[Top] [All Lists]

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

2020-09-27 07:43:32
On 9/27/20 1:22 AM, John Levine wrote:

At some point in the past, this was _not_ a reliable spam filter. ...
I think you may be conflating SMTP and submission. For submission,
you're right, the EHLO argument is frequently some random name that a
computer thinks it has behind a couple of layers of NAT.
Well, if memory serves, that language from the 5321 originally dates from the days when port 25 was routinely used for submission.   So that's a useful point.
server to server, I agree with Sam that it is extremely rare for a
legit message to come from a host that doesn't know its name.

Okay, but should the SMTP standard effectively require that a client SMTP know the server's idea of its source IP address?

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.


ietf-smtp mailing list