>I agree with you regarding whitelisting the IP number - thanks for that -
>I'll be altering my implementation this morning.
>However I think that saying that as soon as you see a retry from a host you
>know that it is safe is not absolutely true. We currently insist that the
>host retries with the same sender and recipient between 1 hour and 5 hours
>from the initial attempt.
I agree that it makes sense to match the triple on the retry, but once
you have a satisfactory retry, you whitelist the IP. Even that has
its problems since big mailers with server farms can retry from a
different IP, but in practice they'll retry from the same IP often
enough to get on the whitelist at which point it doesn't matter.
Having looked through my greylist logs, I find that accepting after 5
minutes is just as effective as accepting after an hour and greatly
decreases the amount of legit mail that's delayed. I also find that I
need to accept retries as late as 12 hours later since some hosts
retry that infrequently.
> The problem will be that currently spammers don't retry, but you
> can be sure that they are already looking at their spamming code and
> working out how to adapt it to do retries.
Sure. If they fix it to retry, greylisting won't work any more. The
question is which will happen first, the bad guys will fix the ratware
to retry, or they'll change it to route the spam through the zombies'
own ISP's mail server. My money is on the latter.
If your goal is merely to stall mail until the sending IP has a chance
to hit spam traps and perhaps be added to a blacklist, you can use a
much simpler scheme. When you see mail from a hitherto unseen IP, you
soft fail and remember the IP and time. When it's been an hour since
the IP was first seen, you add it to the whitelist.
John Levine, johnl @
com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"A book is a sneeze." - E.B. White, on the writing of Charlotte's Web