I may be wrong on this but it looks like Microsoft SMTP clients (at least Windows Mail and Outlook) don’t like being sent a large volume of SSL certificate information when opening a TLS connection. They appear to assume that the data they are being sent is malformed and assume that STARTTLS failed, continuing with an unencrypted SMTP dialogue.
This can be triggered relatively easily on a Debian system by telling Exim to use all the certificates provided by the ca-certificates package (which is the default configuration). The Windows clients will give an unhelpful “the remote end dropped the connection” style error, caused by the server getting upset by the unexpected fallback to unencrypted SMTP. The server logs will show something like this:
2009-02-17 21:32:55 TLS error on connection from client.example.com (Client) [192.168.192.168] (gnutls_handshake): A TLS packet with unexpected length was received. 2009-02-17 21:33:00 SMTP protocol synchronization error (input sent without waiting for greeting): rejected connection from H=client.example.com [192.168.192.168] input="EHLO Clientrn"
Configuring the MAIN_VERIFY_TLS_CERTIFICATES option in the Debian Exim configuration (which sets the tls_verifiy_certificates option in the actual Exim configuration) to point to something with less certificates in should avoid the issue.
On the bright side, at least they’re making an effort to avoid overflows.
See http://www.outflux.net/blog/archives/2009/01/13/etoomanycerts/
Don’t do that then. The point is, you are only sending the chain from the root to your own server certificate out to the client. The list of certificates used for (client) certificate validation is orthogonal to it, and not sent.
In sendmail, these are:
O CACertPath=/etc/ssl/certs
→ peer certficate validation (directory with *.0 files)
O CACertFile=/etc/ssl/deflt-ca.cer
→ own certificate chain; root ca, intermediate cas, but not own server certificate (PEM file/bundle)
O ServerCertFile=/etc/ssl/default.cer
O ClientCertFile=/etc/ssl/default.cer
→ own certificate (I use the same, no matter if my sendmail is the sender or recipient)
O ServerKeyFile=/etc/ssl/private/default.key
O ClientKeyFile=/etc/ssl/private/default.key
→ own private key (similarily)
For Drecksim, the names of the configuration parametres may differ, the use would be the same, I suppose.
@mirabilos: Half the problem is that this is the default configuration in Debian – I blogged it mostly to try to help anyone else who runs into it Google the problem faster.