Currently Being ModeratedMay 14, 2012 10:56 AM (in response to Michael_Lehn)
I'm using 10.7.4 clients with 10.6.8 server and with port forwarding (though not TCP to 999 to 993), and it works fine.
With SSL involved, I always check the certificates, but that's not the trigger here.
What authentication mechanisms are implemented on the client and on the server, and what's in the authentication logs?
Did you possibly end up with a bogus entry in the keychain? (Sometimes removing the passwords and re-adding them will clear this.)
Currently Being ModeratedMay 14, 2012 2:44 PM (in response to MrHoffman)
On failure I get an entry like
May 14 07:20:52 apfel com.apple.securityproxy_mail: V1:IMAP:ACCESS[client:xx.xx.xx.xx:52652, proxy:xxx.xx.xx.xx:999, server:xxxxx.xxxxxxxx.xxxxx.xx:993, connected_secs:180, user:, client-authmethod:, proxy-authmethod:, client-transport:ssl, server-transport:ssl, state:proxy-connected, result:BAD. User not authorized by proxy server. No valid auth method from client. Verify that client and server are configured for mobile access. Connection was closed cleanly.]
in mail_access.log. So the server does not even get a user-name, client-authmethod or proxy-authmethod. The SSL certificate is still valid. No matter what authentication method I choose on the client side the log entry always looks the same, i.e. user name and auth method is empty.
And as I mentioned before. Other mail clients like POSTBOX, mail from iOS and mail from other (older) Mac OS X clients still work fine.
Also clearing the keychain did not change anything.
Currently Being ModeratedMay 14, 2012 3:55 PM (in response to Michael_Lehn)
I have exactly the same problem. It was ok before but with the latest update something broke. Older osx clients and ios clients work ok. If I bypass the proxyserver when I am on the local network and go directly to the server ip address it works again. So something with authenticating to the mobile access server doesn't work anymore. I go from port 5993 to 993.
May 15 00:16:35 soundbox com.apple.securityproxy_mail: V1:IMAP:ACCESS[client:xx.xx.xxx.xxx:56449, proxy:xxx.xxx.x.xx:5993, server:xxx.xxx.x.xx:993, connected_secs:0, user:, client-authmethod:, proxy-authmethod:, client-transport:ssl, server-transport:ssl, state:proxy-connected, result:BAD. User not authorized by proxy server. No valid auth method from client. Verify that client and server are configured for mobile access. Connection was closed cleanly.]
Message was edited by: Henry Mac
Currently Being ModeratedMay 14, 2012 4:09 PM (in response to Henry Mac)
Y'all are running mail through a proxy server? If so, can that be eliminated?
Currently Being ModeratedMay 14, 2012 4:28 PM (in response to MrHoffman)
Ah sorry, when talking about the proxy server I mean the mobile access server. So yes, the mail app can connect directly to the imap server but not through the mobile access server anymore.
Currently Being ModeratedMay 14, 2012 4:28 PM (in response to MrHoffman)
My server is behind a firewall that blocks port 993. So I map port 999 to 993 to bypass the firewall.
And no, I have no control over the firewall
Currently Being ModeratedMay 14, 2012 5:24 PM (in response to MrHoffman)
I turned off the firewall on the client, router and server. No difference. Also routed from 993 to 993 and that didn't work. If I open port 993 on the firewall I can connect from an external ip address directly to the imap server. Also connecting from the local network to the mobile access server I get the BAD result.
Currently Being ModeratedMay 18, 2012 4:23 AM (in response to Michael_Lehn)
So how should I proceed? Send a bug report? And if yes, how?
Currently Being ModeratedMay 18, 2012 1:36 PM (in response to Michael_Lehn)
Same symptom in our School.
We have a kerio connect mail server behind a proxy Mobile Access 10.6.8.
IMAP mail account with Mail.app doesn't work with 10.7.4.
Worked if I bypass the Mobile Access server and connect the IMAP account directely to the Kerio connect server.
Opened a call the 10 mai to Apple.
No news since there…
I called first the server Help Desk.
I explained twice my problem during 15 minutes.
After that the Apple agent told me that he can't register my problem because Mobile Access Services was not an Apple products…
Don't know if I had to laugh or cry…
After that redirect me to the OS X client Help Desk because it was not a server problem for him…
Currently Being ModeratedMay 24, 2012 3:17 PM (in response to Michael_Lehn)
Well, after suffering through this same problem for quite a while, I started doing some digging to see what I could find.
I went to Terminal, and used openssl to see if I could get any error messages that would help. So, the Terminal command is:
openssl s_client -connect <mobile access server>:993
This actually connects, gives a bunch of info about the server, and ends up returning "* OK Dovecot ready."
Wow! We're actually connecting through the Mobile Access Server to the internal IMAP server. Good so far.
So, issue the IMAP login: "a login <username> <password>"
And it just hangs..... I terminated the openssl session, VPN'd in to the internal network and checked the Mobile Access Server mail logs. Same error - the user and authmethods are blank.
No error messages on the client side, so being stuck, I tried to find anyone with a similar issue just generically with dovecot and openssl.
I found an article through Google where someone had the exact same problem trying to connect to GMail. http://superuser.com/questions/134924/manually-accessing-gmail-via-imap
The answer to the problem was that the IMAP server only responds to lines ending with <CRLF>. Trying that article's suggestion, I issued in Terminal this command:
openssl s_client -crlf -connect <mobile access server>:993
Same information about the server as before, and the same "* OK Dovecot ready." message.
Tried the login command again, "a login <username> <password>", and this time got "a OK Logged in."
And from there, I could select the Inbox, etc.
So it looks like the CRLF is the source of the issue, but I have no idea how to make Mail.app do this correctly. I also don't know why it's only a problem when going through the Mobile Access server; if I openssl while I'm on the internal network, I don't need the -crlf switch for it to work.
Hopefully this gets someone with more experience onto the right track to fixing the problem.
Currently Being ModeratedJul 18, 2012 11:19 AM (in response to Michael_Lehn)
So Apple still hasn't fixed this bug. The sad thing is that I am not surprised that Apple does not care.
Currently Being ModeratedJul 19, 2012 12:35 AM (in response to Michael_Lehn)
My case opened the 10 may about this subject is always open.
In fact I don't know if he is always open.
No news since there… Sent an email the 27 june to have some news, but no answer.
I have also little hope that the 10.7.5 will correct it.
So Apple what have we to do now:
– Staying in the 10.7.3 for the rest of our life?
– Remove our Mobile Access Server?
We are waiting for answer.
Is there somebody who tested the Mail.app 10.8 with Mobile Access?
Currently Being ModeratedJul 19, 2012 9:00 AM (in response to David Tschudi)
If Apple Mail had a problem with MS Exchange Server, they would fix it within hours.
Unfortunately Apple Mail has only a problem with Mac OS X Server.
Currently Being ModeratedAug 6, 2012 4:49 AM (in response to Michael_Lehn)
Tested it with Mail 6.0 under 10.8, same results, doesn't work…