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

"Chris Lewis" <clewis@nortel.com> Tue, 11 November 2008 20:05 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 45B4D3A6980; Tue, 11 Nov 2008 12:05:59 -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 1DE633A6925 for <ietf@core3.amsl.com>; Tue, 11 Nov 2008 12:05:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.508
X-Spam-Level:
X-Spam-Status: No, score=-4.508 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 qCmPAk33Xbxw for <ietf@core3.amsl.com>; Tue, 11 Nov 2008 12:05:57 -0800 (PST)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 00B823A6873 for <ietf@ietf.org>; Tue, 11 Nov 2008 12:05:56 -0800 (PST)
Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id mABK2nL08166 for <ietf@ietf.org>; Tue, 11 Nov 2008 20:02:49 GMT
Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Nov 2008 15:05:54 -0500
Received: from [47.130.66.198] (47.130.66.198) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 11 Nov 2008 15:05:53 -0500
Message-ID: <4919E5A0.6030408@nortel.com>
Date: Tue, 11 Nov 2008 15:05:52 -0500
From: Chris Lewis <clewis@nortel.com>
Organization: Nortel
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
CC: "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
References: <A.1KzaJs-0008yI-GB@smtp-ext-layer.spamhaus.org> <20081111143849.GA13960@mit.edu> <alpine.LSU.2.00.0811111625500.23184@hermes-1.csi.cam.ac.uk>
In-Reply-To: <alpine.LSU.2.00.0811111625500.23184@hermes-1.csi.cam.ac.uk>
X-OriginalArrivalTime: 11 Nov 2008 20:05:54.0318 (UTC) FILETIME=[E71EC2E0:01C94438]
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

Tony Finch wrote:

> Note that anti-spam blacklists are distributed by more mechanisms than
> just the DNS. Questions of listing policy apply whatever protocol is
> used, so they shouldn't be addressed in a document that just describes
> a DNS-based query protocol.

I have a similar objection the proposal of a WG for "reputation lists".

The problem it seems intended to solve is far broader than reputation
lists, and is completely orthogonal to a reputation delivery protocol
standard.

The problems that people ascribe to reputation mechanisms are just as
severe in virtually every other type of filtering method.  Poorly chosen
or implemented content filtering systems have exactly the same problems
as poorly chosen or implemented DNSBLs, and have the same implications
for "reliability of email".  These are SMTP filter signaling protocol
issues, and have nothing to do with filtering engine decision mechanisms.

The real issue underlying this is standards and practises on how the
decision making is implemented _at_ the filter itself.  In other words,
we need generalized principles of practise how filtering should be
signaled through SMTP to enhance reliability, repeatability, and and the
ability to identify/resolve problems.

I've long been considering the draft of a BCP on how filters should
operate.  And have written bits and pieces of it in point form.  Eg:
rejects not bounces, SMTP codes, error texts, C/R, SAV, remediation
channels etc.  That doesn't belong in a DNSBL protocol specification. It
would be entirely missed in a WG about "reputation".  It's covered, in
part, in the still-draft DNSBL BCP, insofar as they directly relate to
details specific to DNSBLs.

If a WG were chartered to explore ways to improve filter
reliability/interoperability, eg: standardizing filter response
mechanisms, I'd participate in that.  But that has nothing whatsoever to
do with DNSBL protocols - which is nothing more then a delivery
mechanism for certain classes of information, the interpretation thereof
the choice of who implements whatever uses it.  [I use DNSBL protocols
for far more than filtering decisions.  It works really well to resolve
IP addresses into ASNs, allocation ranges, ownership and geolocation
information for example.]
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf