mail.app and smtp

apple’s mail.app works fairly well. that is, until something goes wrong. i know—stating the obvious. but hang with me for a moment. if you’re sending outbound email over ssl and/or with authentication, things get messy quickly. for reasons unknown to me, apple hasn’t seen fit to provide any debugging information at all. nothing lands in the console log and certainly no description of the error is presented to you, the willing email sender. instead you receive a terse message: ‘Cannot send message using the server ’. yay; super helpful.

i’ve done some digging with the help of the mail server itself, so perhaps if you’re getting this less than descriptive error, there is hope.

if mail.app is configured to send outbound email over ssl, the target server must advertise that it is willing to accept an encrypted session. when connecting to an smtp server, there’s a bit of a greeting of sorts. it looks like this:

% telnet daffy.iprog.com 25
220 daffy.iprog.com ESMTP Exim 4.63 Fri, 20 Jul 2007 17:54:52 +0000
EHLO my.host.name.local
250-daffy.iprog.com Hello my.host.name.local [10.11.12.13]
250-SIZE 600000000
250-PIPELINING
250-AUTH PLAIN LOGIN
250-STARTTLS
250 HELP

let’s walk through this. after connecting, the remote server identifies itself. then, the mail client identifies itself with EHLO client.name. next, the server advertises a number of supported features. STARTTLS is what we’re interested in at this point. tls is basically ssl, so that’s the key. if mail.app doesn’t see that line, it simply aborts the connection and gives you the unhelpful error message above. super. so, to test this out yourself, open terminal.app and run through the exchange above. you will discover quickly what the remote server does and does not support.

if STARTTLS is there (or you haven’t enabled ssl for outbound email), the next thing to check is authentication support. in my case, because it’s encrypted anyway, a plaintext password exchange is sufficient, called simply ‘password’ in mail.app. if AUTH PLAIN isn’t advertised, that won’t work either. again, mail.app give the same unhelpful error if it’s missing.

there is one complicating piece to this puzzle. some mail servers (including mine) don’t advertise AUTH PLAIN unless after the encrypted session has started. let me go back a minute and explain.

the next step in the exchange above would be for the client to send STARTTLS to the server and the server would reply with 220 TLS go ahead. at this point the systems set up the encrypted session. obviously you cannot do this via telnet like the above. then, the session starts over again, beginning with the EHLO… sequence. the server once again advertises its options. STARTTLS will be missing because it’s already happened. and, in the case of my server, only then does AUTH PLAIN LOGIN show up.

it might be possible (not sure) to test that with the openssl commandline client. otherwise, if you have access to the server, it can be diagnosed from there. i run exim on the server so i just ran exim in debug mode (exim4 -bd -d) and it shows the entire exchange (and a lot of other stuff).

anyway, the short message is, if the server you’re connecting to isn’t properly advertising TLS and/or AUTH support, mail.app gives you a nice, unhelpful error message.