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.
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp