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.
http://www.winserver.com/public/aup/wcGeoIp-Location-Filters.htm
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.
Keith
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp