So after several days of more troubleshooting, I have some things to report to the list.
First and foremost, I have discovered that the issue has nothing to do with SSL/TLS, which was my earlier suspicion because after doing some PCAPs I discovered that the transactions were negotiating TLS 1.2 on the new server, as opposed to 1.0 on the old.
Also thank you for the rawlog suggestion: that helped a lot in determining what was happening on the IMAP level.
That all said, this is what I've discovered:
There is a very curious and reproducible four-second delay during the negotiation between server and client which is not present in Dovecot 2.1. This is what our customer is complaining about using Outlook 2010.
During a plaintext TCP stream, I'm seeing this:
Client connects (SYN) to server.
Server ACKs and throws back CAPABILITIES.
User attempts to auth with DIGEST-MD5.
Server says, "no thanks." (Not sure why, but I don't believe this is relevant.)
User attempts to auth with plaintext.
Server says, "Yup. You are you. You're logged in."
Client sends the following: ID ("name" "Microsoft Outlook" "version" "14.0")
Server sends an ACK
... and then there's this very curious four-second delay.
- Server then sends out new CAPABILITIES, and everything proceeds thereafter as normal and zippy and fast.
Does this shed any light on the subject?
On 10/13/16 11:21 AM, Bryan Holloway wrote:
On 10/13/16 11:01 AM, Aki Tuomi wrote:
On October 13, 2016 at 6:52 PM Konstantin Khomoutov flatworm@users.sourceforge.net wrote:
On Thu, 13 Oct 2016 10:35:14 -0500 Bryan Holloway bryan@shout.net wrote:
[...]
Is there a way to see the IMAP commands coming from the client? I've tried looking at PCAPs, but of course they're encrypted so I can't see the actual dialog going on between the server and client. I didn't see an obvious way to do this in the docs.
If you have access to the SSL/TLS key (IOW, the private part of the cert) the server uses to secure IMAP connections you can dump the IMAP traffic using the
ssldumputility (which builds ontcpdump).I do, but the client is using a DH key exchange so I only have the server-side private key.
Tried that using Wireshark's decoder features and ran into this problem. I'm assuming I'd run into the same using ssldump, but I'll give it a shot!
I think DH is not the culprit: just to be able to actually decode SSL traffic, you must have the server private key when you're decoding the SSL handshake phase -- to be able to recover the session keys, which you then use to decode the actual tunneled data.
You can also enable only non DH algorithms in ssl settings if rawlog isn't working for you.
Aki
Ah -- interesting tip. I hadn't thought of that. Thank you! I'll report my findings to the list.