On Tue, Mar 9, 2010 at 08:03, Kai Schaetzl <mailli...@conactive.com> 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 snake-oil salesman. 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 conclusion. > It makes only > sense if you are die-hard spam-fighter who wants to "retaliate" and > doesn't bother if it makes sense. Bzzt. Wrong. 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 "create backscatter". 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.
