Bill Farina wrote: > I'm not certain if I'm getting what you're saying here, but as I > understand it, deleting spam upstream without allowing the recipient > to peruse it is a bad idea. > > Everybody's mail is different and will require different spam rules. > Spam filtering is fallible. I run PopFile for my filtering and it's > wonderful. It's accuracy is 99.86%. Sometimes messages that I want to > see still get filtered into spam and vice versa. PopFile allows me to > train it for my personal mail preferences. Upstream deletion can very > probably mean that valued messages will be deleted before the end-user > gets a chance to judge them. > > ----- Original Message ----- From: "A.N.Other" <zzz2...@gmail.com> > Newsgroups: mailing.postfix.users > Sent: Monday, December 15, 2008 11:25 PM > Subject: Header & body checks among other things!! > > <snip> >> Why defer killing spam, why not kill it ASAP and save spending anymore >> resources processing it? > <snip> Our principle spam checks are spamhaus, spamcop and greylisting and our philosophy is that if you fail these your toast. Once you get passed these we use amavisd-new and spamassassin to filter the rest. The only one of these that is, in my opinion, somewhat suspect is greylisting as there are some MTA that don't obey the rules about deferred delivery. Postgrey, and I assume other packages, has a whitelisting facility and it comes with a fairly comprehensive preconfigured whitelist.
My original question was not what anti-spam measures to take, but when to apply them. My original thought was to kill off that which did not pass the RBL checks could/should be killed off as early as possible, at the client/HELO stage, thereby avoiding "unnecessary" processing, but the kind folks on postfix-users pointed out that some MTAs will not take no for an answer before the RCPT stage and that the default behavior of Postfix was to defer the processing of client and HELO until RCPT-TO. As a result of their helpful input I modified my setup as suggested and everything seems to work just fine. Other than a couple of misconfigured MTAs with HELO names like "fred.sn.local." or "mail.abc.com.abc.com.abc.com." or the MTA that forwarded the 450 deferral to the sender as a bounce message, we don't seem to have had many problems. I think my real problem is that having been out of the IT business for about ten years I am having to re-learn the ropes, which means that I ask some pretty dumb questions on occasion. I can only hope that the people that get answer them understand how much I appreciate their help. JLA
