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

[Keith Moore <[e-mail]>]

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.


> 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.


>> (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.

Keith