On 9/28/20 8:04 AM, Laura Atkins wrote:
But if the RFC recommends poor practice, it will be harder to change
that poor practice, because some people will say "but the RFC
says...!" So the RFC should not recommend poor practice.
What is your evidence that it is poor practice?
If, OTOH, the RFC recommends NOT filtering based on EHLO arguments,
then it will be at least a bit easier for operators to stop doing
that when they start seeing that it's a bad idea.
What is your evidence that it’s a bad idea?
I've made those arguments multiple times already. "evidence" seems like
the wrong thing to ask for because this is really a question of /design/
- what choices should be made to allow the email network to continue
operating seamlessly and efficiently in the event of widespread use of
NAT within the network (either to gateway between IPv4 and IPv6 or to
economize use of IPv4 space)?
I'm thinking long term here. I expect 5321bis, if we do our jobs
right, to be around for decades. So its recommendations need to
make sense in the long term rather than the short term.
That presumes that your recommendation makes sense and that allowing
any random NATed machine to connect to the internet and send mail is a
good thing. I think we have ample evidence that this is actually an
abuse vector and a bad thing.
I disagree. At one time NAT was mostly associated with consumer grade
routers, therefore NATted mail was unlikely to originate from a mail
service provider, and more likely to originate from a compromised PC.
But "carrier grade" or "large scale" NATs are increasingly being used
within the network (rather than only at the periphery) in order to
maximize use of IPv4 address space in the face of increasing address
scarcity. Various flavors of NAT have also emerged as the likely best
way to exchange traffic between IPv6 and IPv4, and their use is also
increasing.
What changes do you see happening that will make this currently good
practice become a bad one.
The changes I see happening include the increasing scarcity of IPv4
address space and the consequent emergence of IPv6-only network
providers using NAT to move packets between IPv4 and IPv6 addressing
domains. I'm also anticipating the need to eventually phase out the
public IPv4 Internet altogether.
(From operators' perspective: how long does it make sense for every
network to maintain its IPv4 baggage, just so that email won't be
blocked? At the very least we need input from network operators.)
It doesn't actually bother me that much if existing operators filter
based on EHLO validation as long as they re-evaluate that policy over
time. I expect operators to be pragmatists. But I really do
expect use of NAT64 to increase, and I really think it's unhelpful to
network operators if reliable email operation requires them all to
maintain static IPv4 addresses and connections to the public IPv4
Internet. It's silly for email to delay a transition away from IPv4
for this reason.
Can you explain this use case in more detail?
I'm not sure what I've left out.
Keith
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp