I am getting TLS shutdown errors with every single MS Outlook POP
retrieval from a couple of test users I'm serving pop3s to. Looks like
this:
May 1 17:26:36 hades xinetd[31233]: START: pop3s_roc pid=14021 from=10.20.11.15
May 1 17:26:36 hades sqpopper[14021]: (v4.0.1) TLSv1/SSLv3 handshake with client
at ro1-cjanel.ddns.roc.questra.com (10.20.11.15); new session-id; cipher: RC4-MD5
(RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 ), 128 bits [pop_tls_openssl.c:510]
May 1 17:26:36 hades sqpopper[14021]: (v4.0.1) POP login by user "cjanel" at
(ro1-cjanel.ddns.roc.questra.com) 10.20.11.15 [pop_log.c:244]
May 1 17:26:36 hades sqpopper[14021]: Stats: cjanel 0 0 0 0
ro1-cjanel.ddns.roc.questra.com 10.20.11.15 [pop_updt.c:296]
May 1 17:26:36 hades sqpopper[14021]: TLS shutdown Error [pop_tls_openssl.c:784]
May 1 17:26:36 hades sqpopper[14021]: (v4.0.1) Timing for
[EMAIL PROTECTED] (normal) auth=0 init=0 clean=0 [popper.c:371]
May 1 17:26:36 hades xinetd[31233]: EXIT: pop3s_roc status=0 pid=14021
duration=0(sec)
They all look like that in repeated tests. I want to be sure this is
normal behavior before I start offering this to the masses. Mail does
seem to retrieve just fine without any problems, and snooping/traces
reveal full encryption. My guess is Outlook isn't following the
spec and just disconnects without shutdown and QUIT...
I'm getting some more testing in tomorrow with different clients, but
wanted to get this message off as well to see if anyone else has already
found this to be normal behavior.
One other question: is standalone mode a lot faster for serving with TLS
encryption (presumably because it does session key init infrequently) ?
We make heavy use of concurrency and rate limiting feature of xinetd, so
standalone mode isn't an option, but perhaps an external session cache
would be of help here...I might try implementing something like this if
it's a lot faster, since our mail server doesn't have the most
horsepower in the world :)
