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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp