Fighting spam via greylisting

Ag. D. Hatzimanikas a.hatzim at gmail.com
Wed Apr 25 02:04:19 PDT 2007


On Tue, Apr 24, at 02:13 Jeremy Huntwork wrote:
> On Mon, Apr 23, 2007 at 08:46:04AM +0300, Ag. D. Hatzimanikas wrote:
> > Maybe it's a flaw in Track, maybe there is already a patch.
> 
> Keep in mind that, although it may have appeared that way externally,
> the idea to try out greylisting had nothing to do with recent vandalism
> of the trac system(s). We fully realize that there are two separate and
> distinct issues there.
> 

Alright then, although I didn't notice any spam in mailing lists in the
last year, since we started to require registration for posting.

Anyway my main concerns were/are the followings:

By rejecting mail and adding overhead to the mail server of the sender, 
is not considering - in my poor opinion - civil/social behavior.

Since I started to reply to you, I read/thought a little about it and 
gathered some information which I will share for reference.


The logic behind greylisting is rejecting email with a temporary error 
code -- which is defined in RFC 821 [1] and should be honored by the
moderns MTA's-- so:
   
   - Any "well behaved" [2] MTA will try to resend the email, which is
     exactly what we want.
   
     But the 450 code is described as: User not active now.
     Isn't this (when with our software return 450) some kind of a violation?
     Personally I would like an answer about that, because quite
     possible, as a novice in these matters, I'm missing something.

   - The spam software will see the error code (450) and quite possible
     will not try to resend the email, considering as a dead connection. 
     
     Smart for a start, although spamers can be smart too and soon or
     later they will make adjustments to their software.
     Probable using another domain for their host to resend their spam.
     Thus, it means extra resources for them, but also means extra
     resources for us too and for all the networks out there extra
     traffic.
     Should networks be penalized in the fight against spam? [borrow the
     question]
    
   - The first delay delivery. We've had already some cases:
     http://linuxfromscratch.org/pipermail/lfs-support/2007-April/033010.html
     And I remember there was another one.

     So before the users start and complain and make our service looks
     unreliable, and if we decided to go that route, we have to warning them 
     for the delay. 
     With which way is up to you. For sure, with a warning in the web page.
     As an extra measure, and for debugging reasons, maybe it's good to add
     another header like: "X-delay" or something -- which will tell us the 
     exact time of the delay, if this is possible.
  

I have to say though, that there is a benefit from that procedure.

Most anti-spam software make extra usage of the system resources, so by reducing 
a good amount of spam with greylisting (hopefully), and freeing some system 
resources, we can make a more extensive and careful filtering by the traditional 
anti-spam software.

For example.
I've had many rejections (at least 4-5) in the past, when the email was
too long.

I want to make a request for those who have the rights to do so, and:

a. Have a second look to the filters and
b. To have a clear notice in the web site, where we can find an email
   address, of who (1 or 2 or 10) will be responsible for the job.
   So addressing problems like this (rejection of a legitimate email)
   will be easier.

     
[1] http://www.faqs.org/rfcs/rfc821.html 
[2] http://projects.puremagic.com/greylisting/whitepaper.html



More information about the lfs-dev mailing list