We've recently modified our main outgoing MTA to perform STARTTLS if advertised by the server. This is primarily to satisfy our Gmail customers, because GMail now sports a nasty red lock symbol beside any incoming mail that was not encrypted.
We've discovered that many servers don't have a CN that remotely resemble either the domain name we're sending to or the CNAME for the MX record of the server we're connecting to. For just one example, domains hosted by dreamhost come up with an MX of mx1.balanced.homie.mail.dreamhost.com, which offers a cert with CN=*.mail.dreamhost.com. According to RFC2818 and others, the wildcard should not match, because the wildcard is good for only one node. Testing with http://www.checktls.com/perl/TestReceiver.pl shows that our logic is correct -- the CN does not match. In other cases, the MX record is some completely different network, with no relationship to the domain or the rDNS for the answering server. In those cases, the cert's CN has no hope of matching. I briefly considered using the server's self-identification on the first 220 greeting, but some log-diving shows that it often bears no resemblance to anything at all. So, what do you all do? Right now, I'm verifying the cert and its chain, but ignoring CN mismatches. That seems to be fine for ensuring encryption, but rather defeats the purpose of knowing we're connecting to the proper server. Second question: How do you handle self-signed certs? Do you just ignore cases where the root isn't a trusted root? Jeffry _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
