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
>> > 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
> 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
What becomes important, then, is the tradeoff between effectiveness and
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
No matter how you configure greylisting, then...