Re: How I deal with (false positive) IP-address blacklists...

Rich Kulawiec <rsk@gsp.org> Wed, 10 December 2008 17:42 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 35DFF3A6989; Wed, 10 Dec 2008 09:42:32 -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 CA7423A6B58 for <ietf@core3.amsl.com>; Tue, 9 Dec 2008 18:53:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.535
X-Spam-Level:
X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 xaesDEiy0-vr for <ietf@core3.amsl.com>; Tue, 9 Dec 2008 18:53:12 -0800 (PST)
Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id F11753A67D7 for <ietf@ietf.org>; Tue, 9 Dec 2008 18:53:11 -0800 (PST)
Received: from squonk.gsp.org (bltmd-207.114.25.46.dsl.charm.net [207.114.25.46]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id mBA2r0rC029353 for <ietf@ietf.org>; Tue, 9 Dec 2008 21:53:05 -0500 (EST)
Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id mBA2k9v6029790 for <ietf@ietf.org>; Tue, 9 Dec 2008 21:46:09 -0500 (EST)
Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id mBA2qsml014971 for <ietf@ietf.org>; Tue, 9 Dec 2008 21:52:54 -0500
Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id mBA2qqjs014970 for ietf@ietf.org; Tue, 9 Dec 2008 21:52:52 -0500
Date: Tue, 09 Dec 2008 21:52:52 -0500
From: Rich Kulawiec <rsk@gsp.org>
To: ietf@ietf.org
Subject: Re: How I deal with (false positive) IP-address blacklists...
Message-ID: <20081210025251.GA14773@gsp.org>
References: <20081209061829.GA13153@mit.edu> <200812090649.mB96n2Fd047212@drugs.dv.isc.org> <20081209070351.GC13153@mit.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20081209070351.GC13153@mit.edu>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Mailman-Approved-At: Wed, 10 Dec 2008 09:42:31 -0800
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

On Tue, Dec 09, 2008 at 02:03:51AM -0500, Theodore Tso wrote:
> Well, it blocked a legitimate e-mail message, so by definition the
> rejection was false positive.  

That's incorrect.  Determining whether the rejection was a false positive
or true positive is the sole prerogative of the recipient, never the sender.

Why?  Well, first, because it is the recipient who is generously furnishing
the privilege of access to a service to the sender.  And second, because
were it otherwise, we would of course be told by every spammer on the
planet that rejection of their abuse constituted a FP.  (We already *have*
been told this by a substantial number of them.)

Of source, the sender may wish to report the incident to the recipient,
or suggest to the recipient that this may be a FP, but the final decision is
still that of the recipient.

For example, I've blocked all the IP allocations of several countries
in some of the mail servers that I run.  (After years of non-stop spam and
precisely zero non-spam messages.)  Those rules are doing precisely what
I intend them to do, and unless the IP allocations are changed, will
never cause a FP.  (That is: suppose a block is reassigned to another
country that I do not wish to block, and that an incoming message from it
subsequently is presented and rejected.  That would be a FP.)

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