On 12/31/19 12:33 PM, Hector Santos wrote:
I have two SMTP compliancy-based deterministic filters:
- Machine name ip-literal matching connecting ip because SMTP tells us
it is defined as the IP address of the connecting client, and
This is something that should be clarified in 5321bis, IMO. The IP
address literal is the address as seen by the client, which in an IPv4
world with increasing numbers of NATs can't be guaranteed to be the
address as seen by the server. And as long as people keep using IPv4,
there will be NATs in the middle of the network.
So if an IP address literal is used in HELO/EHLO, it MUST (or at least
SHOULD) be the source IP address of the current TCP connection as seen
by the client. The HELO/EHLO tag will then get copied to a Received
header field. But because of NATs, servers therefore SHOULD NOT (maybe
MUST NOT) refuse mail based on whether the EHLO/HELO address matches the
peer address. (The only case I can think of that makes sense for
rejecting such mail is if the server somehow has reliable out-of-band
information that the client is lying about its address. It's not
impossible, but it's difficult to imagine how this could happen.)
And while clients SHOULD use a DNS name in HELO/EHLO if they have one,
not all SMTP clients can be expected to have a DNS name. So servers
SHOULD NOT (maybe MUST NOT) reject mail based on the mere presence or
absence of an IP address literal in HELO/EHLO. It would be insane for
a standard to make a recommendation that degrades the reliability of the
service it provides.
Having said that, if a server operator /reliably/ knows that use of an
IP address literal in HELO/EHLO is /currently/ a /reliable//indication/
of spam, it might make sense to filter based on that use. The keys are
in /reliably/ knowing that, knowing that it is a /reliable indication/,
and knowing that the indication is /currently/ reliable. The operator
might also have other information of use - such as knowing the community
of people who can legitimately send mail to the server, and how they
configure their servers [*]. If an operator knows those things, then
the rejection is not based on the "mere" presence or absence of an IP
address literal - it's based on other information also.
But reliably knowing these things requires work and tools, and keeping
that information current also requires work and tools. I wonder how
much spare time operators have to do the necessary work to make sure
that the indicators are reliable, and I wonder if the tools that they
need to do this are readily available to them. I don't know how much
of this should be in scope for 5321bis - probably none of it - but this
does seem like part of what's required to improve the reliability of
email delivery.
Keith
[*] But is using an SMTP forwarder that has a DNS name really part of
the price of admission to IETF discussions? And if so, shouldn't that
be explicit policy rather than just the ad hoc decision of a server
administrator?
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp