Thank you for your detailed reply, Peter!
Peter J. Holzer wrote:
"/denysoft_greylist.dbm" within the config directory is used.
According to the various installation HOWTOs, the config directory
(/etc/qpsmtpd in my case) should be set like
drwxr-x--- 2 root smtpd 1024 Feb 2 12:15 qpsmtpd
so it's not writable for smtpd.
Looks like this is missing from the POD - I'll add it.
Yes, that'll certainly help the next guy.
-- what's the name and format of your whitelist?
Whitelisting is skipped if
* $ENV{RELAYCLIENT} is set (that's outdated - should be changed to use
the relayclient() method)
* per_recipient greylisting is set and the user hasn't enabled
greylisting (via transaction note recipient_options).
* A connection note client_options->{denysoft_greylist}{skip} exists or
a transaction note sender_options->{denysoft_greylist}{skip} exists.
The client_options connection note is set by the client_options plugin.
The config file (also named client_options) looks like this:
62.225.35.170: check_rfc2821_strict_colon_param/skip=1
62.72.108.248: denysoft_greylist/skip=1
62.72.116.58: denysoft_greylist/skip=1
62.99.159.78: denysoft_greylist/skip=1
64.125.133.202: denysoft_greylist/skip=1
64.233.170.192/28: denysoft_greylist/skip=1
66.218.66.64/26: denysoft_greylist/skip=1
66.28.250.19: denysoft_greylist/skip=1
80.110.228.110: denysoft_greylist/skip=1
81.223.132.220: require_resolvable_client/skip=1
143.130.16.50: denysoft_greylist/skip=1
143.130.16.51: denysoft_greylist/skip=1, relay_client=1
143.130.16.52: denysoft_greylist/skip=1, relay_client=1
[...]
Wow, that looks very versatile. I'll install your version, but I'll need
more time than I have right now. When looking at your listing and at
http://cvs.puremagic.com/viewcvs/greylisting/schema/whitelist_ip.txt
the obvious question is: does your format allow appending a #comment at
the end of each line? That would be very helpful for documenting what
each IP/IP range is and when and why you're doing what with it. Is this
possible?
As you can see, CIDR notation (e.g., 66.218.66.64/26) is permitted so
you can whitelist large server farms (66.218.66.64/26 is Yahoo groups,
IIRC) in a single line. The options are comma-separated and the /
separates the levels in a hash of hashes. so the client_options note for
143.130.16.52 gets set to
{
denysoft_greylist => { skip => 1 },
relay_client => 1
}.
Yes, CIDR notation is great!
But client_options is not a standard, or is it? I mean it can only
control those plugins that specifically check for it, right?
Your description on the web page seems to indicate that your whitelist
mechanism does not use "whitelist_soft", yet the description inside the
file mentions only "whitelist_soft".
I'll remove the reference to "whitelist_soft", that's at least outdated
(I don't remember if my version ever supported it). The client_options
transaction note is documented, but may be easy to overlook (especially
if one looks for "whitelist").
I've been playing a bit with whitelist_soft, and it's useful for
hand-tuning a low-volume MTA such as mine. For an MTA with lots of
accounts, it's surely too broad, but I've readily found a use for each
of the four types of whitelisting (helo, hosts, rcpt, senders) that
whitelist_soft offers. IAC, the specificity of your approach with
client_options and denysoft_greylist is much better than
whitelist_soft's whitelisthosts, but I like the other three options,
too, so I hope all three can work together...
In another thread you recently opposed rejecting all bounces because
they provided important information. Here's an interesting observation:
I've had a steady stream of mis-directed bounces, and installing
greylisting has cut that down by 95%. This could mean two things: either
those were all faked bounces (spam delivered under the guise of a
bounce), or the bouncers rarely try again and you're likely to lose a
significant portion of legitimate bounces by greylisting.
Hans
P.S. Thanks for all your help -- I'll be back in a week...
