>>> I am curious why with opportunistic TLS (security level may), you're >>> bothering to take any action to tweak the entirely cosmetic certificate >>> path validation status? >> >> What about parsing the maillog and adding those trusted servers to a table >> in order to enforce a higher tls level for future requests? > > Well, absent some explicit commitment by the receiving domain to > continue to present meaningul certificates from trusted CAs, it would be > quite wrong to "pin" previously observed features. The receiving domain > is free *at any time* to > > * drop TLS support, > * limit TLS to particular highly trusted senders, > * switch to self-issued certificates > * use DNS names in the certificate that don't match what you expect > * ...
That's true but requesting and installing a CA issued certificate could be seen as a form of commitment. Not an explicit one but it's extra work (especially if there's no webserver running on your mta). The question is how likely it is such a server is dropping tls support after that work. I'd guess it will be unlikely and errors mostly occur due to expired certificates or other (temporary) configuration issues. > If the receiving domain wants to signal transport security policy, it > can use DANE, or perhaps its crippled half-sibling MTA-STS. DANE would be best but not everyone is using dnssec yet. Unfortunately that is a requirement although one could argue that tlsa records without dnssec are more secure than no tlsa records, given that regular dns lookups are good enough for resolving mx rrs. I'm not fond of MTA-STS requiring https for smtp. Yes it's more secure but only to the extent you trust your CA - and in most cases all the other CAs listed in your cert-bundle.pem. >> Or just to be informed a previously trusted server cannot establish >> trusted connections anymore. > > Sure, but the forensic value of the signal is rather weak, since you > learn nothing about the names in the certificate, and anyone can get > a certificate from Let's Encrypt. So your connection was to some > server that had some certificate, ... now what? You'll get the information that a valid, CA-issued certificate was used and you can extract the relay from the maillog. I'd guess for real mailservers that certificate would verify with the mx/relay servername, which could be enforced and monitored. Probably I would not implement such a system but the idea came to mind. Best regards Gerald
