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

[Keith Moore <[e-mail]>]

Sorry, there's a piece of this that I neglected to address in my earlier 
reply:

On 9/18/20 6:36 PM, Sam Varshavchik wrote:
>
> Courier has an optional setting that can be enabled, that verifies 
> that "the domain name argument in the EHLO command actually correspond 
> to the IP address". I have it enabled. It's one of my most successful 
> spam filters. It's very valueable to me. It's possible that there were 
> one or two instances in the last 25 or so years when I found out that 
> this rejected something that wasn't junk, but I don't immediately 
> recall a single one. I'll stipulate that there might've been one or 
> two times, and that's a pretty good record.
>
I didn't intend to dismiss or ignore this input.   I believe you when 
you say it's been a good spam filter for you.

At some point in the past, this was _not_ a reliable spam filter.    To 
me the fact that it works as a spam filter today seems like mere 
circumstance or accident; I don't see any inherent reason that it will 
be a reliable spam filter going into the future.   Spammers do learn, if 
slowly, so if they have to learn to make sure their EHLO arguments match 
their source IP addresses, they'll do that.   In the long term, I don't 
think this check helps anything.

SMTP has been around for nearly 40 years now (close enough to round 
up).   Are we intending this standard to be applicable for decades past, 
only today as a snapshot in time, or decades into the future?   I would 
argue that it's the latter, and that SMTPbis should make recommendations 
that there's reason to believe will hold up over time.

Separate from all of this, there is an emerging set of (as far as I 
know) largely-unwritten "rules" for how to make your outgoing mail 
appear legitimate enough so as to not get flagged by spam filters as 
often.   This is a mess because most of those "rules" are basically ad 
hoc and not based on any long-term reliable indicators of message 
legitimacy.   But these rules seem certain to keep changing, so IMO it 
makes sense to keep them out of the (hopefully long-term stable) SMTP spec.

Keith