RE: IMPORTANT: your message to html-tidy
Karsten M. Self <kmself@ix.netcom.com> wrote:
> [Using DNS RBLs to block spam is bad.]
> As many people have noted, for pretty much _any_
> given IP, your odds are good that most of the mail received from it is
> spam. It doesn't do much for the legit mail that comes through. Given
> that we now _do_ have good content/context based filters for assessing
> spam likelihood for a given mail item, blind use of RBLs should be
> discouraged. It's the same sort of thinking that's causing no end of
> trouble for people trying to communicate with AOL users:
>
> http://z.iwethey.org/forums/render/content/show?contentid=96264
> http://yro.slashdot.org/yro/03/04/13/2215207.shtml?tid=120
No, you can't make such a general statement that using content-based filters is "better" than using DNS RBLs. It wholly depends on the listing policy of the RBL, and in most cases, content-based filters will be the far worse option, because it only drives spammers to make their spam stick out from the general mail noise less and less! I.e. after prolonged, widespread use of content-based filters, spam won't be easily distinguishable from your normal mail traffic anymore from a machine's point of view.
Maybe in 50 years, when machines will be able to (almost) fully understand the content of a mail message, this will be a good solution. But until then, I consider a well-designed DNS RBL like bl.spamcop.net to be far superior, even if it causes a few (<0.02% for me, in the SpamCop case) false positives now and then (the SpamCop list even puts up with these by design). If configured correctly, false positives, like all positives, get bounced in the SMTP dialog, so the sender knows that the message wasn't delivered.
> The difference between what I'm advocating and what you're doing: run
> SpamAssassin _at_ _SMTP_ _receipt_, not after accepting the message for
> delivery. Exim4 allows this readily.
Indeed. Bouncing in the SMTP dialog is by far preferrable to bouncing after accepting the message. In fact, the latter method is inacceptable in 95% of all cases (except for when the delivery failure could not have been determined at the time the message was accepted). And even in the remaining cases, it might be better to silently drop the message.
Reply to: