greylisting from multiple sources

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

Contact vjs@rhyolite.com by mail or use the form.