>Seeing as I'm just running into a lot of VERP problems I thought I'd see
>what experience other list managers are having. I'm implementing
>greylisting for users at Keele as an anti-spam measure. ...
>A quick description of greylisting is that a mail server takes a look
>at the sender address and recipient address and the IP number of the
>sender and takes a look to see if that combination has been seen
This problem is easy to solve: Don't Do That.
The point of greylisting is to lose mail from misimplemented hosts
that don't retry after a soft failure. As soon as you see a retry
from a given host, you know that, no matter what other flaws it may
have, it's able to retry so there's no point in soft failing its
mail any more.
That means that when you see a retry, you whitelist the IP, not the
specific bounce/recipient addresses. To keep the size of your
whitelist under control you might want to age out the IPs if you
don't hear from them for a month, but other than that there's no
reason ever to greylist mail from a known-to-retry IP again.
My greylist system does this and it works very well, rejects lots of
spam, delays very little real mail. Anyone's welcome to a copy,
although it's written for qmail, so you'd have to rewrite the client
that's part of the SMTP daemon from scratch.
By the way, it's increasingly unwise to expect that you can predict
the bounce address on any incoming mail, not just mailing list mail.
All my outgoing mail all uses BATV to put a signature in the bounce
address, so I can tell real bounces from spam blowback. Since this
lets me reliably detect and reject several hundred thousand blowback
attempts per day, it's not going away. My version of BATV has a time
stamp that changes once a day, so I have a new bounce address every
John Levine, johnl @
com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I shook hands with Senators Dole and Inouye," said Tom, disarmingly.