proposal: greylisting and multiple-IP clients

Vernon Schryver vjs@calcite.rhyolite.com
Thu Mar 11 15:12:48 UTC 2004


> From: John Sutton 

> ...
> embargoing that can surprise end users."  Of course, this problem can be 
> circumvented by appropriate "ok ip" additions to grey_whitelist but this 
> involves an administrative burden and defeats the purpose of greylisting.

Could you use something like the CGI scripts in the DCC source to
let users do their own whitelisting?

> ...
> If the first submission which initiates an embargo involves the "quartet":
>
> 	<ip1><env_from1><env_to1><body1>
>
> then a subsequent submission should lift the embargo if it presents:
>
> 	<ip2><env_from1><env_to1><body1>
>
> where ip2 is *any* ip.  ...

> Of course, it is my assumption that "the relaxation of this restriction would 
> produce very little increase in spam evading the greylist" which needs to be 
> tested, and I wonder what other people think about that?

Consider the spam that greylisting does best against, spam sent
through open proxies or relays.  It seems to me that it would be
fairly easy for a spammer to make <env_from1><env_to1><body1> constant.

You are basially proposing that the IP addresses be removed from
the greylist triples, making them greylist pairs.

The greylist servers are given something like MD5(IP address,from,to)
and MD5(body).  If it is not impossible for the greylist servers
compare MD5(IP address1,from1,to1) to MD5(IP address2,from2,to2)
and know that only the IP addresses differ, then many digitial signature
and other mechanisms that depend on MD5 are catastrophically broken.

What you want could be done if dccifd or dccm would cheat and use a
constant IP address such as 127.1 when they compute the checksum of
the greylist triple.  However, I don't see a clean way to do that.  I
make a mistake when I made -G a boolean switch for dccm and dccifd
instead of something like '-G on'.  If I'd done the latter, it would
be easy to recognize '-G weakIP'.  I think I could kludge things with
optreset and optind with the 4.4BSD version of getopt(), but not
on, for example, Solaris.  Using a private version of getopt() on all
except BSD systems seems ugly.  Using a private getopt() is tolerable
on WIN32 systems since they seem to lack getopt() entirely.


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

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