Victor Duchovni:
> On Fri, Nov 05, 2010 at 11:03:34AM -0400, Wietse Venema wrote:
>
> > The current manpage text reads:
> >
> > reject_rbl_client rbl_domain=d.d.d.d
> > ...
> > permit_dnswl_client dnswl_domain=d.d.d.d
> > Accept the request when the reversed client network address
> > is
> > listed with the A record "d.d.d.d" under dnswl_domain. If
> > no
> > "=d.d.d.d" is specified, accept the request when the
> > reversed
> > client network address is listed with any A record
> > under
> > dnswl_domain.
> > For safety, permit_dnswl_client is silently ignored when
> > it
> > would override reject_unauth_destination. The result
> > is
> > DEFER_IF_REJECT when whitelist lookup fails. This feature
> > is
> > available in Postfix 2.8 and later.
> > ...
> > reject_rhsbl_client rbl_domain=d.d.d.d
> > ...
> > permit_rhswl_client rhswl_domain=d.d.d.d
> > Accept the request when the client hostname is listed with
> > the A
> > record "d.d.d.d" under rhswl_domain. If no "=d.d.d.d" is
> > speci-
> > fied, accept the request when the client hostname is listed
> > with
> > any A record under rhswl_domain.
> > For safety, permit_rhswl_client is silently ignored when
> > it
> > would override reject_unauth_destination. The result
> > is
> > DEFER_IF_REJECT when whitelist lookup fails. This feature
> > is
> > available in Postfix 2.8 and later.
>
> Looks good.
>
> Should we mention that these should only be used to reduce FPs from
> blacklists that follow, and that are expected to not list legitimate
> clients. Thus any temporary DNS lookup error would likely result an an
> additional lookup that incurrs a low risk or rejection, but does *imply*
> rejection. DNS-based positive access rules are fragile with respect
> to the semantics of temporary lookup failures, and must not be used to
> permit some while denying all.
I agree that whitelisting on client names is fragile (whether one
uses a static whitelist map or DNS lookups), because the client
name lookup will sometimes fail due to some temporary error. The
DEFER_IF_REJECT result cited above handles only whitelist lookup
problems; it is easy enough to hard-code the same in permit_*wl_client
for temporary client name lookup problems, but I see no easy way
to automatically fall back to DEFER_IF_REJECT for all name-based
mechanisms.
> There will at some point be interest in DNSWL support for verified DKIM
> "d=" domains. For now that's out of scope (milters, pre-queue filters, ...)
> I've recently starting using the OpenDKIM library, ... it is fairly easy
> to support. If there is ever interest in directly supporting DKIM in the
> Postfix SMTP server, I'm game to talk design.
I'm not yet in a hurry to build those 3-4 letter alphabet soup
protocols into Postfix.
> Due to the DNS lookup latency inherent in incoming DKIM checks, doing
> DKIM in post-queue content-filters is somewhat unattractive, as typically
> one wants low-latency, modest concurrency in a post-queue filter.
This is where before-queue filtersand Milters are in a better
position. I expect that there will be pressure to move away from
after-queue filters, despite the limitations of the before-queue
approach.
Wietse
