[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Anoying Peter Whalley Spam messages.



On Apr 4, 2005 12:06 PM, Scot L. Harris <webid cfl rr com> wrote:
> On Mon, 2005-04-04 at 12:41, Gustavo Seabra wrote:
> Besides that TMDA systems is not a good solution for fighting spam.
> greylisting at the MTA and spamassassin will block 99%+ of the spam out
> there and does not require the additional network bandwidth and handling
> that TMDA systems do.
> 

Actually TMDA works, if it is used correctly. If you filter through
the RBLs and other sanity checks that most good MTAs can do (rejecting
bad HELOs and rejecting spoofed domain information) and then go
through spamassassin, and then whatever is left goes to TMDA... it's
really not that many messages that get challenged. Especially if the
user has configured his whitelist properly.

I have been using TMDA on one of my other accounts since March 15,
2003, and since then, I have received a total of 6 spams. Over 114000
have been blocked by the first methods, and another 13400+ were
blocked by Spamassassin. The remaining 1300+ that passed those checks
were from spammers not responding to TMDA challenges. The six that got
through were because spammers used real e-mail addresses and got the
challenge messages and then responded to them.

I think that as long as people will make a lock, someone else will
find a way around the lock, so no matter what is used. And then you
will have a slew of people who flame the person who made the lock.
Yes, I use TMDA, and I have never had a complaint from anyone who had
to respond to my challenge message. Why? Because I use it properly,
and don't annoy the hell out of people I want to communicate with.

But in this case, the guy apparently has no clue about how to set his
list up. In fact in the challenge message it even has a line at the
bottom that says that if you continue to receive messages to tell the
user to add to his authorized list. Why should that be a problem for
the recipient to take care of instead of the user.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]