ietf-smtp
[Top] [All Lists]

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

2020-09-28 08:49:43


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

On 9/28/20 9:10 AM, Laura Atkins wrote:

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’ve seen lots of arguments, yes, but I’ve not seen any real evidence 
backing up your assertions.
Most of this is what I've picked up reading IETF lists and trade publications 
for years.   I guess I thought it was common knowledge within IETF that NATs 
were increasingly being used in these ways - certainly there were many 
discussions about it in IETF several years ago.   

NATs, yes. NATs handling significant amounts of SMTP traffic, I’ve not seen any 
evidence for.

And if it’s just an issue of NATs, there are other solutions. So the question 
really becomes: is this an issue affecting large amounts of email? What emails 
is it affecting? Is it likely to affect email in the future? That’s the kind of 
evidence I was asking for. Tell me, how much traffic, does this affect now? How 
much traffic do we expect this to affect moving forward? What tools are we 
removing from filters if we say they cannot evaulate the hostname? What impact 
does that have on them? 

The next round of questions will look something like:

Is this a RFC status that MTA operators are simply going to ignore? In the 
email space we have some very large players who handle billions of emails a day 
and blatantly violate the RFCs. ’But the RFC says’ is not, in my experience, a 
persuasive argument for these types. They usually have significant analysis and 
data that shows that the operational and human problems resulting from their 
lack of implementation is not enough to force them to follow the RFCs. Simply 
saying something MUST or MUST NOT be done doesn’t actually result in that 
happening. 

And then there is the abuse problem. I understand that it’s outside the scope 
of the rewrite here but it is relevant for adoption. There are absolutely cases 
where interoperability takes a back seat to protecting the network. 
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 sniping. 

The design question is one that should be discussed, but is this the correct 
space for that? 
Arguably the discussion should be taking place on the emailcore WG mailing 
list rather than here.   But we started the discussion here.



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.    

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 decades. 
We could make such a recommendation.   Though I expect, that like spam 
filterers, network operators will do what they want, and consider themselves 
justified in doing so, regardless of what we recommend.

I suspect that the task before us is to make recommendations that both spam 
filterers and network operators will find palatable.

So why are we wasting time on the EHLO evaulation question, if that’s the case. 

(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 might even make sense for IPv6 operations to "raise the bar".   For 
example, PTR lookup of IPv6 addresses allows finer-grained delegation than 
PTR lookup of IPv4 addresses.   But regardless of what some operators are 
doing, I think this requires careful analysis to justify from a standards 
perspective.   I suspect there will be IPv4-only networks with a legitimate 
need to originate mail to IPv6-only servers.

You suspect, but I’m not convinced your suspicions are a reason to upend 
current practices. 

laura 

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

Laura Atkins
Word to the Wise
laura(_at_)wordtothewise(_dot_)com
(650) 437-0741          

Email Delivery Blog: https://wordtothewise.com/blog     







_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
<Prev in Thread] Current Thread [Next in Thread>