[Top] [All Lists]

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

2020-09-28 08:10:23

On 28 Sep 2020, at 13:53, Keith Moore <moore(_at_)network-heretics(_dot_)com> 

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 

I’ve seen lots of arguments, yes, but I’ve not seen any real evidence backing 
up your assertions. I’m trying to better understand your point of view and 
understand why this is so important. But it’s been hard to find that in the 

The design question is one that should be discussed, but is this the correct 
space for that? 
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.

I understand carrier grade nat, thank you. 

I was struggling to come up with use cases. I understand the use case now, and 
better understand why you’re bringing this up thinking about the v6 to v4 
NATing going on. 
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 

Or we could write the BIS to recommend anyone running v4 services also provide 
v6 services, couldn’t we? Take the burden off the v6 only systems which are 
likely newer entrants and put it on the ‘old timers’ who’ve been around for 
(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.)

My experience is that folks running MTAs on IPv6 actually enact stricter 
technical requirements on those systems. For instance, many IPv4 servers will 
accept mail without valid rDNS on the sending IP or will accept mail without 
SPF records, while the IPv6 servers run by the same entities require those 
things directly. 
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.

This makes things clearer. 

Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
(650) 437-0741          

Email Delivery Blog:     

ietf-smtp mailing list
<Prev in Thread] Current Thread [Next in Thread>