Wietse Venema put forth on 8/24/2010 2:37 PM:
> With reject_rbl_client etc. Postfix can use different DNSXLs names
> in different access lists, and filter the result. For example, to
> select responses from some.example.com with value 127.0.0.4:
>
> smtpd_mumble_restrictions =
> ...
> reject_rbl_client some.example.com=127.0.0.4
> ...
>
> I suppose that similar selection would be help with whitelists.
Yes, I believe the dnswl.org implementation is based on RFC5782.
Regarding "safety" against the "list world" and other scenarios, see
section 5, and paragraph 2 of section 7. The tests are the same for
dnsbls and dnswls. You simply check for responses to make sure a dnsXl
is running on the host you're querying before sending real queries. I'm
guessing you already have code for this in the reject_rbl_client code.
>> I assume postscreen processes or passes this data to smtpd in a way that
>> smtpd will automatically bypass all checks normally performed during the
>> CONNECT phase.
>
> Postscreen passes no session information to the SMTP server. The
> file handle is all the SMTP server gets. We're talking about a
> really tight development budget here.
Darn. With all candor and humility Wietse, I don't think postscreen is
the right place to implement dnswl whitelisting. Or, I should say, it's
not a complete dns whitelisting solution, but only a small first step.
If I understand correctly, all this will do is shoot such a whitelisted
client past all the postscreen checks. Virtually all MTAs at IPs listed
by dnswl servers are going to pass the postscreen checks anyway since
postscreen is looking for bots and other ill behaved SMTP clients. Thus
there is little gain in dns whitelisting here here but maybe some extra
performance on loaded MX'en.
IMHO, for dnswl whitelisting to be implemented "properly", or "the way
most people will expect it to behave", it should be implemented almost
exactly like
reject_rbl_client abc.dnsbl.tld n.n.n.n
but with the opposite action--immediately queuing the message for
mailbox delivery--but still executing recipient address verification,
virus checks, and possibly content filter checks etc.
For a full up dnswl implementation, if we can assume some but not all
dnswl servers have multiple responses, then I'm thinking we should do
something just like your reject_rbl_client example, so an OP can
configure the level of "trust/accept" behavior based on his/her
knowledge of a particular configured dnswl server's responses:
accept_dnswl_client abc.dnsbl.tld [n.n.n.n]
As with reject_rbl_client the n.n.n.n would be optional and the default
behavior would be to accept or "OK" a message with any positive response
code from the dnswl server, in the same manner as we would process a
local access table whitelist OK action. We obviously still want
recipient verification, virus scanning, maybe content filtering. So if
I understand Postfix design correctly, we'd implement this in smtpd and
skip all smtpd checks on a positive dnswl hit, assuming the OP inserts
this parameter appropriately close to the top of the restrictions list.
As with reject_rbl_client an OP would be free to insert this dnswl
check in the most appropriate place in the OP's processing order.
--
Stan
