RE: [sa] Re: SMTP REJECT after DATA (was: SpamAssassin Milter Plugin...)
Now THAT is off-topic. We are discussing the use of SA at SMTP time. Please stay on-topic for this group, and for this thread. If you actually care to continue, I expect a reasonable response to my arguments about rejection being better than bouncing or silent diversion. Geez, you didn't even try to advocate a system of notices to the user to overcome the 'silent' portion of that argument. Do I have to argue both sides for you? :) - C Charles, with all due respect and in right spirit you know way too much for anyone to have an argument with you... if you cannot implement all processing and reject in DATA phase, then well... there it is... work on it... your next post says you sometimes have to reject after... and i quote you --- Charles Gregory Quote:Re: [sa] Re: SMTP REJECT after DATA The only efficiency to be gained is to reject as much as possible after the RCPT_TO, before accepting DATA. But for systems like mine, with lousy user cooperation, rejecting some of the mail after DATA is still the best option. --- i would say you are arguing both sides and that it might be the issue. i would tend to believe that most have made the choice not to straddle the fence are you blaming the users for your administration? ;-) - rh
Re: SMTP REJECT after DATA (was: SpamAssassin Milter Plugin...)
On Wed, 10 Mar 2010, R-Elists wrote: Charles Gregory Quote:Re: [sa] Re: SMTP REJECT after DATA The only efficiency to be gained is to reject as much as possible after the RCPT_TO, before accepting DATA. But for systems like mine, with lousy user cooperation, rejecting some of the mail after DATA is still the best option. i would say you are arguing both sides and that it might be the issue. I'm arguing that with such a strong component of YMMV there is NO side in this debate that is so woefully wrong as to be labelled 'misguided', which is what I was responding to in my first posdt in this thread. i would tend to believe that most have made the choice not to straddle the fence I made my own choice, as outlined above, but 'sit on the fence' with regard to my opinion on 'best practice' or 'misguided decisions', because I don't belive there really is any one 'good' or 'bad' decision (except maybe the decision to backscatter, but we all agree that is 'bad'). are you blaming the users for your administration? ;-) Naturally. All good adminsitration is customer driven. |-D - C
SMTP REJECT after DATA (was: SpamAssassin Milter Plugin...)
On Tue, 9 Mar 2010, Kai Schaetzl wrote: Second: you are completely misguided in your wish to reject mail after SMTP data stage. You may certainly argue for YOUR preference (and I emphasise *preference*) for the most 'efficient' way to run an SMTP server, but there is nothing sufficiently 'wrong' with rejecting mail after DATA that you can use the term 'misguided'. All this term implies is your attitude Apart from this, you make some nice arguments, but again, you seem to have a bias that weighs them too heavily. It does not make any sense to process a complete message and then reject it. If this were true, no one would have added 'header' and 'body' checks to the postfix configuration and no one would have been jumping through hoops to find ways to integrate SA into the front end of MTA's Indeed, it makes far LESS sense to have a system accept mail but send it to a spam folder. That practice leaves the sender with the mistaken impression that their mail was sucessfully delivered. And argue as you will, there is simply no way to get a broad user base to adopt the habit of reviewing a spam folder. I mean the whole point of filtering is that the user no longer has to sift through a pile of junk, right? Processing a message takes CPU power and precious SMTP time. Doing that at SMTP stage means you cannot take in as much mail as you could. It also means that the sending MTA cannot send as much mail as it could. Think about that statement twice. It IS correct, but it is an argument FOR processing mail at SMTP time. A legitimate outbound SMTP sever is *never* as busy as an incoming mail server. So a leigitimate server will not suffer *any* penalty from my system introducing a 5-6 second delay into the SMTP transaction. But a spammer's zombie is trying to pump out mail as fast as it can. The spambot will be slowed down. That is a GOOD thing. Yes? :) There are other reasons not to do this, for instance legal ones. Again, you are quoting arguments that favor SMTP reject. It is better to reject a mail, so that legitimate senders know it, rather than have them believe it was delivered when it was sent into a spam folder, perhaps suffer consequences and then sue the recipient. Sure, OUR butts will be covered by our user agreements, but only if we have jumped through hoops so that the user cannot claim they did not know about their spam folder. But in the real world, even if we don't get sued, we get a lot of people complaining that they didn't know about the optional spam folder on our system that the user turned ON themselves! Now we use a spam folder for 'borderline' spams that score 5-10. The rest get rejected at SMTP time. But still I get these occasional complaints It's just the way users are LOL The idea is not to punish the other side because it sends spam. If they send spam, I'm happy to see them punished. If they send legitimate mail, they should not be punished for the actions of spammers by having to GUESS whether their mail made it through. The idea behind a rejection at SMTP stage is twofold: avoid unnecessary processing and avoid unncessary traffic. None of that is achieved if you take a whole message, scan it and reject it at SMTP stage. Well, firstly, ALL of that is achieved *regardless* of these arguments because the helo/rbl checks are done BEFORE the DATA stage. The only 'loss' of time is on mail that you were going to have to fully process anyway because it made it past those checks. No loss to me. A few seconds delay on the SMTP connectino that saves a legitimate sender worry without incurring the 'cost' of backscatter, and actually might slow spammers down a bit. Maybe I personally don't gain any time. But maybe by the end of the day the spammer doesn't get to send quite as many e-mails, and someone out there enjoys less traffic on their server! - Charles
Re: SMTP REJECT after DATA (was: SpamAssassin Milter Plugin...)
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. It makes only sense if you are die-hard spam-fighter who wants to retaliate and doesn't bother if it makes sense. And that is indeed very misguided. Most if not all of your arguments are arguments for spam-filtering mail, not in favor of rejection at DATA stage. 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 - which often have nothing to do with spam/malware detection at all. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: SMTP REJECT after DATA (was: SpamAssassin Milter Plugin...)
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.
Re: [sa] Re: SMTP REJECT after DATA (was: SpamAssassin Milter Plugin...)
On Tue, 9 Mar 2010, Kai Schaetzl wrote: and you find it doesn't make sense to spam-scan messages and reject them in/after DATA stage in a real world scenario. You ignore my arguments. Hardly surprising. You reword yours, but say nothing new. It makes only sense if you are die-hard spam-fighter who wants to retaliate... I stated my objectives and they have nothing to do with this pathetic straw-man argument. Most if not all of your arguments are arguments for spam-filtering mail, not in favor of rejection at DATA stage. How is that English-as-a-second-language class coming along? I refuse to bore this group by repeating arguments that you so grossly mis-categorize in a feeble attempt to promote your point of view. 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 - which often have nothing to do with spam/malware detection at all. Now THAT is off-topic. We are discussing the use of SA at SMTP time. Please stay on-topic for this group, and for this thread. If you actually care to continue, I expect a reasonable response to my arguments about rejection being better than bouncing or silent diversion. Geez, you didn't even try to advocate a system of notices to the user to overcome the 'silent' portion of that argument. Do I have to argue both sides for you? :) - C
