Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

"Chris Lewis" <clewis@nortel.com> Sat, 08 November 2008 21:43 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 233373A68C8; Sat, 8 Nov 2008 13:43:53 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21883A6916 for <ietf@core3.amsl.com>; Sat, 8 Nov 2008 13:43:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.8
X-Spam-Level:
X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2THIJWGNgeYT for <ietf@core3.amsl.com>; Sat, 8 Nov 2008 13:43:51 -0800 (PST)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id C9A653A6883 for <ietf@ietf.org>; Sat, 8 Nov 2008 13:43:50 -0800 (PST)
Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id mA8Legk14707; Sat, 8 Nov 2008 21:40:42 GMT
Received: from [47.130.64.204] ([47.130.64.204] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Nov 2008 16:43:44 -0500
Message-ID: <4916080D.6030900@nortel.com>
Date: Sat, 08 Nov 2008 16:43:41 -0500
From: Chris Lewis <clewis@nortel.com>
Organization: Nortel
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: John Levine <johnl@iecc.com>
Subject: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
References: <20081108184543.26372.qmail@simone.iecc.com>
In-Reply-To: <20081108184543.26372.qmail@simone.iecc.com>
X-OriginalArrivalTime: 08 Nov 2008 21:43:44.0780 (UTC) FILETIME=[12F2ECC0:01C941EB]
Cc: john-ietf@jck.com, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John Levine wrote:
>> Today, messages can just disappear on the way to the user's mailbox
>> (often at or after that last-hop MTA).  They do so without NDNs out
>> of fear of blowback, and they do so for two main reasons. ...

> You know, DNSBLs make mystery disappearances less likely, not more.
> 
> The DNSBLs that most people use are typically checked at SMTP time, sp
> MTAs can give a 5xx rejection using the TXT record from the DNSBL that
> identifies why the mail was rejected.

Indeed, and more concretely: NDNs aren't inherently bad (blowback).
It's "accept then generate NDN" that's inherently bad.  Anti-spam
techniques that are after the destination's MX should not generate NDNs,
because all of it is potentially blowback by definition.

The "just disappear" argument more applies to techniques that can't NDN
without blowback.  Which, includes, for example, ALL client-side
filtering no matter what filtering they use, and all server-based
"accept-then-analyse" filtering.  Not DNSBLs per-se.

By far the most common server-based implementations using DNSBLs reject
at SMTP time (usually with some sort of remediation information in the
error message), which suppresses almost all blowback, yet "you" still
find out what happened.   In contrast, for example, the most common
implementations of (say) content analysis do accept-then-analyse, and
should not NDN because it'll be blowback.

Full analysis during SMTP time of (say) content and rejecting at SMTP
time is considerably rarer (we're one of the rarer ones).   In part
because older revisions of the SMTP standards weren't very clear about
handling of rejections after DATA.  We decided to ignore that limitation.

In other words, in general you're far more likely to find out about your
email not getting through (and how to fix it) if it was a DNSBL hit than
most other techniques.  It's not intrinsically inherent to DNSBLs, it's
just the "overwhelming experience".

>> Unlike you, I don't see "overwhelming community consensus for
>> this mechanism".
> 
> Aw, come on.  There's a billion and a half mailboxes using the
> Spamhaus DNSBLs, on systems ranging from giant ISPs down to hobbyist
> Linux boxes.

All of the very largest email and spam filtering infrastructures use
DNSBLs (generally IP-based reputation lists) in one way or another,
whether they tell you or not.  I said "all" because I meant "all" -
that's not hyperbole for "most".

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf