Re: [ietf-smtp] Possible cont4ibution to moving forward with RFC5321bis SMTP

[Keith Moore <[e-mail]>]

On 1/2/20 12:41 PM, Hector Santos wrote:

>
>> In these days of complete IPv4 address space exhaustion, it can not be
>> safely assumed that there is no NAT between the MSA and the MX SMTP
>> server.
>
> Correct.
>
> My approach is how to deal with the exceptions to a well-defined SMTP 
> protocol element.   The good intention exceptions will normally 
> address the issue promptly, reports are made, including server 
> whitelisting, client authentication, etc. The bad intention exceptions 
> don't give a hoot.
>
> So by applying frontend SMTP compliancy-based osmosis filters first, 
> you will expect to see fast detection and correction of the good 
> stream, leaving behind the bad stream and less complaints. That is 
> exactly what has happen, what I have experienced, my customers have 
> experienced, in the 17 years of applying these SMTP compliancy filters.

I get the impression that you think that a mismatch of IP address 
between the client and server, for legitimate (e.g. non-spam) traffic, 
is an exceptional case that can be dealt with via exceptional means.

Even if this is an exceptional case today, I do not believe it will 
continue to be an exceptional case for the future of IPv4. I see the use 
of NAT in IPv4 traffic increasing for as long as there is a public IPv4 
Internet.

(Use of IPv6 address literals could be a different case, but I don't 
want to wade into that swamp today.)

You can obviously do what you like with your own product, and you can 
probably change the behavior of your product relatively quickly should 
you need to.   But RFCs should be stable documents and should try to 
provide the right advice for the long term.   So I suspect that 5321bis 
should make it clear that IPv4 addresses can't be expected to be the 
same between client and server.

Keith