On Thu, 19 Dec 2019 12:18:53 -0500, Hector Santos said: > But the SMTP specs also say, it MUST NOT reject on this basis and I > was part of the WG encouraging text that we now find in section 7.9 > because we had new situations where a "MUST NOT reject" rule was not As it turns out, it wasn't rejecting on that basis, it was rejecting on a "not having a FQDN is a very strong spam signal" policy basis and erroneously issuing the wrong message. Given that there were *two* rules involved, one of which *did* flag an actual protocol violation, I'm willing to accept it's just a cut-n-paste error that nobody actually noticed for a decade or so... And maybe it's time to let that "address literal" sail into the sunset. If you're an MUA on a DHCP'ed device, there's a good chance that you don't know your FQDN. But at that point, the reality is that you're probably talking to an MSA on port 587 rather than a full MTA on port 25, and the MSA is (or should be) going to be authenticating you far more strictly than checking your EHLO. And if you're a full MTA on the public internet today, and *don't* have a FQDN, you're going to have a really bad day in 2019, *totally notwithstanding what the RFCs say about how it's totally legal*. What consenting MTA's do inside a walled garden is, of course, totally up to the administrators involved. They can use X.400 for all the rest of the net cares. We passed the point of a significant divergence between "what works in a walled garden" and "what works in the wild" at least a decade ago. And at *some* point, that's a big pile of technical debt that's going to need to be paid back. At this point, the least bad option is probably producing an updated rfc5321/5322 that documents the protocol, and a BCP/guidance document of "but here's what you need to be doing to ensure you can survive in the wild".
Attachment:
pgpVN5EFWGCsi.pgp
Description: PGP signature
