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

[Keith Moore <[e-mail]>]

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.
> For SMTP,
> 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.

Keith