Re: [yam] Issue #10: RFC 5321 3.9: add tiny subsection

SM <sm@resistor.net> Tue, 08 December 2009 22:53 UTC

Return-Path: <sm@resistor.net>
X-Original-To: yam@core3.amsl.com
Delivered-To: yam@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08BE03A6834 for <yam@core3.amsl.com>; Tue, 8 Dec 2009 14:53:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level:
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599]
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 KVup5H80UnxD for <yam@core3.amsl.com>; Tue, 8 Dec 2009 14:53:03 -0800 (PST)
Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 5C40E3A69AB for <yam@ietf.org>; Tue, 8 Dec 2009 14:53:02 -0800 (PST)
Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id nB8MqeFE000819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Dec 2009 14:52:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1260312770; x=1260399170; bh=VIfuJ3SCzi2MmRk0QwHFThC4nxFgKrelcXj/Sn7DCGA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=bY1AdG5048zWd7e/PXGeV1D7v+n6PI6vy56NrG7NlYuESXgw2MFoTGIeA+jDQss96 EmIC9LyPKa7lMaWyPvp73Xr+VyL3bjIpOf8jQKlZQohjmb9xqnEo1F74VE2mF/LM96 YFYmR9RkRlWjW4lMQr+zBMRIJ2O6SsYXprn1nJLU=
DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=jppFKHrKUmbVErXlca6n2/gRBuJZVQhMf5buaDx8BnTGxI93xHN5B6HSrcNyMMUnV VVbgt0AsnhpuwQ6i7pipeE7bpcha7EuetevbcbymasNWxljxTu7HvK3A5K5BGTiVrQl w2+WIR/g3LhffcNyUtE6B1rnV2wlLYdpd9vJ+WQ=
Message-Id: <6.2.5.6.2.20091208135556.030cfb28@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 08 Dec 2009 14:51:19 -0800
To: Alessandro Vesely <vesely@tana.it>
From: SM <sm@resistor.net>
In-Reply-To: <4B1E0967.1040006@tana.it>
References: <6.2.5.6.2.20091206014538.033cdcc8@elandnews.com> <4B1BE2D5.9010405@tana.it> <6.2.5.6.2.20091206102946.04601b90@resistor.net> <01NGXSHS3NUQ0000BI@mauve.mrochek.com> <4B1CDDE8.2090100@tana.it> <6.2.5.6.2.20091207072413.047ff4a0@resistor.net> <4B1E0967.1040006@tana.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: yam@ietf.org
Subject: Re: [yam] Issue #10: RFC 5321 3.9: add tiny subsection
X-BeenThere: yam@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Yet Another Mail working group discussion list <yam.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/yam>
List-Post: <mailto:yam@ietf.org>
List-Help: <mailto:yam-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2009 22:53:04 -0000

Hi Alessandro,
At 00:08 08-12-2009, Alessandro Vesely wrote:
>No, it's a tentative guess. That section currently contributes to 
>make it ill-defined. Eliding the term or replacing it with "mailing 
>lists" may better that state of affairs with minimal changes. 
>Alternatively, slightly restructuring the section may be an occasion 
>to reword it and also restate the concept of forwarding and its implications.

 From Section 2.1:

   "In other words, message transfer can occur in a single connection
    between the original SMTP-sender and the final SMTP-recipient, or can
    occur in a series of hops through intermediary systems."

I gather that you are viewing "forwarding" as when the final 
SMTP-recipient being changed by an intermediary system.  In technical 
terms, we could have different types of forwarding; for example the 
address correction in Section 3.4.  Section 3.7.2 also discusses 
about forwarding where the message goes through a gateway.  From an 
implementation perspective, we might talk about aliases, as mentioned 
in Section 3.9.1, or the .forward which can be set by a 
user.  There's also the case of this mailing list which forwarded 
your message to me.  Section 3.9.2 refers to that as "redistribution".

The main problem doesn't seem to be with forwarding; it's more about 
the return path and/or authorization.  It's up to the WG to determine 
whether restating all that would be a minimal change.

Regards,
-sm