Vernon Schryver
vjs@calcite.rhyolite.com
Tue Jan 27 02:43:16 UTC 2004
> From: Tim Wicinski <tim@meer.net> > We're seeing a problem with greylisting, one that our customers are > seeing enough and getting antsy about. While the tuple of (IP, sender, > recipient) works fine, it has a problem in dealing with SMTP servers > which send from multiple IP addresses the same message, or different > messages. Once the first message is whitelisted, successive messages > can not be assured of arriving that quickly since they may be going out > on a different SMTP server. > > Any ideas how to deal with this? Turning off greylisting is currently > the largest vote, despite the flood of spam which is destined to return. 1.2.29 will let individual users turn off greylisting. > The next idea is to try to monitor and whitelist as many large IP space > as possible. This would cut down the very long delays we are seeing in > email arriving. For example, we're seeing Earthlink/Mindspring take > upward of 6+ hours for messages to arrive through the embargo. Whitelisting Earthlink/Mindspring is fine, provided their users don't send unsolicited bulk email. Perhaps what is needed is a way to add (IP,sender,recipient) triples to the greylist database from something like the proof-of-concept CGI scripts in the DCC source. Then individual users or you on their behalf could premempt future embargos. I spent the last week working on a cool hack to greylisting. The idea was to handle greylisting of some messages at the SMTP Rcpt_To command and so break up transactions of several targets that get embargoed as a block at the DATA command because one in the block needs the embargo. It fell apart when I belatedly realized that you can't whitelist by headers or anything else in the message body at the Rcpt_To command before the body has arrived. Vernon Schryver vjs@rhyolite.com
More information about the DCC
mailing list