[Top] [All Lists]

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

2020-09-26 21:00:24
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.


ietf-smtp mailing list