[Top] [All Lists]

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

2020-09-28 17:59:53

On 29 Sep 2020, at 08:16, John Levine <johnl(_at_)taugh(_dot_)com> wrote:

In article 
<b47992c5-17dc-f461-c1cd-1e4277f52c00(_at_)network-heretics(_dot_)com> you 
On 9/28/20 10:27 AM, John Levine wrote:

Keith is asking us to expect that mail clients will move behind NAT64
even while their associated servers do not,

No, I expect IPv4 to go away.   Gradually at first, and then much more 
quickly.    Are people here really going to insist that operators have 
to maintain IPv4 servers (or ALGs or whatever they need to maintain the 
illusion that the client and server see the same source IP address?).   

I'm sorry but this is making less and less sense.

You appear to be saying there will be mail systems that need to send
mail to IPv4 systems, but will not have an IPv4 mail server so the
recipients can't reply to them.  Really?

Actually I expect there will be systems where just 25/<ipv4-address> is
statically NAT46’d to a 25/<IPv6-address> and all the outbound traffic goes
back through the NAT64 with no linkage to the IPv4 address except for those
established by the inbound connections.

I expect that setups like this will happen dynamically in the future and the
A records will be dynamically updated to reflect whatever IPv4 address the
server happened to negotiate out of the NAT64.  The protocols to do this
have existed for years now.  They just haven’t been initiated from SMTP
servers yet.

The same thing will happen for other services like HTTP{S} that needs to
supported in house.

If you do expect the recipients to be able to reply, why wouldn't the
inbound IPv4 mail server's address be the one it uses to send mail,
like it has for the past 40 years?


ietf-smtp mailing list

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka(_at_)isc(_dot_)org

ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>