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

"Randy Presuhn" <randy_presuhn@mindspring.com> Wed, 10 December 2008 19:28 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 1831E3A69D9; Wed, 10 Dec 2008 11:28:49 -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 ABFEB3A69D9 for <ietf@core3.amsl.com>; Wed, 10 Dec 2008 11:28:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.511
X-Spam-Level:
X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[AWL=1.088, BAYES_00=-2.599]
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 DWhAEY-unVch for <ietf@core3.amsl.com>; Wed, 10 Dec 2008 11:28:47 -0800 (PST)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id C56233A6862 for <ietf@ietf.org>; Wed, 10 Dec 2008 11:28:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UtHMmYaKMmQM1Ag/mmDEmIjiu/t8pgSg1n5J3zjkqRxGAY0pXHETOEOYiexArT2W; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [68.166.189.121] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1LAUja-0006mi-Oc for ietf@ietf.org; Wed, 10 Dec 2008 14:28:34 -0500
Message-ID: <002c01c95afd$b78767e0$6801a8c0@oemcomputer>
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: ietf@ietf.org
References: <20081209061829.GA13153@mit.edu> <493EC59E.1050002@dcrocker.net><20081210165710.GC26292@mit.edu> <49400922.8060803@dcrocker.net>
Subject: Re: How I deal with (false positive) IP-address blacklists...
Date: Wed, 10 Dec 2008 11:30:09 -0800
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88858bc2ddbf51b90e4747d340a48af31111accb4b4a26ff0e2350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 68.166.189.121
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

Hi -

> From: "Dave CROCKER" <dhc2@dcrocker.net>
> To: "Theodore Tso" <tytso@MIT.EDU>
> Cc: <ietf@ietf.org>
> Sent: Wednesday, December 10, 2008 10:23 AM
> Subject: Re: How I deal with (false positive) IP-address blacklists...
...
> Really:  If there is a larger issue that the IETF can and should tackle, then 
> let's talk about it.  But I'm still not seeing how the thread you started qualifies.
...

The problem is a mis-match between the protocol model (and
the points for spam blocking it affords) and the economics of
actual use.

The debate about sender-vs-recipient responsibility for dealing
with false positives misses the point that the party usually
responsible for the blocking is under the control of neither
the sender nor the recipient.  I've spent enough time on hold to
far-away lands to be skeptical of claims that ISPs are really
that interested in resolving false positives, but I recognize that
the experience of individual users isn't considered valid data.

Ted's core point seems to be that that the "delivery value"
economic argument does not always align with the "sender
assumes responsibility for out-of-band-delivery when
blocked" model, particularly when the cost of out-of-band
delivery is far greater than the value of delivery to the sender,
no matter how badly the intended recipient who requested the
information might want it.

By looking only at the SMPT protocol exchange, rather than
the next-layer-up request-for-info followed by response, the
real use case is distorted.

Randy

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