[Top] [All Lists]

Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version

2019-12-21 09:01:04
On 12/20/2019 4:22 AM, Paul Smith wrote:
On 19/12/2019 22:52, Hector Santos wrote:

It's actually quite hard to automatically get a correct address
literal if you're behind NAT, and if you're also on a dynamic IP, then
it's approaching the impossible.

For auto preparing the correct MUA's MTA setup, I agree, it is a quite hard to get it coded right. I believe the SMTP "ideal" MTA auto setup is:

(1)  Set Client.IP from Sender Session Connection IP

(2)  Set EHLO.field from manual configuration/definition

(3.1) if EHLO.FIELD is empty then EHLO.FIELD = using socket gethost() for client.ip (3.2) if EHLO.FIELD is empty then EHLO.FIELD = get first PTR for client.ip

(4)  if EHLO.FIELD is empty, then EHLO.FIELD = "[" + Client.IP= "]"

Not every MTA does #2. Not every MTA has a dns resolver, so it may not do 3.2, but it may do 3.1 and the behavior depends on the OS socket stack. But going direct to DNS (3.1) is generally the right way.

Either way, EHLO.FIELD can end up being validation incorrect.

It required two things, either a relaxation at wcSMTP or the MUA has a manual way to set the ip-literal for the NAT.

I don't fully recall the widely tested MUAs, but the popular ones like OE used the machine's netbios name. It probably only did 3.1 and I never saw it used #4 to set an ip-literal. Since I using Thunderbird, it did use #4 and I issued a report to the Thunderbird guys to add an option to offer #2. I assisted with the suggested C/C++ changes to the EHLO command function.

But that would be a manual configuration the MUA user had to be familiar with because with TBIRD there was no "first time setup, What is your NAT address?" popup configuration. With the change, you had to use the "config://" url.

The impact was seen mostly with the submit protocol where the MUA's MTA issued a private-ip-literal, and of course, it would not match the NAT's public ip and wcSMTP would filtered it.

So the way I approached the  problem was:

Overall, in wcSMTP, client authentication ruled to bypass these new extended wcSMTP checks.

- With Public Port 25 access, the helo/ehlo ip-literal check is done. Admin has option to disable it. If the connected IP was authenticated, via a IP relay table or via POP3 B4 SMTP method, it was skipped.

- With Private Port access (port 587), the EHLO ip-literal check was skipped because Authentication was expected after EHLO.

I recall sending an implementation note to Klensin and Gellens explaining the "MUA behind the NAT" problem and the suggestion to relax any EHLO validation now authorized by RFC4409 because ESMTP AUTH was now expected and required.

Now, you may say that 'if the sender
is on a dynamic IP we don't want to receive mail from them', and
that's a valid viewpoint, but I'm not sure the SMTP standard should
prohibit SMTP senders being on dynamic IP addresses.

I agree.


ietf-smtp mailing list

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