trevor at tecnopolis.ca
Sun Dec 3 21:03:18 CST 2006
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:
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
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
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
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.
More information about the Roundtable