Pierre Habouzit <[EMAIL PROTECTED]> writes: > 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
A novel, but not particularly clever use of greylisting. Those delays seem excessively big. >From experience, there only needs to be one 4xx message, and a short delay. 5 minutes is common, a few seconds is sufficient. Todays spambots do not try again after the first 4xx. However, this _will_ change, if enough sites start to greylist. Spammers adapt. > 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. These are sound ideas, and a piece of code is worth more than a thousand arguments. I'll give it a try. :D -- Stig Sandbeck Mathisen Linpro -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
