Re: Last Call: draft-klensin-rfc2821bis

Douglas Otis <dotis@mail-abuse.org> Thu, 20 March 2008 16:35 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietfarch-ietf-archive@core3.amsl.com
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B7428C165; Thu, 20 Mar 2008 09:35:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.872
X-Spam-Level:
X-Spam-Status: No, score=-102.872 tagged_above=-999 required=5 tests=[AWL=-2.435, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
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 FK6cJK1hZPnV; Thu, 20 Mar 2008 09:35:37 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 485123A6EA1; Thu, 20 Mar 2008 09:35:21 -0700 (PDT)
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 196D728C4D0 for <ietf@core3.amsl.com>; Thu, 20 Mar 2008 09:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 5Wj-1aeyAXdE for <ietf@core3.amsl.com>; Thu, 20 Mar 2008 09:35:19 -0700 (PDT)
Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 3783928C276 for <ietf@ietf.org>; Thu, 20 Mar 2008 09:35:19 -0700 (PDT)
Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 85029A94483 for <ietf@ietf.org>; Thu, 20 Mar 2008 16:33:01 +0000 (UTC)
Message-Id: <ECB5B617-410A-43E2-9594-437F03DB17A9@mail-abuse.org>
From: Douglas Otis <dotis@mail-abuse.org>
To: ietf list <ietf@ietf.org>
In-Reply-To: <fq67g8$6mj$1@ger.gmane.org>
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: Last Call: draft-klensin-rfc2821bis
Date: Thu, 20 Mar 2008 09:33:01 -0700
References: <20080227171826.98C293A6AFE@core3.amsl.com> <fq67g8$6mj$1@ger.gmane.org>
X-Mailer: Apple Mail (2.919.2)
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

While this response may be a bit late, the change in section 5.1  
indicating SMTP server discovery now explicitly supports IPv6 address  
records represents a significant change from RFC2821.

While a desire to retain current practices has some justification,  
extending an already dubious and archaic practice to the explicit use  
of IPv6 raises significant questions.

The level of misuse afflicted upon SMTP often results in an  
exploration of DNS SMTP discovery records to determine whether a  
purported domain might be valid in the forward direction.  To remain  
functional, reverse DNS checks are often avoided due to the poor level  
of maintenance given this zone.  A move to deprecate A records for  
discovery when performing these checks to ascertain domain validity  
would favourably impact the level of undesired transactions.  To  
combat rampant domain spoofing, some domains also publish various  
types of SMTP related policy records.  To counter problems related to  
wildcard policy records, a lack of policy may be conditioned upon  
presences of possible SMTP discovery records.

Adding IPv6 to the list transactions needed to qualify SMTP domains  
that is predominately triggered by geometrically growing levels of  
abuse or misuse appears to be a remarkably poor choice.  To suggest a  
domain might reply upon this mechanism again appears to be remarkably  
poor advice.  Reliance upon a communication system should not be  
predicated upon such a questionable mechanisms.  During the next  
disaster, would you want FEMA to not use MX records or to depend upon  
IPv6 address records?  Not including IPv6 as a discovery record would  
better protect networks in the face of growing misuse of SMTP while  
also better ensuring the integrity of SMTP.

-Doug
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf