The case of the sudden segfaults
The CSAIL mail servers run exim, a very flexible and powerful mail server. Typically a very stable one, too, at least until just recently. It was brought to my attention yesterday that CSAIL users were unable to send mail to addresses @broad.mit.edu. Investigation revealed that yes, there was a problem. The exim process responsible for handling the remote SMTP session was crashing when communicating with the Broad servers. Trial and error revealed that this was related to the SSL certificate exchange taking place. I disabled SSL for remote SMTP sessions to work around the problem while I investigated further. I copied outgoing.csail.mit.edu's Exim configs over to a test system, only to find that exim would crash there as well. How is this possible? It had never done this before!
More testing revealed that the list server, tweety.csail.mit.edu, which runs exim and handles its own deliveries, was able to send mail over an SMTP+SSL session to Broad. But it runs the same version of exim. The exact same binaries, in fact. I determined that the only difference was that outgoing was configured to use certificates when negotiating an SSL session as a client, and tweety was not. So I was able to re-enable SSL in client mode on outgoing, but I had to leave the certificate-related directives out. Given that it isn't likely that anybody out there was actually verifying the certificates, this isn't likely to ever be an issue. But it's very weird.
At least my initial fear didn't turn out to be true. I released a security advisory for the Debian OpenSSL packages the other day. I was concerned that this was somehow related to the problem. However, reverting to the previous version didn't change anything. I guess that's good. Sort of.
writebacks...
trackback
TrackBack ping me at:
http://people.csail.mit.edu/noahm/blosxom.cgi/exim-segfaults.trackback
comment...