[Top] [All Lists]

Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version

2019-12-23 12:44:40
On 12/23/19 12:59 PM, Hector Santos wrote:

Do you believe a backward compatible ESMTP solution is possible along the lines of a connection response preempting the need to use EHLO?

I believe that any SMTP solution has to be backward compatible, so incompatible solutions are non-starters.   At the same time I think there may be room to "pessimize" processing of certain kinds of traffic in order to encourage senders to upgrade.  (e.g. return "4xx try again later" in response to MAIL or DATA, at random, with probability < 1 but possibly increasing over time.)

I'm still not convinced that there is any "need" to use EHLO tags in spam filtering because the EHLO tag says absolutely nothing about the message content or even about whether the sender is misrepresenting itself in order to hide something.   (Or at least I don't see a reliable way of testing the EHLO tag to determine from the server's environment, whether it's valid in the client's environment.)   From a standards perspective I still think it makes sense to discourage use of the EHLO tag for spam filtering (maybe SHOULD NOT rather than MUST NOT), but also to explain why use of EHLO tags for that purpose is a Dubious Idea.

In December 2018, I released an major update that included Geo IP Location filtering.

The idea is simple: IF your operation, business, etc, absolutely has no expectation to be doing business or communications with particular countries,  nations or regions of the world, wcSMTP can immediately filter by GeoIP Location at the connect level.

I think it's useful to think of spam filters in two categories:

(a) stopgap countermeasures which may make sense in the short term and for specific conditions,  vs. (b) countermeasures that make sense in the longer term and are broadly applicable.

I agree that sometimes the stopgap countermeasures are necessary, but I think it's important to distinguish the two and periodically review the stopgap measures to see if they're still applicable. Today, perhaps, a business may have no expectation of doing business with clients in particular countries.  But that may change in a year or two, at which point a filter that blocks inbound mail from Elbonia becomes harmful to the business.

Also, a country-specific block may make sense for some sites, or some users, but not for others.    Different users have different needs.   Different sites also get different amounts and kinds of spam.

Another consideration is that some kinds of filters are very easy for spammers to circumvent, and spammers are sometimes more nimble than operators.   So if you're choosing how to filter a particular kind of spam, it might be prudent to pick a filter that is harder to circumvent over one that is easy - that may mean you have fewer fires to fight.   If spammers can easily hide their tracks using botnets or other traffic laundering measures, country-specific blocks on source IP address may not be useful for very long.

The very nature of the IETF consensus process and the RFC publication process, with their inherent delays, means that IETF will have a much harder job documenting long-term countermeasures than stopgap countermeasures.


ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>