After domain keys, I implemented the milter-greylist that Gilbert was talking about. It's pretty easy (on FC, with yum packages).
Anyone care to compare notes?
I've chosen the following values:
timeout 25h greylist 6m autowhite 30d subnetmatch /24
Does anyone think there could be an MTA retarded enough to have the queue retry time set to longer than 25h? The greylist default was 5d, but that seems a bit excessive, or am I missing something here?
As for the greylist option, shouldn't 1m be enough to do the trick? Either a spammer will retry or it won't, how long you make it wait should not matter. Of course, once everyone implements greylisting, then all spammers will simply start retrying -- it's only CPU cycles, and those keep getting cheaper.
I suppose setting greylist to 30m or 60m or something might stop some spammers who are now waiting, but not very long. But that's got to be rare.
autowhite should be set pretty high IMO.
My only complaint with the greylist concept is the fact that at the end of the conf file is:
# This is a list of broken MTAs that break with greylisting.
This is like me adding mailertable entries for every domain that RBL's my dyanmic IP (which I do, but the list is getting unwieldly). It's a can't-win scenario. Too bad there are MTA's out there that are so braindead.
Of course, some of them like AOL aren't necessarily braindead, but instead are hard to greylist because of the common-pool problem. That's why I set subnetmatch to /24 which should be fairly safe (since we're still checking to/from/ip tuples, not just IP). But that's just a big kludge, and there appears to be no immediate easy solution to the problem.
Unless... change hte subnetmatch to /16 (or even /0??) and rely more on the to/from tuple. Why not? Most spams use random to/froms. Not ideal, but /0 would get around the braindead/pool problem while still providing some greylist benefit.
I'm going to keep an eye on stats on my boxes to see how this greylisting impacts things, and I may report back.
Trevor Cordes wrote:
Unless... change hte subnetmatch to /16 (or even /0??) and rely more on the to/from tuple. Why not? Most spams use random to/froms. Not ideal, but /0 would get around the braindead/pool problem while still providing some greylist benefit.
There's one big problem with that... botnets. Odds are excellent that two 'bots are going to be in the same class-B (think Shaw or MTS...), which will cause the entire ISP address space to be whitelisted. Even /24 has this problem, but on a smaller scale. You're betting the odds, and have to find an acceptable balance. -Adam
On Sun, 2006-12-03 at 21:03 -0600, Trevor Cordes wrote:
After domain keys, I implemented the milter-greylist that Gilbert was talking about. It's pretty easy (on FC, with yum packages).
Anyone care to compare notes?
I've chosen the following values:
timeout 25h greylist 6m autowhite 30d subnetmatch /24
Does anyone think there could be an MTA retarded enough to have the queue retry time set to longer than 25h? The greylist default was 5d, but that seems a bit excessive, or am I missing something here?
Some of them are very slow to retry. This is my main complaint about greylisting, some mail is very _very_ delayed.
As for the greylist option, shouldn't 1m be enough to do the trick? Either a spammer will retry or it won't,
Agreed. I have mine set to 50 seconds and its just as effective.
# This is a list of broken MTAs that break with greylisting. Too bad there are MTA's out there that are so braindead.
Spammers will soon catch on that if they emulate broken MTAs they bypass greylisting.
Of course, some of them like AOL aren't necessarily braindead, but instead are hard to greylist because of the common-pool problem.
IMHO we all should have just completely blacklisted AOL back in the 90s and called it done. ;)
John
On 2006-12-03 21:03, Trevor Cordes wrote:
After domain keys, I implemented the milter-greylist that Gilbert was talking about. It's pretty easy (on FC, with yum packages).
Anyone care to compare notes?
I've chosen the following values:
timeout 25h greylist 6m autowhite 30d subnetmatch /24
Does anyone think there could be an MTA retarded enough to have the queue retry time set to longer than 25h? The greylist default was 5d, but that seems a bit excessive, or am I missing something here?
I think the reason for setting this to 5 days by default is that's the maximum time a message will typically stay queued up on a sending system before being bounced back to the sender. In case things go very wrong, you don't want grey-listing to further contribute to delivery problems by forcing unnecessary retries. So, setting the retry timeout to 5 days is a safe default.
That said, it's probably fine in most circumstances to set this shorter. I don't think it buys you much, however, other than keeping the list of pending greylist entries down a bit.
As for the greylist option, shouldn't 1m be enough to do the trick? Either a spammer will retry or it won't, how long you make it wait should not matter. Of course, once everyone implements greylisting, then all spammers will simply start retrying -- it's only CPU cycles, and those keep getting cheaper.
So far, most spam sent out by botnets doesn't retry at all, so you could set this as short as you want without increasing spam input. I suppose if spammers do start retrying, then a longer delay is perhaps more likely to keep them away than a short one, since the name of the game for spammers is to maximize volume while minimizing time.
And, according to an article I read, time is very much of the essence. When spammers use botnets, it's often not their own - they rent them from hackers that control them, and they pay based on the amount of time they use. So throughput does matter, and anything you can do to slow them down works in your favour. That's perhaps why grey-listing is still so effective, and why they typically don't bother with retries. It's not worth the time and effort.
I suppose setting greylist to 30m or 60m or something might stop some spammers who are now waiting, but not very long. But that's got to be rare.
Probably very rare right now. I think most of the spam that does get through on retries is being sent through open relays which are "legit" mail servers. In that case, the retry time doesn't really matter much.
autowhite should be set pretty high IMO.
Prabably safest, and least disruptive to legit e-mail. It might slightly increase the chance of repeat spam from the same addresses, though, but I'm not sure how much of a problem that would likely be in practice.
My only complaint with the greylist concept is the fact that at the end of the conf file is:
# This is a list of broken MTAs that break with greylisting. ... Too bad there are MTA's out there that are so braindead.
Yeah, it's rather disconcerting.
-
Adam Thompson -
Gilbert E. Detillieux -
John Lange -
Trevor Cordes