Re: Last Call: draft-klensin-rfc2821bis

Keith Moore <moore@network-heretics.com> Wed, 26 March 2008 17:48 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 715D03A69F1; Wed, 26 Mar 2008 10:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.594
X-Spam-Level:
X-Spam-Status: No, score=-100.594 tagged_above=-999 required=5 tests=[AWL=-0.157, 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 1AAbHWlQoCi7; Wed, 26 Mar 2008 10:48:46 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2283A6E1B; Wed, 26 Mar 2008 10:48:19 -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 0FCC428C5EA for <ietf@core3.amsl.com>; Wed, 26 Mar 2008 10:48:18 -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 IEvQAKgpD5A9 for <ietf@core3.amsl.com>; Wed, 26 Mar 2008 10:48:17 -0700 (PDT)
Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 7C1C13A69A3 for <ietf@ietf.org>; Wed, 26 Mar 2008 10:48:15 -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 APD05528 (AUTH admin@network-heretics.com) for ietf@ietf.org; Wed, 26 Mar 2008 10:45:55 -0700 (PDT)
Message-ID: <47EA8BCD.8030001@network-heretics.com>
Date: Wed, 26 Mar 2008 13:45:49 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.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><fsdek6$ep5$1@ger.gmane.org> <47EA412C.3040606@network-heretics.com> <fsdk2t$4pa$1@ger.gmane.org>
In-Reply-To: <fsdk2t$4pa$1@ger.gmane.org>
Cc: ietf@ietf.org
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


Frank Ellermann wrote:
> Keith Moore wrote:
>  
>> IPv4-only hosts can see the AAAA record even if they can't 
>> directly send mail to that address.  and there's no reason
>> ("obvious" or otherwise) why a MTA should reject mail from
>> a host just because that MTA can't directly route to it
> 
> What I wrote was "at their border", that is not any MTA on a
> route from sender to receiver.  "At their border" is the hop
> where receivers decide if they accept the mail, or reject it.
> 
> If they accept it, and later find they can't deliver it, and
> it is not a case for /dev/null, they MUST report the problem:

you're assuming lots of conditions there that don't apply in the general 
case... e.g. single-hop internal routing for inbound mail and yet the 
MTA can't detect that the mail is nondeliverable until after it has 
accepted it, and no designated relay to the IPv4 world for outbound 
mail.  the former is occasionally true, the latter would be insane.  one 
way to look at it is that the border for inbound mail may be different 
than the border for outbound mail.

> 
> | it MUST construct an "undeliverable mail" notification
> | message and send it to the originator of the undeliverable
> | mail (as indicated by the reverse-path).
> 
> For IPv4-only back to IPv6-only that cannot work, therefore
> the IPv4-only border MTA is obliged to reject mails with an
> IPv6-only envelope sender address.

often, the inbound MTA for a domain lacks reliable knowledge of whether 
either the sender or recipient address is actually valid.  it appears 
that you would have the inbound MTA drop mail based on a very dubious 
presumption.  you would rather cause additional delivery failures of 
subject messages than to risk the failure of nondelivery reports.  most 
operators, I think, would have the opposite preference.  and regardless 
of what 2821 says, I don't think your reading of it is justified.

>> there's nothing that requires a user to use the same MTA
>> for outbound mail that is used to receive inbound mail.
> 
> My definition of IPv4-only is that there is no other route.

that's a pretty useless definition because the case would not exist in 
practice until IPv6 were ubiquitous.  there's always the possibility for 
an IPv6-only domain to contract with an MTA sited on both v4 and v6 to 
relay outgoing mail.  it would be insane for an IPv6-only domain that 
wanted to send and receive mail to not have such an arrangement.

> The IPv4 border MTA needs to know if that is the case or not
> for its decision to accept or reject IPv6-only envelope
> sender addresses, because if all else fails it MUST [s.a.].

if we were to take your presumption to its logical conclusion, every 
inbound MTA should just reject all mail - since it can never be 100% 
certain of being able to either deliver the message or send an NDN.

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