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

[Keith Moore <[e-mail]>]

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?