I have an eM Client setup (several clients) running mail against OS X Server. Up until now the server was Mountain Lion (OS X 10.8.x and OS X Server 2.2.2). I am now testing against Mavericks (OS X 10.9.1) and OS X Server 3.0.1 and SMTP authentication no longer works. However, IMAP authentication is working and eM Client is able to check mail, sync folders etc. I have tested both the latest eM Client 5.0 and the latest 6.0 as well - same results.
My users are all Open Directory based and from what I see it seems that maybe OS X Server 3.0 no longer allows SMTP authentication using cleartext passwords for Open Directory users (but this is just supposition based on some circumstantial evidence). What authentication mechanism does eM Client support for IMAP and SMTP and are they configurable anywhere? Ideally I would like to use digest (MD5) for both…
I hope someone can advise on this ASAP as my upgrade plans are now blocked by this issue.
I have solved this problem but I think that maybe it reveals a bug in eM Client…
OS X Server 2.2.2 allows LOGIN authentication for Open Directory hosted users. OS X Server 3.0 now only allows Open Directory users to be authenticated using GSSAPI, CRAM-MD5 or Digest-MD5. But if the IMAP/SMTP server advertises support for GSSAPI, DIGEST-MD5, CRAM-MD5, LOGIN and PLAIN then by default eM Client chooses LOGIN. If LOGIN is disabled on the server then it chooses PLAIN. If both LOGIN and PLAIn are disabled then it chooses CRAM-MD5 which works. Since eM Client seems to support CRAM-MD5 quite happily, surely it should choose that if it is available as it is more secure? Is this behaviour intentional or is it a bug?
It is intentional, although we may change it in future.
We do not use DIGEST-MD5 (and NTLM) as long as any other method is available. This is due to many compatibility issues with various servers.
Other methods are currently evaluated in the order sent by the server. If the server responds with proper error code for a given authentication method that indicates it can’t authenticate the given user (eg. because the authentication is forwarded to directory server that doesn’t support the method) then we proceed to try the next method. It is possible that we may interpret the OS X server response incorrectly in this context, but many servers also send incorrect error codes.
As long as TLS/SSL connection is used to connect to the server it shouldn’t really matter what authentication method is used. All the password based ones are almost equally secure.
Thanks for the clarification Filip. I suspect that OS X Server (postfix) probably sends an incorrect error code - it seems to simply say that authentication failed as if the username or password was incorrect whereas in fact it is that Open Directory no longer allows plain text authentication for users at all. This seems to be a change that occurred in OS X Server 3.0 as this setup was working fine with OS X Server 2.2.2. I take your point about TLS/SSL (and of course I am setup to use that) and plain text. Unfortunately the fact remains that setups that worked fine with OS X Server 2.2.2 may no longer work with OS X Server 3.0. I doubt that Apple will be interested in doing anything to address this (!) so maybe you guys want to think if there is anything you can do on your side to make this a bit easier. Maybe even just some documentation/tech note or something about his issue.