Crossdomain web hosts are also a thing, and HTTPS works fine. (Sometimes with particularly hilarious definitions of "fine", like CloudFlare's former practice of putting dozens of customers' websites in the same certificate, via subject alternative names.)
If you're worried about the fact that your mail host and web host can now impersonate each other, we can just define a new X.509 extension for "I can only be used for email". You might even be able to get away adding a new option to the existing Extended Key Usage field, but it's possible that enough clients don't enforce it rigorously enough.
Ideally, you'd also want an SMTP equivalent of strict transport security.
SMTP can use TLS, though, right? It doesn't _have_ to use STARTTLS? You _could_ use SNI.
My concern is that it doesn't get you anywhere. phishing sites can and do get TLS/SSL certificates. The process isn't particularly difficult or labour intensive if you own the domain. As far as spam goes, so what? This only proves I'm talking to the server I intended to, not that it's a reputable and upstanding member of the server society.
It would at least help companies/freelancers to host their own mailserver. The same infrastructure may lead to EV for individuals (or equivalent) once we can figure that out. Waiting for everything to be equally ready leads to inaction.
If someone spoofs a CNAME to evil.com in response to DNS query for google.com, your browser will not accept a certificate from evil.com as valid for google.com, whereas if you send mail to gmail.com and someone spoofs an MX record for mx.evil.com, a vaild mx.evil.com certificate will be accepted.
Right, so "don't do that." There isn't a clear standard for what subject to accept, out of the two options. The obvious correct one is to check for google.com, even if you're talking to a server named mx.google.com -- just as you don't trust CNAMEs and you check the original name, don't trust MXes either. It's just that most people don't have those certs configured in their mail servers, so doing that check today would lead to widespread failures and it's a bad default.
Postfix, for instance, lets you configure what it checks via the "smtp_tls_verify_cert_match" option. If you set it to "nexthop", it'll require google.com. The default, "hostname", will check against mx.evil.com.
That proves I own the domain to some extent. Don't DKIM records do the same? For the purposes of anti-spam, a cert doesn't do anything except prove that you showed some CA that you own the domain (which can be done and is done in other ways currently).
At present SMTP is so broken that arbitrary servers are allowed to send mail for any domain, with fake headers, there is no proper verification of sending server or sending identity, the mail is accepted (along with legitimate mail), and put in spam folders (sometimes, as is real mail sometimes). SPF/DKIM are an attempt to solve that of course, but they are not enforced rigorously or universally, and tactics like IP reputation and email content sniffing still seem to be widely used too (the problem reported in the article). Compared to the web, email seems pretty behind on verifying server identity.
Yes, that's my point. It doesn't really solve any issues that SPF/DKIM don't already solve -- pointing to certs isn't a new solution, it's a rehash of the same solution.
And yes, the concept of relays should disappear along with much of the other cruft SMTP brings. (And while we're at it, can we fix/replace IMAP, or at least make the spec say that message ids are eternal and can't be invalidated?)
Currently headers get modified in-flight, so a content-based ID wouldn't work.
As for a new protocol, there are some out there, but all fail in some way or another. I figured I'd throw my ideas out there and see how much they fail https://github.com/jimktrains/email_ng
EV certificates are to be bit more extensive than just proving ownership of domain. Most importantly they should associate the owner with some legal entity. So using EV certs would force spammers to establish shell companies, which typically is bit more expensive than just buying a domain and leaves stronger paper trail.
