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

[Evan Harris]

On 11 Dec 2003, Franck Arnaud wrote:

> What happens to legit servers that retry from different
> IP?
> ...
> 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?).

Most servers really do distinguish between temp 4xx and permanent 5xx codes.
You may just get a large amount from one certain type/group of servers that
doesn't.

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

See the $do_relay_lookup_by_subnet setting in the example implementation.
This takes care of almost all of these "pooled server" setups acceptably.

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

I normally block those types by IP or IP range rather than by domain name,
since they tend to add new domains to their collection all the time, but
it's harder for them to change IP's.  Only works for ones with real servers
and not DHCP'd systems tho.

Another common problem is people who forward their mail from a different
machine.  Greylisting doesnt' help avoid spam in those cases at all, since
the MTA doing the delivering is acting as a proxy and is persistant.

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

Unfortunately, in order to do that you have to have the body text, which
comes at a bandwidth penalty.  And if it became commonplace, it would be
easy for the spammers to take advantage of.

Evan