On 27 Dec 2014, at 16:42, Kee Hinckley wrote:
On 26 Dec 2014, at 14:01, Benny Kjær Nielsen wrote:
I've had this reported once before and I added a quick workaround:
defaults write com.freron.MailMate MmExchangeAuthPlainWorkaround
-bool YES
I cannot promise I'll keep on supporting this, but if I remove it
then it'll probably be because I've found some other way to handle
it.
That doesn't appear to change anything, it's still trying PLAIN. I'm
waiting to hear back from IT to see if there's something else going
on. A co-worker claimed that they were able to authenticate just fine
via telnet, and SMTP is working fine for me, so it could be some other
issue.
2 things to try:
1. If you are using just a bare username for IMAP auth, try switching to
[email protected]. Or vice versa.
2. Instead of STARTTLS on port 143, try port 993 (i.e. "SSL wrapped"
IMAP). If the server supports the use of that port, that may change how
the server sees your connection and so allow PLAIN or LOGIN auth.
Unfortunately the company is on skeleton staff this week. Is there a
reason you don't start with a more secure option and then work your
way back? Or does MailMate not support GSSAPI and NTLM?
Nothing new should implement NTLM. Nothing that doesn't run on Windows
should implement it unless supporting obsolete Windows tools is
critical. It survives as a concession to older Windows tools that can't
do GSSAPI/Kerberos. It is marginally more secure than plain text over
unencrypted transport but only because replay is more obscure. GSSAPI
support would be a nice feature, but it is a major addition to any
client and wouldn't help you any if you are talking to the Exchange
server from someplace where you can't reach your Kerberos infrastructure
(which is common).
_______________________________________________
mailmate mailing list
[email protected]
http://lists.freron.com/listinfo/mailmate
