Re: Last Call: draft-klensin-rfc2821bis

Keith Moore <moore@network-heretics.com> Wed, 26 March 2008 03:57 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 21EAB28C240; Tue, 25 Mar 2008 20:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.669
X-Spam-Level:
X-Spam-Status: No, score=-100.669 tagged_above=-999 required=5 tests=[AWL=-0.232, 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 O6pnX3mkdKKN; Tue, 25 Mar 2008 20:57:43 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C3928C159; Tue, 25 Mar 2008 20:57:43 -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 50A0D3A6A5A for <ietf@core3.amsl.com>; Tue, 25 Mar 2008 20:57:42 -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 PpD6Of2jb5pO for <ietf@core3.amsl.com>; Tue, 25 Mar 2008 20:57:41 -0700 (PDT)
Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 91D563A68B9 for <ietf@ietf.org>; Tue, 25 Mar 2008 20:57:41 -0700 (PDT)
Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by m1.imap-partners.net (MOS 3.8.4-GA) with ESMTP id APB82443 (AUTH admin@network-heretics.com) for ietf@ietf.org; Tue, 25 Mar 2008 20:55:21 -0700 (PDT)
Message-ID: <47E9C923.2090804@network-heretics.com>
Date: Tue, 25 Mar 2008 23:55:15 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>
Subject: Re: Last Call: draft-klensin-rfc2821bis
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>
In-Reply-To: <AADD02274043C6E6681E0407@p3.JCK.COM>
Cc: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, Ned Freed <ned.freed@mrochek.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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> 
> Ned, by "disable MX lookups", do you mean "don't put MX records
> into the DNS zone and therefore force a fallback to the address
> records" or "ignore the requirement of the standard that
> requires using MX records if they are there"?   If the latter,
> the behavior, however useful (or not) is, IMO, so far outside
> the standard that it is irrelevant to any discussion about how
> DNS records are used in a standard way.
> 
> Keith, what do administrative domains have to do with this? 

I can imagine wanting an option to skip MX record lookup for relaying 
mail within an administrative domain - if, say, all of the relevant 
domains within that administrative domain were known to have A records 
pointing to their inbound SMTP server.

By contrast, I have a hard time imagining a good reason to skip MX 
lookup for relaying mail from one administrative domain to another. 
(unless maybe there is a bilateral agreement between the source and 
destination domain that specifies how such mail is to be relayed.)

(I have no doubt at all that people ask for such a thing, but I am at a 
loss as to why such behavior should be blessed by the standards.)

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