[prev in list] [next in list] [prev in thread] [next in thread] 

List:       spamassassin-users
Subject:    Re: spamcop.net tactics
From:       List Mail User <track () Plectere ! com>
Date:       2005-11-24 4:36:12
Message-ID: 200511240436.jAO4aC3n029785 () Plectere ! com
[Download RAW message or body]

>...
>On Wednesday, November 23, 2005, 3:33:47 AM, Leonard SA wrote:
>> Hello,
>
>> I have had to remove spamcop from my rbl check list. they have had some 
>> legitimate mail servers listed recently. They had the gentoo mail list 
>> listed and some other important servers which i cant see why they were 
>> added.
>
>> Regards ..
>
>> Leonard
>
>If you mean at the MTA level, yes, I don't use bl.spamcop.net in
>my MTAs.  For SpamAssassin, however it's useful as another
>somewhat reliable indicator of spammyness to increment the scores
>a bit, just like SORBLs or SPEWS, which would otherwise be
>largely unusable for outright blocking in an MTA for most
>people.
>
>SpamCop's bl gets IPs that users report.  There's some filtering
>and munging, but it's either less than one would like or more
>than one would like, depending on one's perspective.  IOW some
>SpamCop user (unwisely) reported a gentoo mailing list message as
>spam, and that's why it got onto the blacklist: user error.
>
>Jeff C.
>-- 
>Jeff Chan
>mailto:jeffc@surbl.org
>http://www.surbl.org/
>

	It is not an available option to everybody;  I depends on your
MTA and other parts of your environment, but if you can, '"450"'ing on
the SpamCop blacklist catches a lot of zombies, open relays, etc. before
they hit the other lists (XBL, CBL, etc.), and the policy of relatively
rapid auto-delisting makes almost certain that "real" mail isn't lost,
just delayed.  At least for Postfix, this is quite trivial (i.e. directive
"defer_if_reject"); For sendmail, it is more than one line, but not much
harder (I don't know most other MTAs well enough to be the person to say
what the "easiest" method should be, but I can already see an easy equivalent
means for Exim too).

	Paul Shupak
	track@plectere.com

[prev in list] [next in list] [prev in thread] [next in thread]