[Greylist-users] what happens with servers that change IP addresses

[Franck Arnaud]

Hello,

A few days ago I started using a home grown SMTP server with 
a variant of greylisting implemented. Looking at my logs 
brings a question:

What happens to legit servers that retry from different 
IP?

I bounce a significant number of Windows "virus" traffic 
which comes from the regular SMTP servers of the victims' 
ISP, so typically large ISPs. Before I implemented the 
SIZE extension (which allows me to reject most of those 
(big) messages on EHLO or MAIL FROM) I rejected those 
messages at the end of DATA (not bandwidth effective...). 

First, I note that none of those legit servers distinguishes 
(at the end of encoded data) between a tempfail and a 552 or 
554. They all retry even for permanent fail. Do legit 
servers ever distinguish between a tempfail and a permanent 
fail (if in reply to FROM or TO maybe?).

Secondly, those retries are usually (much more often than not)
from a _different_ server from the big ISP's pool of SMTP 
senders.

If those messages (could be legit mail from a big-ISP user) 
had been greylisted the retries would have generated their 
own greylisting entries. What I do myself is only greylist 
on the (from,to) pairs. If the ISP has a large pool, and  
regular (IP,from,to) greylisting is used, isn't it likely 
that a legit message will bounce if the retry count is 
below the number of servers in the pool?

As far as greylisting goes, I have not enough data to 
say how effective is it, because it turns out I stop most 
spam because of mere standard compliance! Having implemented 
SMTP by reading the RFC, I reject:

MAIL FROM: <blah at x.net>

(Note illegal space after the colon.)

Apart from one maybe semi-legit instance, virtually all such 
errors seem to come from probably only 2 different spam 
programs, with the following patterns:

One always reconnects three times from the same IP, with 
different HELO and MAIL FROM addresses, with real 
domains apparently picked up randomly from a pool of 
harvested domains.

Another connects once, and gives the real reverse DNS 
lookup of the machine in the HELO, almost always from 
a dialup/DSL address (x-y-z-ip.dsl/cable.somelargeisp.net).

Maybe greylisting of servers and users should be done 
separately? If you greylist (from,to) pairs, and (IP,helo) 
pairs it would probably effective against the above if 
they fixed their MAIL FROM or for people who accept 
syntax errors. This does not completely solve the 
"big ISP pool" issue, but for large sites the big ISP 
would quickly have all their pool past the 
site-greylisting so that further individual user delays 
or bounces are minimised.

No legit server will change their HELO name (even if 
they use a broken/useless name) between connections, 
while the second pattern type of spammer will never 
reuse the same HELO name, so (IP,helo) greylisting 
would be quite effective against these.

I've also got one persistent spammer who retries, so 
greylisting will definitely not work against all 
spammers. They use their own domains without hiding 
them, so I've blacklisted their domains. It may be a bit 
labour intensive if they change them frequently...

Another variant I've done so far, to avoid greylisting
delays, is to greylist only HTML messages (9/10 of my 
real email is plain text, 9/10 of spam is HTML).