3 ms·
Considering you basically can only get a certificate for a domain name that refers to a host (and offering an IP address for an unqualified domain name is an an
by tinus_hn 4y ago
Considering you basically can only get a certificate for a domain name that refers to a host (and offering an IP address for an unqualified domain name is an anomaly) I’d expect the required subject to be the hostname. But the RFC does not specify it:
The decision of whether or not to believe the authenticity of the
other party in a TLS negotiation is a local matter. However, some
general rules for the decisions are:
- A SMTP client would probably only want to authenticate an SMTP
server whose server certificate has a domain name that is the
domain name that the client thought it was connecting to.
However in the case of Postfix there’s also the matter of connection to services like an ldap server to check things. In that case it’ll also by default happily connect to an ldaps service with a self signed, expired certificate.
- usr1106 4y agoThanks for the reference. But this does not seem to make sense. Email delivery is about interoperability. How can that be achieved if parties make their local decisions? P.S. As you probably guessed in my previous comment "3 months later" should of course have been "3 months earlier". Sorry about the mistake.
- tinus_hn 4y agoIt’s delivering email, there is no way for the receiving site to state a certificate is required anyway. Traditionally it’s just a plaintext connection on port 25 and using and supporting STARTTLS is optional. I suppose you could write up a way to specify this in DNS but it’d take decades to be implemented and you would have to deal with pushback from the snoops who I’m sure don’t mind they can peep into the email you receive.
- usr1106 4y agoI guess the support of TLS was added for confidentiality and integrity on untrusted networks. If you don't verify the certificate a MITM attack is possible. So what is the remaining benefit of using TLS?