>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 >before. 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 day. Regards, John Levine, [EMAIL PROTECTED], 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.
