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