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:
pgpZIkEfhYmnE.pgp
Description: PGP signature