Re: [ietf-smtp] Fwd: New Version Notification for draft-crocker-email-deliveredto-00.txt

Alessandro Vesely <vesely@tana.it> Sat, 06 February 2021 11:19 UTC

Return-Path: <vesely@tana.it>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CF63A10F7 for <ietf-smtp@ietfa.amsl.com>; Sat, 6 Feb 2021 03:19:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vD4aqhJtQXQS for <ietf-smtp@ietfa.amsl.com>; Sat, 6 Feb 2021 03:19:08 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16BF53A10F3 for <ietf-smtp@ietf.org>; Sat, 6 Feb 2021 03:19:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1612610343; bh=Jc6d0599LJcRqroHDZuXSCpQGgpuw0PApKHR0rCxfQ0=; l=2028; h=To:References:From:Date:In-Reply-To; b=CJtboE0CY/xumlV9KYrEniS6IHaEHm4nqqHl8h32Zo127MPmS7R9QMqEEMNisH6QO bklnwq1T/0iM9OF/WqpjFq938oRb2m9djpXcgpWMZVwSlM6XdBCf2AyJsCGNUmXbaP 2PF4FukwcK7uIqtTYLYiVq8vC8JFx60vJzlUt/+gtIBqk/p8HDK8w3NHsr6MU
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC050.00000000601E7B27.00000DB3; Sat, 06 Feb 2021 12:19:03 +0100
To: dcrocker@bbiw.net, Valdis Klētnieks <valdis.kletnieks@vt.edu>, ietf-smtp <ietf-smtp@ietf.org>
References: <161237978029.17564.1671203014287258223@ietfa.amsl.com> <ac72f2cc-7244-23d1-3615-a8f4e5f7388c@dcrocker.net> <468945c6-04f9-12c7-c49c-51badaf04ea2@tana.it> <33341.1612561465@turing-police> <b0c79f55-b4e2-710c-b290-465c3210885c@dcrocker.net>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <7b581545-47e2-b250-451e-4c76b35c9500@tana.it>
Date: Sat, 06 Feb 2021 12:19:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <b0c79f55-b4e2-710c-b290-465c3210885c@dcrocker.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/agC3qiXls9uiedRj3hhJcZ5eIEc>
Subject: Re: [ietf-smtp] Fwd: New Version Notification for draft-crocker-email-deliveredto-00.txt
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Feb 2021 11:19:10 -0000

On Fri 05/Feb/2021 22:53:34 +0100 Dave Crocker wrote:
> On 2/5/2021 1:44 PM, Valdis Klētnieks wrote:
>>
>> It's a plausible design that the agent doing final delivery accepts
>> responsibility for delivery to multiple local mailboxes (I've often had things
>> that ended up delivering to root@localhost and valdis@localhost with one
>> invocation of the local delivery agent, for example).


Even then, actual delivery usually happens one mailbox at a time, in a loop.


>> Should the agent generate two Delivered-To: headers, or does it *actually*
>> get generated appropriately for each copy (at a time later than when the
>> agent accepted responsibility)?

The second, IMHO.  Adding multiple Delivered-To: at once, one for each mailbox, 
would violate the MUST NOT in Section 5.


> The question for the specification is whether it makes clear what the 
> specification calls for.  I think it does, but if readers aren't clear about 
> it, it would be good to know what about it isn't clear enough.


Perhaps, the case of delivery to multiple mailboxes should be anticipated in 
Section 3.


> A different question is how to implement the specification, so as to conform to 
> the specification.
> 
> For storing a separate copy for each recipient, that seems straightforward.
> 
> For sharing a single copy of the message among multiple recipients, the answer 
> probably is not straightforward...


The case of shared IMAP folders is also straightforward.  The Delivered-To: 
contains the mailbox of that folder if it has one, or the mailbox of the 
recipient whose filter directed the message to that folder.

If the mail store implements messages to multiple recipients as files with 
multiple links, I see no way it can add a Delivered-To:.  Such a complicate 
system perhaps might resort to adding it on the fly whenever a MUA downloads 
the message.  Or it can do without.  Or maybe it may make sense to have 
something like Delivered-To: user-group-XXXX@example.com.


Best
Ale
--