[Discuss] anti-spam.

[Scott Petersen]

On Thu, May 25, 2006 at 02:37:15PM -0700, Alan W. Irwin wrote:
> On 2006-05-25 11:59-0700 Scott Petersen wrote:
> 
> >My mail server is Postfix and my greylisting tool is Postgrey.
> >
> >http://www.greylisting.org/ [...]
> 
> Scott, I would appreciate it if you would answer some further questions
> about this technique based on the following quote from that reference:
> 
>    "What happen is that each time a given mailbox receives an email from an
>    unknown contact (ip), that mail is rejected with a "try again
>    later"-message....".
> 
> (1) Does the technique really work at the individual mailbox (i.e.,
> individual mail address) level?  That would be bad since it tells the
> spammers this particular mail address is legitimate.  I presume that is a
> bad description, and the whole SMTP server (e.g., users.sf.net) does the
> greylist rather than individual mailboxes for a given SMTP server (e.g.,
> username at users.sf.net).

This technique works at the server level. Every time a new message
arrives at the mail server, it has to identify who it is to, who it is
from and the sending ip address. This "triplet" is checked against the
greylisting database to see if it is listed. If it is not listed the
server responds to the sender with a try again later message.  It will
continue to send the "try again later" message until the timeout is
exceeded. (In my case 5 minutes) After that point, the "triplet" will be
listed in the database and the transaction can continue. You will note
that the the "triplet" is what is checked, not whether the individual
recipient exists. This may vary between greylisting implementations. 
 
> (2) Later on the reference says the delay for unknown IP addresses gives a
> chance for the black-listing tools to work.  That sounds good, but from the
> examples given it appears grey-listing works right at the SMTP server level
> so there is no chance for spam to get through and immediately be recognized
> as spam and black listed before the time delay is completed.  That's fine if
> there are a substantial fraction of SMTP servers that don't use grey-listing
> or who have such a short delay that the grey-listing is ineffective.  Such
> spam-trap SMTP servers immediately get the spam and can black-list it in
> time to help the grey-list servers who are delaying it.  But who is going to
> run such spam-trap SMTP servers, and how do you keep spammers from detecting
> and simply avoiding those spam-trap sites?

That evaluation is the same as the one I arrived at, after reading the
article. However, this black-listing will be helpful when spammers start
resending messages.
 
> >From such considerations, I believe grey-listing will work well for a 
> >while,
> but in the long run it won't be nearly as effective. To be fair, in the long
> run it will still have some value by adding a bit more genetic diversity
> (variety of delay times) that spammers have to deal with, but that is about
> it.

The fundamental factor here, that I believe will let greylisting be a
viable tool in to the future, is time. A spammer, typically, wants to
send lots and lots and lots of messages as quickly as possible. They
currently accomplish this but not fully following the SMTP RFC and not
resending messages. In the future, even when they adapt and start
resending, they will still be impacted by having to wait for the timeout
and ensure that they get the mail sent within the window between the
timeout and when the triplet is removed from the database.  This will
slow them down and I will get less spam.

As well, when they do start re-sending, more e-mail will get through the
greylisting. When that happens, if the first people who get the message
submit the information to an on-line blacklisting service, the people
after them will be able to take advantage of the informtion when the
spammer does a resend for them. 

That being said, I am not all that comfortable with an on-line
blacklisting service as it has all the same problems as a web filtering
service.  That is, trusting the data sources to evaluate a message as
spam correctly and to not abuse the black list to block large blocks of
IP addresses.

Cheers
Scott Petersen