Noel Jones put forth on 8/24/2010 2:18 PM:

> - This is specific for  Postfix needs a general mechanism. 
> Other whitelists are not required to follow's 127.0.x.y
> mechanism.

Yeah, I used this example as dnswl is, afaik, the most "established" of
the dns whitelists.  I haven't yet looked at the return codes the others

> - what do you mean by "accept the message"; OK? suppress further rbl
> lookups?

This is something that needs discussion due to various expectations of
what a dns "whitelist" entry actually means and how it can best be
implemented.  I think messages with a "positive" dnswl return code
should obviously bypass certain restrictions, mainly dnsbl hits, but not
all restrictions--we shouldn't bypass virus checks and content filters.
 And if an admin wants to locally ban an IP listed in a dnswl for any
reason, we shouldn't be bypassing user defined access tables.

I think bypassing reject_r*bl_* and most of the inbuilt/standard client,
sender, helo, etc sanity checks would be a good idea.  Obviously we
don't want to bypass something like reject_unlisted_recipient.

I think what we really need here is consensus on the use of local
whitelists.  Should dns whitelists carry the same weight?  If so, we may
want to bypass all restrictions but virus/content filters and recipient
address verification.

> - If "accept" means OK, how will you protect postfix from open relay if
> the dns whitelist accidentally or intentionally lists the whole internet?

We currently run similar risk, but in the opposite direction, using
dnsbls.  I don't believe there is a technical solution to this potential
issue.  Every dnsbl comes with a "use at your own risk... no
warranty..." disclaimer for this reason and others.  Though I think the
dnsbl case is worse as it can potentially stop all email flow.  In the
dnswl case, you'd simply see much more spam.  Although, at the inbox
level, the "denial of service" result may be equivalent, much like
yesteryear when folks had to sift through 100 spams to find 3 legit
emails they received on a given day.  But at least they still received
those 3.

Probably difficult to implement, but maybe some kind of analysis on mail
flow would help.  Keep statistics counters and establish an "average
volume" baseline.  If volume increases 10x over baseline, throttle all
connections.  The programming effort may not be worth the payoff here
given the odds of "list world" occurrences.

> - what would the user interface look like?  Is it possible to document
> it clearly?

I think something like I mentioned before would be good.  Simple single
line configuration parameter populating one global program variable.
How the variable would be used is the tricky part, and up to others.
I'm not much of a programmer these days. :(  I think it would be wise to
allow flexible use of accept_dnswl_client much like reject_r*bl_foo
which can today be used within access tables in addition to directly
within smtpd_foo_restrictions.  If we make its functionality very
permissive by default, I probably wouldn't make it globally effective by

WRT documentation, that will depend on the values we allow for the
variable.  If we do something like the 0-3 thing similar to,
it's not as clear due to complexity.  If we make it boolean, it's very
clear.  In this latter case, lots of bold starred italic documentation
needs to inform the OP of the risks of turning it on.


Reply via email to