IPv6 incentive? RE: Last Call: draft-klensin-rfc2821bis

"Hallam-Baker, Phillip" <pbaker@verisign.com> Wed, 26 March 2008 21:45 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 20B7928C7D9; Wed, 26 Mar 2008 14:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.766
X-Spam-Level:
X-Spam-Status: No, score=-99.766 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 hrNIyd5zwI24; Wed, 26 Mar 2008 14:45:48 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2E103A6CBF; Wed, 26 Mar 2008 14:45:46 -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 651533A6812 for <ietf@core3.amsl.com>; Wed, 26 Mar 2008 14:45:45 -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 uS3fARxHcVhx for <ietf@core3.amsl.com>; Wed, 26 Mar 2008 14:45:44 -0700 (PDT)
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 2D4A228C5FD for <ietf@ietf.org>; Wed, 26 Mar 2008 14:44:47 -0700 (PDT)
Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id m2QLgLN1009409; Wed, 26 Mar 2008 14:42:21 -0700
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Mar 2008 14:42:21 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: IPv6 incentive? RE: Last Call: draft-klensin-rfc2821bis
Date: Wed, 26 Mar 2008 14:42:20 -0700
Message-ID: <2788466ED3E31C418E9ACC5C316615572FF88E@mou1wnexmb09.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: IPv6 incentive? RE: Last Call: draft-klensin-rfc2821bis
Thread-Index: AciPDiMCmc0Dj8k2SOuXp9YJDx+b5wAes7K+
References: <01MSSXWZKKZ800007A@mauve.mrochek.com> <fs9blg$9in$1@ger.gmane.org><20080325133807.GA12616@boreas.isi.edu> <fsb3lo$gsd$1@ger.gmane.org><20080326023117.GA26917@boreas.isi.edu><01MSUMMIXZRA00007A@mauve.mrochek.com><47E9C09D.8020900@network-heretics.com><AADD02274043C6E6681E0407@p3.JCK.COM><01MSURGHV8XQ00007A@mauve.mrochek.com><47E9E93D.3060308@network-heretics.com> <01MSUUWPKRJS00007A@mauve.mrochek.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: Ned Freed <ned.freed@mrochek.com>, Keith Moore <moore@network-heretics.com>
X-OriginalArrivalTime: 26 Mar 2008 21:42:21.0435 (UTC) FILETIME=[45803CB0:01C88F8A]
Cc: John C Klensin <john-ietf@jck.com>, Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, ietf@ietf.org, Bill Manning <bmanning@ISI.EDU>
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: multipart/mixed; boundary="===============1316752720=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

It is pretty clear here that we are talking about a configuration that is actually specfically prohibited by 2821.
 
If you are doing SMTP and claiming to be 2821 compliant you must lookup the MX and you must not look at the A if there is no MX there. Any sender that is breaking those rules is not compliant with the spec.
 
Spam is relevant in this regard to the extent that when you have a protocol that is under such a level of sustained attack, it is entirely justified for receivers to employ strict compliance with the standard as an acceptance criteria. If you are not 2821 compliant then no soup for you.
 
 
I see no reason at all to extend support for non-compliant systems to the IPv6 world. On the contrary, it seems to me that this transition is exactly the point at which you would want to say that the host name fallback support is terminated.
 
The argument would become even stronger if it turned out that email comming over IPv6 transports could be more easily distinguished from spam than over other transports. This might even be turned into an incentive for making the IPv6 transition.
 
What I am thinking here is that we stand a better chance of authenticating IPv6 address block allocations and thus eliminating bogons. Residential support for IPv6 is non-existent today. We have a good chance of getting some BCP type agreements out of the likes of MAAWG that could limit botnet and spambot potential there.
 
Lets make IPv6 as clean as possible, leave host name A record fallback to the legacy world.
 
 
________________________________

From: ietf-bounces@ietf.org on behalf of Ned Freed
Sent: Wed 26/03/2008 2:48 AM
To: Keith Moore
Cc: John C Klensin; Frank Ellermann; Ned Freed; ietf@ietf.org; Bill Manning
Subject: Re: Last Call: draft-klensin-rfc2821bis



> It might be the case that it's useful for an MTA to have an option to
> skip MX lookup for specific destinations because of DNS brokenness at
> those destinations.  But this seems to me to be outside of the scope of
> the standard.

By the same token, discussions of gatewaying to non-Internet systems could be
considered "outside the standard". But RFC 2821 devotes many pages to
discussing this sort of thing.

> Skipping MX lookup is not acceptable as a general
> practice, nor is it something we want to encourage.

I never implied that it was acceptable. In fact I'm fairly sure I said
the exact opposite.

> In general, it's always been acceptable to configure an MTA to handle
> mail in some special-case way for specific domains where there was
> specific knowledge such that the special-case handling made sense for
> those domains.  The MX-then-A lookup is what you should do in the
> absence of any such knowledge.

Yep.

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


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