[Top] [All Lists]

Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321

2020-09-27 20:26:30
On 9/27/20 8:51 PM, Richard Clayton wrote:

Hash: SHA1

In message 
Keith Moore <moore(_at_)network-heretics(_dot_)com> writes

But this is a silly discussion.
It seems backwards from where it started ... which effectively came down
to what would be good advice to proffer to a client to ensure that their
email deliverability improved.  The good advice "why don't you make sure
that forward and reverse DNS match up and say EHLO in a consistent
manner" is difficult (as has been pointed out) for some clients to
follow ... and that's why IMO it ends up as a SHOULD rather than a MUST.

I thought it was about advice to the server which is currently that the server MUST NOT refuse to accept a message based on failure of EHLO argument verification.

My argument is that EHLO verification is, in the long run, poor practice and should not be encouraged by 5321bis /even if it seems like an effective spam countermeasure today./   There are various reasons for this, but probably the most salient is that the need to support mail sending from some IPv6-only networks, and eventually to no public IPv4 Internet, makes any expectation that the client knows what DNS name will result from a PTR lookup of the client's source address as seen by the server, to be dubious at best and perhaps completely meaningless.   Since we expect 5321bis, as a Full Standard, to be long-term stable, it doesn't make sense to promote a practice that seems dubious or even harmful to mail reliability in the long run.

(I'm open to other ways of rewording the language currently in 5321, as long as it takes into account the fact that in a world where communications between IPv4 hosts and IPv6 hosts is mediated by NATs supplied by carriers, a client no longer has a reasonable expectation of knowing what its source IP address will be as seen by the server, or of having control over the PTR records in the corresponding DNS zone to that source address.   What I don't think is reasonable in the long run is to expect all SMTP clients to have direct access (and their own static addresses) on both the public IPv4 network and the public IPv6 network.)

I certainly acknowledge that spam
filtering is hard, and that the state of the art is to use unreliable
I would disagree ... state of the art is ML clustering algorithms using
a wide range of signals, where even the people who developed the systems
find it fairly hard to reliably predict beforehand which of those
signals are going to be of real significance.

Thanks for the clarification.   I agree that it's useful to distinguish ML algorithms from heuristics.

This does bring a tangential question to mind, though:

Since the only practical way of tuning these algorithms is end-user

To me it seems like a very important case where reliability is concerned is when a willing sender (who has not previously received mail from this recipient) tries to send their first email to a willing recipient.    If that doesn't work, the sender and recipient may simply give up, but whatever they do, they're shooting in the dark.

If end-user feedback is already difficult to get (and I acknowledge that it is), it seems like measuring this critical case and tuning ML algorithms based on this case would be extremely difficult.


ietf-smtp mailing list
<Prev in Thread] Current Thread [Next in Thread>