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

Re: db.debian.org (and related infrastructure) updates



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 <joss@debian.org> 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 cmot@debian.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.

Attachment: pgpaq500SnkAT.pgp
Description: PGP signature


Reply to: