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

[Keith Moore <[e-mail]>]

On 9/27/20 8:51 PM, Richard Clayton wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In message <[e-mail]>,
> Keith Moore <[e-mail]> 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
>> heuristics.
> 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
> free-back

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.

Keith