I've been seeing some odd behavior today with some of the servers that respond to smtp.comcast.net on port 587. Some, but not all, of the servers are presenting self-signed certs, causing my own server to balk at making a connection. (The Organization is RTFM, Inc. -- it'd be funny if mail wasn't queueing up on my end). Sometimes I get a server with a legit cert, so I can slowly drain my queue by flushing it over and over and over...
openssl s_client output below. I can send a libpcap trace on request.
--Jeff
┌─(root@bookcase)(04:48:06)
└─(~)-> openssl s_client -CApath /etc/ssl/certs/ -starttls smtp -connect smtp.comcast.net:587
CONNECTED(00000003)
depth=1 /C=US/O=RTFM, Inc./OU=Widgets Division/CN=Test CA20010517
verify error:num=19:self signed certificate in certificate chain
verify return:0
* Jeff Mitchell:
I've been seeing some odd behavior today with some of the servers that
respond to smtp.comcast.net on port 587. Some, but not all, of the
servers are presenting self-signed certs, causing my own server to
balk at making a connection. (The Organization is RTFM, Inc. -- it'd
be funny if mail wasn't queueing up on my end). Sometimes I get a
server with a legit cert, so I can slowly drain my queue by flushing
it over and over and over...
There's no PKI for Internet Mail routing, so I don't see what you get
by checking certificates at all.
Function, non-broken Outlook integration.
Adrian
(Who is -fed up- with outlook just randomly spewing crap at you from time
to time if you use self-signed certs for various mail related activities.
Or chained certs. Sigh. 
That's not entirely true. SMTP over TLS is intended to work for
inter-domain SMTP, and it is in fact quite frequently used. However it is
utterly broken, with the result that what PKI there is is not in practice
used.
The brokenness is:
* TLS certificates verify host names not mail domains, so they only
provide protection for the result of an MX lookup - they don't verify
the MX lookup itself was not spoofed.
* Most SMTP software does not check certificates and many certificates
installed on MX hosts have different common names from the MX record
target hostname. Turning on certificate verification breaks too much
email, and there's no incentive for postmasters to install valid
certificates.
These problems are extremely hard to fix.
Tony.
Tony Finch wrote:
That's not entirely true. SMTP over TLS is intended to work for
inter-domain SMTP, and it is in fact quite frequently used.
My understanding is that Comcast uses it simply for encryption, not for authentication.
* Most SMTP software does not check certificates and many certificates
installed on MX hosts have different common names from the MX record
target hostname. Turning on certificate verification breaks too much
email, and there's no incentive for postmasters to install valid
certificates.
You're right; certificate verification was turned on on my end simply because I'd never had a reason to turn it off (since in recent times the majority of my mail goes through their gateway, which has never presented an invalid certificate to me before).
However, in this case, there is another benefit: the presence of what was clearly a default certificate on some of their servers, where before there were always valid certificates presented, could indicate that the rest of the mailserver was incorrectly configured. Better that mail is delayed than it is accepted and ends up bounced or disappearing into the ether (that was my main incentive for the OP) 
FWIW, this seems to be fixed today.
--Jeff
Message submission is very different to inter-domain SMTP. There's no MX
indirection, so the TLS certificate actually verifies the correct name,
and certificate verification is normal on the client, and correct
certificates are normal on servers. A much better situation.
Tony.
I submitted a ticket to Comcast yesterday around 10:00 AM EST regarding
this issue (ticket #151689315), received a standard reply last night,
but as of yesterday 14:45 EST, the issue seems to have resolved itself.
Here's the certificate I saw:
Issued To
Common Name (CN) - localhost
Organization (O) - RTFM, Inc.
Organizational Unit (OU) - Widgets Division
Serial Number - 01:01
Issued By
Common Name (CN) - Test CA20010517
Organization (O) - RTFM, Inc.
Organizational Unit (OU) - Widgets Division
Validity
Issued On - 5/17/2001
Expires On - 3/6/2004
Fingerprints
SHA1 Fingerprint - 15:13:DF:CF:8B:BE:63:2D:91:BC:2E:B3:ED:29:8D:74:06:4D:7D:8A
MD5 Fingerprint - 21:91:FB:FE:F3:13:AF:74:53:48:56:B4:EF:7A:13:69
Eric
Eric Tow wrote:
I submitted a ticket to Comcast yesterday around 10:00 AM EST regarding
this issue (ticket #151689315), received a standard reply last night,
but as of yesterday 14:45 EST, the issue seems to have resolved itself.
I can verify that it was still happening as of about 12:10 AM EST this morning, when I submitted the OP (the output there was grabbed right before I posted). I'm out of the country so calling them up to submit a ticket was not possible.
I did get word in a private message that the people in the department responsible say that it is fixed now.
Thanks,
Jeff
Sure, but, in that case, it's also perfectly valid to load the self-signed
root certificate for that SMTP server's cert. chain into the trusted roots
set.
Owen