From: "Aaron Konstam" <akonstam@xxxxxxxxxxxxx>
On Mon, 2007-07-30 at 19:40 +0930, Tim wrote:
In my experience, it's rather bad. I see quite a few false positives,
and a lot of spam getting through. It can be trained better, but
that's
hard for me to do if I run it where it needs to be run - on the
(remote)
mailserver, hosted by someone else who only give me limited control.
Most of the un-marked spam that I see rarely has enough points to
qualify, so it's hard to train effectively, anyway. I've yet to see a
hosted mail server doing spam assassin well. There probably are some
expensive ones that manage it, but I'm not going to use an expensive
mail service.
This is a fundamental issue with using something like spam assassin:
It needs to be run on the SMTP server, as an INPUT filter, so that
spam
gets refused before entry, with a notification as part of the SMTP
transaction. That way, the sender (the actual sender, not just the
address in the "from" header) gets notified that the message wasn't
accepted, and a genuine sender can try again in a manner that doesn't
get rejected (e.g. without HTML, or an attachment, or other things).
Otherwise, if they're not told, they think you got their mail, and
they
didn't. That's a serious problem if you try to conduct any business
through e-mail.
If you run it locally, your external SMTP server has already accepted
the mail, it's too late to reject it. People who mailed you and
accidentally got filtered out as spam have no idea. And, you have to
filter a lot of mail yourself. Not to mention havi thng to check the
junk
mailbox, yourself, which defeats the purpose of running an anti-spam
system.
You are asking a lot form a spam filter. But let me share with you this:
1. For the first time spamassassiin really works with evolution in f7.
I get no more that 1 spam message a week out of maybe a 1000 messages.
I always suspected you of masochism, Aaron. {^_-} Don't use it as a
filter inside an MDA. Use it via fetchmail, procmail, and dovecot. You
do not perceive the 2 to 5 seconds SA spends scanning the messages that
way. And that makes it easier to live with.
2. It is impossible to run a spam filter without checking the junk
folder since you will lose a few files that you wanted to see. Training
in this regard is everything.
It is quite possible to do it. It is foolish to do it if there is a
chance that you will get some very important but spammish looking
email. A quick check for false alarms with SA scoring setup to report
up to three digits of score in the marked up subject line allows for
a VERY quick search by sorting the subjects.
rewrite_header Subject *****SPAM***** _SCORE(00)_ **
3. Asking your spam filter to notify the spam senders is crazy. Why
would I want all the cialis vender's and Nigeria con men to know their
mail did not get through.
Bluntly put a SendMail level rejection is fine but anything that goes
to the "From:" line WILL get your address block listed as a spam site.
4. I guess being a New Yorker I have a thicker skin. I have never gotten
a message from a crazy that I felt would damage my equilibrium. If one
appears I put him in my blacklist and he disappears.
Heh, those guys go on my .procmailrc /dev/null list. Why waste any more
CPU cycles on them than necessary? {^_-}
The real thing is communication channels are designed to communicate.
And some communication does not belong on a public list. To tell people
they can't communicate with you except if they know the secret code word
to me is rude. I have no good examples in e-mail communication but If I
could e-mail you directly to give you examples why having an unlisted
phone number can be between disastrous to life threatening in some
situations.
When I get a bounce for a challenge/response or for a missing magic word
that address goes into my /dev/null list so I don't get bothered again.
That is where a certain misbehaving major service in Brazil finds a lot
of its mail going.
But since I can't communicate with you off the list lets drop the
subject.
Better yet - /dev/null the nonsense.
{^_-}
