--On Monday, December 23, 2019 18:24 -0500 Sam Varshavchik
<mrsam(_at_)courier-mta(_dot_)com> wrote:
...
Peter J. Holzer writes:
The discussion did however strengthen my belief that the
paragraph from section 4.1.4:
...
ought to be deleted. Not to legalize what the IETF admin did
- that's already fine - but what you did.
No, it should be deleted because it will be ignored, in
practice. It is very easy to understand why.
The reason you see various places doing this is because it
works for them. As simple that. They've reached the conclusion
that this check blocks a bunch of crap with negligible, if any
at all, impact on their non-spam mail traffic.
However, no SMTP server I'm aware of does this by default, in
its stock configuration.
Sam,
I want to get an oar in the water about an alternate point of
view, not because I'm convinced it is the right one but because
the conclusion you describe above may be problematic.
_Any_ envelope-level spam filtering technique other than, maybe,
specifically identifying a particular bad actor and rejecting
mail from them, is going to be subject to false positives --
legitimate messages that are incorrectly rejected. Anyone who
reaches the conclusion you describe, whether they understand it
or not, is making the decision that losing some number (a number
that is actually very hard to estimate accurately) of legitimate
messages is ok if it makes a big dent in the spam. That is ok,
but it doesn't work well in environments in which reliable
delivery, i.e., not losing legitimate messages, is important.
And, in situations where it counts, the task of a mail
administrator who has to explain to her boss's boss why a
message from an important customer was rejected and didn't get
through is, well, not enviable.
Of course, if said boss's boss gets a spam-delivered phishing
message and stupidly responds to it in a way that puts the
organization at risk, having to explain why that was allowed to
happen is not likely to be much fun either (see "disclaimer" at
the end).
If one decides to block attempts to open SMTP sessions by
rejecting IP literals at EHLO time (a singularly blunt
instrument, even more blunt, IMO, than rejection based on IP
address ranges, there are also two ways of doing it. One is to
return a 5yz code in response to the EHLO, thereby rejecting all
messages using such syntax regardless of origin or destination.
The second is to wait until the MAIL command, or maybe even one
or more RCPT commands, are received, thereby allowing
whitelisting if there are particular cases one wants to allow.
In the particular case of the IETF servers and posted anti-spam
policy, that would allow an IETF participant with special
circumstances to argue that their mail traffic should be
accepted even if they are somehow restricted to IP address
literals in EHLO. I read the policy statement as requiring that
there be a possibility for such exceptions; others may not. For
other lists and operators, if we were going to drop IP address
literals (a feature that has been allowed and supported for more
than 37 years, much longer if one counts email over FTP), I
think we have some obligation to explain why we are doing that
and just how to do it, including the tradeoffs.
I have quibbles with the analysis in the rest of your note, but
prefer to see them worked out in more extensive discussion than
to write a longer message now.
john
Disclaimer: At the risk of saying something that some will
construe as political, while I understand the need for spam
filtering at or near the recipient end of the mail flow, I fear
that we are not doing ourselves or the Internet any favors by
getting incrementally better at it. In the current model, the
higher a percentage of spam we intercept at the receiver end and
prevent from reaching the user, the more the spammers have
incentive to increase their output volume as well as their
technology for bypassing our filters. The combination drives up
costs to mail service providers and creates more incentives for
concentration. If there is a solution to spam, it is almost
certainly lies in general recognition of spamming as an
antisocial act and the creation of social, legal, and financial
disincentives to spamming. That recognition will probably never
come as long as we are successful in preventing enough of it
from reaching legislators and their active constituents so that
they don't feel significant pain. I'm not quite serious about
this, but, if one wanted to really stop spam by making life
painful for the spammers, the most useful possible step might be
to declare a "let all of it go through to the end users" week
every once in a while.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp