[Top] [All Lists]

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

2019-12-31 12:23:49
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.


[*] 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
<Prev in Thread] Current Thread [Next in Thread>