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

Re: Greylisting for @debian.org email, please



Le Lun 20 Juin 2005 09:58, Russell Coker a écrit :
> On Saturday 18 June 2005 01:33, Pierre Habouzit <madcoder@debian.org> 
wrote:
> >   you didn't read one of my first posts : when the mail you receive
> > comes from a big big big MX, and that they see a greylisted domain,
> > since the time is sometimes 5 minutes, somtimes 10 and sometimes
> > 20, they choose to deliberately let those mail in the queue for 30
> > to 60 minutes.
>
> Do you have any evidence to support yout claim that big mail servers
> are configured to handle gray-listing servers differently from other
> mail servers?

I do. I know personnaly some admins of big MX (not necessarily ISPs, 
french schools/universities in my case) that have a special rule for 
domain that they know practicing greylisting, and that *force* the 
delay to be of 30 to 60 minutes. and they increase that time if their 
queue is big

> My experience from working at big ISPs is that queues can take 60
> minutes to process because they have many tens of thousands of
> messages.  A queue with more than 50,000 messages will take quite a
> while to process even if you have a 100baseT full-duplex connection
> to the Internet.

well, greylisiting is done before any DATA is sent, and won't charge 
your connection that much. so the BW problem seems quite irrelevant. 
the latency will play a big role though.

> > if there is 2 or 3 such MX that relay the mail before it
> > arrives to its final destination, it can induce 2 to 3 hours delays
> > (I already saw it) and it's painful.
>
> In what situation will you have three such mail servers?

redirections : my debian account redirects to an adress I have from my 
alumni that is a redirection address garanteed for life that redirects 
to my real account.

I do that because my alumni provides me really good AV and AS services, 
and all my ingoing mail comes through it. So maybe 3 is a bit 
exagerated, but I think 2 is pretty common.



> > btw, I don't know how to help to deploy antispam tools for debian,
> > but I can help if any help is welcomed/wanted/...
>
> You could help by listing the anti-spam measures that you consider to
> be acceptable.  Rejecting every suggestion for an improvement is not
> helpful.

I already did. I don't find blacklists, or greylists alone be of any 
good : too many false positives ofr r(h)bls, and too many delays for 
greylisting.

IMHO, rbls, SPF and others techniques that induce false positives have 
to be used upside down : use the rbls, SPF, ... to clean mail. that 
means, that a mail that is 100% correct wrt dnsRBLs, SPF records, ... 
can come in. any other mail, then, can go through "evil" treatments 
like greylisting. It's a way to select mails that are suspicious, and 
let them be delayed.

With that, it's quite easy to avoid greylisting if you are a real 
ISP/MX/... : you only have to try to be removed from RBLs, or fix your 
domain wrt SPF if you use it and use it badly.

I've written a little postfix POLICY daemon that does what I explained 
here. it's called whitelister, and it's in the repo. Though, it has not 
been (AFAIK) used in a big queue, but I plan to.

Cheers,
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgpbv3geOujm0.pgp
Description: PGP signature


Reply to: