RBL whitelist?
in [Postfix]
|
From: mouss on 15 Mar 2010 16:16 Erik Logtenberg a écrit : >[snip] > Thanks for your reply. I see that I could construct a policy service to > do this, but it seems simpler and much more efficient to let postfix do > this natively. It already has al the DNS-resolving code and whatnot, I > would guess it shouldn't take much more than an extra negation somewhere > to make it permit instead of deny. > an alternative is to rsync the whitelist (if that's possible) and use it as an access map. This is how I use DNSWL (see www.dnswl.org). > Wietse, is there a reason why you would not want a permit_rbl_client > feature in postfix? If not, then I would like to hereby suggest this > feature request. > If you would approve the feature request but don't have the time and/or > other incentive to implement it, I'd gladly try to submit a patch. One of the design issues is what to do if the whitelist query tempfails? if postfix tempfails, then you defer all mail (or a large part). if you pass, then you get "non deterministic" behaviour. if a permit_rbl_... is accepted, I'd rather go for a check_dnsbl_client, allowing one to return restriction classes/PREPEND/... (that said, the design is even more problematic).
From: Noel Jones on 15 Mar 2010 16:29 On 3/15/2010 3:16 PM, mouss wrote: > One of the design issues is what to do if the whitelist query tempfails? > if postfix tempfails, then you defer all mail (or a large part). if you > pass, then you get "non deterministic" behaviour. When a DNS blacklist lookup fails, the worst that can happen is unwanted mail is accepted. Since you accept unwanted mail anyway, this isn't a real big problem. So with a blacklist failures it's acceptable to "log warning and continue". When a DNS whitelist fails, the worst that can happen is that mail that should be specifically whitelisted is rejected. This is bad. I suppose the "failed DNS whitelist lookup" problem could be mostly avoided if the DEFER_IF_REJECT flag was raised on lookup failure. That would allow known good mail to pass, and rejected mail would get a safety net. IIRC last time we discussed this, DEFER_IF_REJECT wasn't invented yet (at least not in it's current form). > > if a permit_rbl_... is accepted, I'd rather go for a check_dnsbl_client, > allowing one to return restriction classes/PREPEND/... (that said, the > design is even more problematic). > Sounds useful, but I can't quite imagine the user interface fitting into the existing framework. Sounds like a job for a policy service. -- Noel Jones
From: Victor Duchovni on 15 Mar 2010 16:39 On Mon, Mar 15, 2010 at 03:29:46PM -0500, Noel Jones wrote: > I suppose the "failed DNS whitelist lookup" problem could be mostly avoided > if the DEFER_IF_REJECT flag was raised on lookup failure. That would allow > known good mail to pass, and rejected mail would get a safety net. IIRC > last time we discussed this, DEFER_IF_REJECT wasn't invented yet (at least > not in it's current form). With name-based white-lists (check_client_access with names rather than addresses as keys) "defer_if_reject" is not a good option for all anonymous clients. With explicit DNSWL lookups, indeed "defer_if_reject" is acceptable, since the DWL is operated locally or by a competent provider and persistent temp failure of lookups is less likely. So it seems to me that this has cleaner semantics than "check_client_access" with name-based "OK" results, provided the DWL lookup-key is an address, not a domain name! -- Viktor. P.S. Morgan Stanley is looking for a New York City based, Senior Unix system/email administrator to architect and sustain our perimeter email environment. If you are interested, please drop me a note.
From: Noel Jones on 15 Mar 2010 16:44 On 3/15/2010 3:39 PM, Victor Duchovni wrote: > On Mon, Mar 15, 2010 at 03:29:46PM -0500, Noel Jones wrote: > >> I suppose the "failed DNS whitelist lookup" problem could be mostly avoided >> if the DEFER_IF_REJECT flag was raised on lookup failure. That would allow >> known good mail to pass, and rejected mail would get a safety net. IIRC >> last time we discussed this, DEFER_IF_REJECT wasn't invented yet (at least >> not in it's current form). > > With name-based white-lists (check_client_access with names rather > than addresses as keys) "defer_if_reject" is not a good option for all > anonymous clients. > > With explicit DNSWL lookups, indeed "defer_if_reject" is acceptable, since > the DWL is operated locally or by a competent provider and persistent temp > failure of lookups is less likely. So it seems to me that this has cleaner > semantics than "check_client_access" with name-based "OK" results, provided > the DWL lookup-key is an address, not a domain name! > What do you think about extending rbl_reply_maps to accept access(5) actions? That might be a suitable generalized interface. Or maybe just too much rope... -- Noel Jones
From: Wietse Venema on 15 Mar 2010 17:15
Victor Duchovni: > With explicit DNSWL lookups, indeed "defer_if_reject" is acceptable, since > the DWL is operated locally or by a competent provider and persistent temp > failure of lookups is less likely. So it seems to me that this has cleaner > semantics than "check_client_access" with name-based "OK" results, provided > the DWL lookup-key is an address, not a domain name! A client hostname is bad because it may not be available, but what is the problem with helo/sender/recipient domains? Wietse |