[Greylist-users] what happens with servers that change IP addresses
franck at nenie.org
Wed Dec 10 16:13:04 PST 2003
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
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
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
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).
More information about the Greylist-users