Noel Jones put forth on 8/24/2010 2:18 PM: > - This is specific for dnswl.org. Postfix needs a general mechanism. > Other whitelists are not required to follow dnswl.org'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 use. > - 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 default. WRT documentation, that will depend on the values we allow for the variable. If we do something like the 0-3 thing similar to dnswl.org, 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. -- Stan
