RBL whitelist?
in [Postfix]
|
From: Victor Duchovni on 15 Mar 2010 17:37 On Mon, Mar 15, 2010 at 05:15:59PM -0400, Wietse Venema wrote: > 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? Yes, only the client name is a problem in the original sense of this thread. Of course one would be rather foolish to white-list by helo-name and sender domain, these are too easy to spoof. It is not clear that a recipient domain DNSWL is semantically useful, so I think that only client names make sense in this context. -- 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: Erik Logtenberg on 15 Mar 2010 17:41 >> 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). I understand what you say: you don't want to be dropping mail that's actually supposed to be whitelisted. However the DEFER_IF_REJECT flag makes _all_ mail that would normally be rejected (quite much) be deferred, which imho is quite a sacrifice to make. (if I understand correctly) I don't feel that my specific use case warrants such an approach; the whitelist that I would like to use contains IP addresses of MTA's from the biggest ISP's in The Netherlands. They normally don't get blacklisted at all, the whitelist is there only to protect regular email traffic from some accidental blacklisting. In the rare case that it happens, these guys are very quick in having themselves unlisted again, so in that respect the whitelist is only useful now and then, and even then just for a relatively short period of time. In this case I would say that if the whitelist were to be unavailable at some time, logging a warning and continue is the best thing to do. This way the usual rejecting of mail isn't disrupted and most of the time the blacklists don't contain those IP addresses anyway, so if the whitelist is unavailable for just a short period of time, normally no mail would get unjustly blocked. Please note that at this time most postfix users don't use the whitelist at all, and that would be quite a lot of Dutch ISP's, so the described implementation would be a big step forward anyway -- it doesn't even need to be foolproof in order to be useful. Other users' use cases may vary of course, making this configurable would enable everyone to choose the right behaviour for their specific environment.
From: Erik Logtenberg on 15 Mar 2010 17:48 On 03/15/2010 10:37 PM, Victor Duchovni wrote: > On Mon, Mar 15, 2010 at 05:15:59PM -0400, Wietse Venema wrote: > >> 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? > > Yes, only the client name is a problem in the original sense of this > thread. Of course one would be rather foolish to white-list by helo-name > and sender domain, these are too easy to spoof. It is not clear that > a recipient domain DNSWL is semantically useful, so I think that only > client names make sense in this context. Indeed. By the way, the orignial sense of this thread is inspired by this specific whitelist: http://noc.bit.nl/dnsbl/nlwhitelist/ As you can see (http://noc.bit.nl/dnsbl/nlwhitelist/txt.php) it just contains IP addresses. Those IP addresses belong to companies whom we trust to send valid mail, _and_ have a decent abusedesk -- this is in fact a prerequisite to be included in that list to begin with. We wouldn't be using it to check HELO name and/or sender domain, but just for the initial state of initiating an smtp session from a specific IP, exactly the point where the reject_rbl_client is currently active. If the IP is on the whitelist, then we don't even want to check the blacklists anymore, but permit the connection right away. It may still fail other checks that could lead to reject or defer of course.
From: Victor Duchovni on 15 Mar 2010 17:49 On Mon, Mar 15, 2010 at 10:41:02PM +0100, Erik Logtenberg wrote: > However the DEFER_IF_REJECT flag makes _all_ mail that would normally be > rejected (quite much) be deferred, which imho is quite a sacrifice to > make. (if I understand correctly) No, this would apply only to failed DNSWL lookups. -- 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: Erik Logtenberg on 15 Mar 2010 17:57
On 03/15/2010 10:49 PM, Victor Duchovni wrote: > On Mon, Mar 15, 2010 at 10:41:02PM +0100, Erik Logtenberg wrote: > >> However the DEFER_IF_REJECT flag makes _all_ mail that would normally be >> rejected (quite much) be deferred, which imho is quite a sacrifice to >> make. (if I understand correctly) > > No, this would apply only to failed DNSWL lookups. Ah okay, you mean the case where the whitelist is actually available, but a single lookup happens to fail, which they sometimes do. Now I understand; and yes I agree that raising the DEFER_IF_REJECT flag would be the best/strictest way to handle such an event. However in the case where the whitelist is (completely) unavailable for some period of time, I still think that my suggestion applies, don't you agree? |