On Tue, 2007-07-31 at 19:26 -0700, jdow wrote:
> 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.
>
Joanne,
I would agree with you with evolution on versions before f7. But under
f7 spam checking under evolution works like a "house on fire". And it is
somewhat simpler then dealing with 2 or three other programs just to get
the spam checking done.
As far as checking spam for false identifications your system may work
but the dependence on the spam value as an indicator of real spaminess
is a little too speculative for me. Although, theoretically you would
think it might work,
--
=======================================================================
Comparing software engineering to classical engineering assumes that
software has the ability to wear out. Software typically behaves, or it
does not. It either works, or it does not. Software generally does not
degrade, abrade, stretch, twist, or ablate. To treat it as a physical
entity, therefore, is misapplication of our engineering skills.
Classical engineering deals with the characteristics of hardware;
software engineering should deal with the characteristics of *software*,
and not with hardware or management. -- Dan Klein
=======================================================================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@xxxxxxxxxxxxx
