RE: several messages

<michael.dillon@bt.com> Wed, 12 November 2008 21:07 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 0AC8B3A6B49; Wed, 12 Nov 2008 13:07:15 -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 682A83A6B49 for <ietf@core3.amsl.com>; Wed, 12 Nov 2008 13:07:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level:
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 0qB9vz6ndDEl for <ietf@core3.amsl.com>; Wed, 12 Nov 2008 13:07:13 -0800 (PST)
Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 5AD233A6B22 for <ietf@ietf.org>; Wed, 12 Nov 2008 13:07:13 -0800 (PST)
Received: from E03MVZ2-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Nov 2008 21:07:10 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: several messages
Date: Wed, 12 Nov 2008 21:07:05 -0000
Message-ID: <C0F2465B4F386241A58321C884AC7ECC09526433@E03MVZ2-UKDY.domain1.systemhost.net>
In-Reply-To: <008601c944fd$950335c0$6801a8c0@oemcomputer>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
thread-topic: several messages
Thread-Index: AclE/Y11rskhSUukTPOhypMqsstFNgADClfg
From: michael.dillon@bt.com
To: ietf@ietf.org
X-OriginalArrivalTime: 12 Nov 2008 21:07:10.0703 (UTC) FILETIME=[A0D457F0:01C9450A]
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

> Huh?  Concrete, real example:  I send a message to an IETF 
> mailing list.
> A list subscriber's ISP rejects the forwarded message.  
> IETF's mailman drops the subscriber, because this has been 
> happened multiple times.
> I can't notify the subscriber, because their ISP also rejects 
> my email.
> My ISP is irrelevant to the scenario, and the (now former) 
> list subscriber doesn't even know this has happened, or why.
> 
> Another real, concrete example: some (but not all) messages 
> sent via my employer were tossed because one of my employer's 
> mail servers was listed on a blacklist.  As an employee, I 
> had no alternatives for sending mail - company policy 
> precluded the use of "webmail" alternatives via company 
> infrastructure.

This is the type of thing which should be discussed in a much
longer Security Considerations section, even if it is only
an informational RFC. A DNSBL sits in the middle of an
end-to-end email transaction, and there is a danger of this
type of mysterious man-in-the-middle effect. The issues
surrounding this should be openly disclosed in the RFC.
Many RFCs don't need more than a cursory Security Considerations
section, but this one does, partly because of its impact on
end-to-end email transactions, and partly because of its
overloading different meanings onto the DNS protocol.

If reputation systems are going to be an integral part
of the future Internet email service, then this existing
DNSBL needs to be properly documented, and it would be
fruitful to have a WG take on the task of designing something
that looks less like a temporary band-aid solution.

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