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

  • From: Emanuele Balla balla@localhost
  • Date: Tue, 22 Aug 2006 13:06:22 +0200

pna.lists wrote:

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

This was a quote, not my own stuff ;-)

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

But they are a false positive nontheless.

And it's really *plenty* of lame administrators out there, in my experience.

What I whish to make clear is that you cannot rely on greylisting to
have 0 FP.
As well as you can't assume this for any daemon or DNSBL or whatever. No
matter how well-managed it is by its staff.

Administration of false positives is always a must for any non-lame
server administrator.

What becomes important, then, is the tradeoff between effectiveness and
administration load.

And this is true both for greylisting and DNSBLs, the same way.

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

Not if the exit points are located on very different subnets.

The issue I found was related to a very large company, with a robust
private WAN infrastracture and several internet connections, even on
different ISPs.

No matter how you configure greylisting, then...