Re: Last Call: draft-klensin-rfc2821bis

"Frank Ellermann" <nobody@xyzzy.claranet.de> Wed, 26 March 2008 13: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 4DD8B28C62A; Wed, 26 Mar 2008 06:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.85
X-Spam-Level:
X-Spam-Status: No, score=-100.85 tagged_above=-999 required=5 tests=[AWL=-0.413, 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 qGMSZkA9tlcC; Wed, 26 Mar 2008 06:48:45 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B713A69E3; Wed, 26 Mar 2008 06:48:45 -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 42E623A6860 for <ietf@core3.amsl.com>; Wed, 26 Mar 2008 06:48:43 -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 spJetwFkDNQ4 for <ietf@core3.amsl.com>; Wed, 26 Mar 2008 06:48:39 -0700 (PDT)
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by core3.amsl.com (Postfix) with ESMTP id 31B3728C220 for <ietf@ietf.org>; Wed, 26 Mar 2008 06:48:39 -0700 (PDT)
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JeVxF-00077m-RF for ietf@ietf.org; Wed, 26 Mar 2008 13:46:13 +0000
Received: from hmbg-d9b88e23.pool.mediaways.net ([217.184.142.35]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf@ietf.org>; Wed, 26 Mar 2008 13:46:13 +0000
Received: from nobody by hmbg-d9b88e23.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf@ietf.org>; Wed, 26 Mar 2008 13:46:13 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann <nobody@xyzzy.claranet.de>
Subject: Re: Last Call: draft-klensin-rfc2821bis
Date: Wed, 26 Mar 2008 14:17:22 +0100
Organization: <http://purl.net/xyzzy>
Lines: 55
Message-ID: <fsdk2t$4pa$1@ger.gmane.org>
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>
Mime-Version: 1.0
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: hmbg-d9b88e23.pool.mediaways.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
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

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:

| 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.

> 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.

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.].
 
> granted, lots of really really stupid things are done in 
> the name of spam filtering that make no more sense than
> this, but they're not "obvious" - they're just stupid

The duty to send DSNs is not about "spam filtering", it is
about the reliability of SMTP.  Dropping all undeliverable
IPv6-only reverse-path mails in an IPv4-only MRN can affect
90% spam, but where it affects the remaining good mails it
would be bad.

> of course, as a practical matter, any domain for which
> mail eventually ends up in an IPv6-only world is going
> to need to have at least one MX pointing to a IPv4-capable
> host, until IPv6 becomes ubiquitous or very nearly so.

> so the example above only makes sense in a world where
> IPv6 is ubiquitous

Bill did not say that it is a hypothetical example for the
times when IPv6 is ubiquitous, I took it for a real example
today.  As a practical matter, I have no idea which of my 
providers if any is able to reach an IPv6-only example.com

 Frank

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