[Top] [All Lists]

Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321

2020-09-27 10:05:04
On Sun, 27 Sep 2020, Keith Moore wrote:
For example, should the standard insist that client SMTPs have and use an outgoing IPv4-capable interface any time the server SMTP is reached (directly or indirectly) via IPv4?   Or should client SMTPs be forced to use IPv6-to-IPv4 SMTP relays rather than NAT64?    Should we have to keep maintaining a public IPv4 network indefinitely (or at least until IPv6 is globally ubiquitous)?

To me NAT64 seems like an essential tool for transitioning to IPv6 and one quite often chosen by carriers, and I don't see the benefit in adding complexity to the SMTP signal chain  (with the consequent degradation of reliability)  just to preserve this rule.

This seems backward to me. Keeping in mind that upwards of 90% of all mail is spam, and reliable spam signals are valuable, we know from experience that real mail servers have static addresses and matching forrward and reverse DNS. Anything that comes from a dynamic or NAT pool is invariably spam from a botnet.

Small mail servers send and receive on the same address, so if they're going to work on IPv4 at all, they need a static v4 address. Large providers do NAT64 for their customers, but that's not where they put their mail servers (or any servers that need an A record.) They have a chunk of static v4 space for that, and that's where they put their outgoing mail hosts, too.

Also remember that mail hosts don't need a lot of address space. I've seen estimates of the total number of SMTP hosts in the 100,000 range.

John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.
ietf-smtp mailing list