|Main Archive Page > Month Archives > spamassassin-users archives|
On Tue, Mar 9, 2010 at 08:03, Kai Schaetzl <firstname.lastname@example.org> wrote:
> Charles, just a quick answer as we are really OT.
> It all simply boils down to (quoting me):
>> avoid unnecessary processing and avoid unncessary traffic.
> and I might add now: with the least disadvantages on both sides.
> Assess that and you find it doesn't make sense to spam-scan messages and
> reject them in/after DATA stage in a real world scenario.
To you. Not to everyone who does the analysis. We all have our valid
biases, our valid assumptions (that follow from both those biases, and
from our locally defined goals and objectives that come from business
cases, theory, etc.). They do not promote a single unified opinion
about the best way to approach these problems. Anyone who says they
have a single, one size fits all, solution to that analysis is a
For example, there are actually some people on the planet that
intentionally silently drop email messages. It's like they WANT their
email servers to be defective-by-design. Clearly, their local
analysis derived a different conclusion than any intelligent person's
> It makes only
> sense if you are die-hard spam-fighter who wants to "retaliate" and
> doesn't bother if it makes sense.
It's for anyone who wants to reject messages, so as to reduce the
amount of crud that they are storing, backing up, handling/tracking,
and/or quarantining. The other options for that goal (bouncing,
silently dropping) are not acceptable.
Rejecting after SMTP (bouncing): backscatter, bad idea
Dropping messages silently: RFC violation, and thus
defective-by-design mail service
Rejecting before accepting (during SMTP): proper behavior for handling
messages for which you don't wish to accept responsibility
> And that is indeed very misguided.
Retaliation is misguided. Spam scanning during the SMTP session is not.
> Most if not all of your arguments are arguments for spam-filtering mail,
> not in favor of rejection at DATA stage.
I don't need to make arguments for/about rejection vs filtering. I do
what makes the most sense to my local case. And I obey RFCs and
decent net behavior. I only answer to outside agencies for the latter
2 (RFC compliance and net behavior). I do not answer to outside
agencies for "what makes the most sense to my local case", therefore,
I have no requirement to make arguments about rejection vs filtering,
as long as I am RFC compliant, and do not do odious things like
In my local case, we reject messages for which we have a very high
degree of confidence about the likelihood that a message is
spam/virus/phishing/etc. We do RBL rejection during the SMTP session
(for RBLs that we feel are reliable, within our comfort zone of
reliability). We do ClamAV scanning during the SMTP session (using a
variety of ClamAV signature sources, again within our comfort zone of
reliability). And we do SpamAssassin scanning during the SMTP session
(rejecting messages that score above a certain threshold; merely
tagging messages under that threshold -- and that threshold is, again,
set by our comfort zone of reliabilty).
> Last, keep in mind that filtering mechanisms in whatever stage are not
> solely meant for rejecting or spam-fighting, they are for *filtering* and
> then assigning appropriate actions
And one of those appropriate actions can be "reject the message".
As I suggested above, if you don't do the scanning during the SMTP
session, then you can't reject the message. You can only bounce it
(causing backscatter), drop it (making your mail server defective), or
deliver it (to the inbox, or to a quarantine). Not everyone wants to
store, backup, and handle lots of crud ... nor do they all want to
manage (and, typically, pay for) a quarantine system ... or they want
to reduce the crud that they store, backup, handle, and/or quarantine.
The only acceptable (to those of us who care about RFCs and proper net
behavior) mechanism for doing that: reject it during the SMTP session.
If you don't care about reducing the load of crud you deal with it,
fine. That's your local consideration, and is by no means a
universal, nor superior, conclusion. It is not misguided, nor bad
analysis, to come to a different conclusion.