Re: [anti-spam-wg] About DNSBLs vs greylisting - Was: Steve Linford and Spamhaus Internet Terrorists

[pna.lists <pna.lists@localhost]

Dear Emanuele,

there are several mistakes/omission in your message:

> > That depends on the mail servers... Quite a few big companies seem to be
> > running servers that don't understand the 4** messages, so you have to
> > whitelist them

Even those incompatible servers (GroupWise) are able to understand 4xx
messages -- the current versions are fixed.

> Or people configuring their mailservers to try delivery just once, or
> mailing-list services than do not use to keep queues for performance
> reasons.

Are lame senders' administrators an excuse???

> Or large neworks with several exit points for email, configured to
> mutually fallback in case of deliverability problems. Mails tend to move
> from one exit point to another even for days, since each exit point is
> considered as "unseen" by the receiving greylisting system.

You can use /24 address range instead of a single IP address in your
greylisting triplets and/or you can store sender domain instead the
sender e-mail address (from the SMTP envelope).

Such tricks are common:
http://www.jonatkins.com/page/software/qgreylist

http://sqlgrey.sourceforge.net/

http://mimo.gn.apc.org/gps/

> Moreover, an increasing amount of junk passes through greylisting, as
> spammers know about its behaviour, and know that running the same run
> through the same bot/proxies 30 minutes later is enough to bypass it.

Anyway, greylisting at least delays the spam, so you can  better catch
the delayed spam using Razor/Pyzor/DCC.

> At this time, greylisting is useful exactly for delaying the delivery:
> in the meanwhile, there's the chance for the spam source to be catched
> by euristic/retroactive DNSBLs like CBL/XBL/DSBL/etc before it starts
> its second run.

It does not delay the delivery from the konow contacts...

But it would be nice to increase the initial greylisting delay if the
sender's IP address.