Hello Privateofcourse,
Monday, June 15, 2009, 4:22:48 PM, you wrote:
> I've done a bit of leg work, but it seems to me that the majority of
> so-called 'SPAM blocker/stopper' solutions don't and can't really do
> anything other than allow you to manage SPAM after-the-fact. That is, SPAM
> isn't actually blocked or stopped at all, but is managed after it has been
> received.
Well, yes, that's exactly what you have to expect *if* you want to
deal with spam on the MUA (i.e. TB!) level. You can't really expect
your email program (which typically is completely separate from your
mail server) to decide which emails need to be accepted and which
need to be rejected.
> But nonetheless, I suspect that for some this is better than
> nothing at all.
Agree.
As for me, I used to use AntispamSniper for some time (and BayesIt!
before that). The main drawbacks were:
- severe limitations on using encrypted connections to the server,
- me wanting to access an acount from more than one PC -- this did
not fit nicely with the idea of client-side filtering,
- me deciding TB! was too unreliable and switching to IMAP account.
For reference: my current setup is a mail server (Postfix + Dovecot)
which has SpamAssassin process incoming emails. SA only flags these
emails (adds rating information to header). Then, a Sieve script run
by Dovecot does the actual actions: suspected spam is moved to Junk
folder; if it's obvious spam it is additionally marked as Read.
So, as for checking for false positives: from time to time I can
review all messages that have been marked as spam, and, on a daily
basis, I see the ones that were not marked as Read (i.e. not
obvious).
The lessons learned here are:
- this works independently of the MUAs I use to access my email base
(I use more than just TB!),
- SA is far more thorough than any client plugins (it offers more
checks, the rules are updated often, etc.),
- this is a part of a bigger filtering scheme; the filtering happens
on server side and I am not forced to rely on TB!'s extremely
unreliable filtering; the individual email automatically get
dispatched into proper folders.
- I *could* implement a true spam rejection scheme by enabling e.g.
greylisting in Postfix but the current setup works so well that I
don't feel the need to do so.
One wish I have would be for TB! to allow assigning Junk folder to a
server folder -- please support my wish here:
https://www.ritlabs.com/bt/view.php?id=6483
So much for the description of my setup. It probably won't help you
or your friends/ family but should allow you to set the expectations.
You always can:
- use an email provider that has reasonable filtering (e.g. GMail),
- try to use something like AntispamSniper to filter spam.
Also, I think that trying to write your own set of rules for TB!'s
filter mechanism is bound to fail. This might allow you to filter out
a significant part of spam volume but in practice, if you get 100
spam messages per day instead of 300, does it really help you?
--
Best regards,
Robert Tomanek mailto:[email protected]
________________________________________________
Current version is 4.2.6 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html
