On Monday 01 January 2007 22:20, Josselin Mouette wrote: > Le lundi 01 janvier 2007 à 17:51 +0100, Marco d'Itri a écrit : > > On Jan 01, Josselin Mouette <email@example.com> wrote: > > > rejecting email blindly based on data as > > > reliable as RBLs is likely to give tons of false positives. > > > > This can be easily disproven by anybody who does this... > > Of course. I'm pretty sure that nobody on this list has ever got emails > rejected because of broken RBLs. And of course having one or two mails (that I can remember) rejected because of borked RBLs is "tons of false positives"? Besides: Linux has tons of bugs. It still solves many of my computing problems. RBLs are probably not the golden bullet either, but they're an important part of my spam prevention measures, and I could even remove the "send spam (as per spamassassin) to firstname.lastname@example.org to devnull" hack, which is much more prone to false positives, and where the false positives are much, much worse (senders get no indication at all) than with RBLs, where the sender get a bounce. Greylisting and callout verfication are to other pieces in the puzzle, the latter being the one I find the most controversial, the first one being the one that spammers are slowly getting the hang of. (But if the RBL get fast enough so that a spam sender is in the RBL by the time the sender tries to send the spam the 2nd time, I still have won :-) All of these are much, much more preferrable to all measures that can only be used when the mail body is on my server, because (i) sending mailservers often don't deal properly with rejections at the DATA stage and (ii) if rejection is not an option, and dropping is IMHO not a good option either, I'll still have to look through my spam folder. cheers -- vbi -- Shutting down networkservers reguarly during worktime prevents RSI and develops social contacts at work.
Description: PGP signature