proposal: greylisting and multiple-IP clients

John Sutton
Thu Mar 11 18:04:07 UTC 2004

On Thursday 11 March 2004  3:12 pm, Vernon Schryver wrote:
> Could you use something like the CGI scripts in the DCC source to
> let users do their own whitelisting?

I'll take another look at that.  The last time I looked I didn't spot 
anything to do with greylisting whitelisting?  In any case, I've realised 
today that I am going to have top provide users with access to the logs (I've 
been trying to avoid this - one more system that will need explaining and 
maintaining...) to deal with another shortcoming of greylisting, viz: users 
click buttons on web pages to:

* subscribe to mailimg lists
* register in forums
* get new passwords
* etc etc

and they *expect* to receive a confirmation email which allows them to 
complete the process *within minutes*...  But even if the client SMTP is well 
behaved and fully RFC2821 compliant (dream on...) it is going to take 30 
minutes to get such emails.  More likely, the user will hit the button 10 
times, go to bed in frustration and wake up to 10 emails...

> 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.

I suppose the question to consider is how much easier this would be as 
compared with keeping the quartet constant.  And that is a pretty complex 
question which depends crucially on the degree to which spammers have access 
(or otherwise) to fixed (and re-usable) IP addresses?

It all comes down to where does this bloody spam come from!  Is it just a 
bunch of tosspots in Boca Raton (or whatever that place is called) who have 
cable connections?  If so, how come their whole IP address range is not 
listed in the RBL, problem solved?

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

I'm not sure that is true.  It is still important that triples are stored 
(otherwise a spammer need only send out all emails with env_to = env_from and 
the greylist would be defeated?)  Rather, it is a question of *how* those 
triples are created.  Having the IP in there is surely pretty crucial because 
it is the one element of the triple which the spammer cannot spoof?  Looked 
at from the other side, authentic non-spam messages come from fixed IP 
addresses - sender X using ISP Y sends via ISP Y's SMTP server to recipient Z 
- and once the communication path XYZ has been established, it is good for 
all time (at least until X changes their ISP).  Addressing the problem that 
ISP Y actually has many SMTP servers should not lead us to throw the baby out 
with the bathwater!

> 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.

That you have got involved in implementation questions makes me think that 
the proposal is not wholly unconvincing ;-)

John Sutton
SCL Internet
Tel. +44 (0) 1239 711 888

More information about the DCC mailing list

Contact by mail or use the form.