From nobody Fri Jan 1 08:24:39 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5EB3A005D for ; Fri, 1 Jan 2021 08:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 6nMrTrxVDYgq for ; Fri, 1 Jan 2021 08:24:35 -0800 (PST) Received: from cyan.elm.relay.mailchannels.net (cyan.elm.relay.mailchannels.net [23.83.212.47]) (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 462BB3A0045 for ; Fri, 1 Jan 2021 08:24:34 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2D186701F82 for ; Fri, 1 Jan 2021 16:24:34 +0000 (UTC) Received: from nl-srv-smtpout3.hostinger.io (100-96-1-8.trex.outbound.svc.cluster.local [100.96.1.8]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 4419C701EF9 for ; Fri, 1 Jan 2021 16:24:33 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout3.hostinger.io ([UNAVAILABLE]. [145.14.159.243]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Fri, 01 Jan 2021 16:24:33 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Tart-Sponge: 3612c56e1491558c_1609518273816_980973486 X-MC-Loop-Signature: 1609518273816:3537922445 X-MC-Ingress-Time: 1609518273816 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout3.hostinger.io (smtp.hostinger.com) with ESMTPSA id 591B931C2C54 for ; Fri, 1 Jan 2021 16:24:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1609518271; bh=dyWL3AxVxkNP36IyOZo8zLfZhI1pQqncXORRx2SC+Go=; h=Reply-To:Subject:From:To:References:Date:In-Reply-To; b=gjDPni3mhMM44QYUxLEN19Ed2HWoP5nle/YS05VpOZzErKaXhN3wkiYR04CsK/pXw pnuwGvIGKs9J9lKC66XzjBltAYR3lmr/5I6DLXRseM0yJzUGf6BlBNa9b7AYsWXK2u /IOLGL20wu8+JF+KvVDztg4+EZG0Gw0rTnDIjcpqSgzLPzQRC/8dmZL4bCcVC+jA3e 0MSRnuylC2HCMt7Of/Nx1P9ieFpiSsD5mmCJazD48bblpIP3IKcnjoIHlEi9Qg9YfL Pa90AnH0YYmt6TIukshnankTU/touKzOrNv14/yFBqj1gvF9k++GhQjDNVRb7hRDXM rWBQtGsercEeg== Reply-To: dcrocker@bbiw.net From: Dave Crocker To: emailcore@ietf.org References: <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> Organization: Brandenburg InternetWorking Message-ID: Date: Fri, 1 Jan 2021 08:24:29 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2021 16:24:37 -0000 On 12/31/2020 1:09 PM, Dave Crocker wrote: > 3. ? Drat. Just started to throw some basic text into a draft and I've already run into an issue that might or might not creates some challenges. Rather than pursue this in terms of fine-grained details, I'll ask you all to first consider what information we would like a recipient's MUA to have access to. Then we can worry about how to engineer the details. In the simple case, the RCPT TO contains an address and, indeed, the recipient's MUA resides at that address. The message has gone through a single SMTP posting/delivering sequence. Mailing lists (including Aliases) and other post-processing facilities, make things more interesting. They create multiple posting/delivery sequences. The final recipient address is not what the author generated in the initial RCPT TO field. Should the recipient's MUA have access to the /sequence/ of RCPT TO addresses used to get to them? Should they have only the final one? Should they have only the original one? Should they...? Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jan 1 12:18:40 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE063A0C7B for ; Fri, 1 Jan 2021 12:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 wUWLpxp4yNV0 for ; Fri, 1 Jan 2021 12:18:36 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 714293A0C77 for ; Fri, 1 Jan 2021 12:18:36 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kvQsc-000MGZ-TQ for emailcore@ietf.org; Fri, 01 Jan 2021 15:18:34 -0500 Date: Fri, 01 Jan 2021 15:18:28 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: <8034D30CAC474E52B15C1AC4@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Emailcore] Navigating 5321bis (and predecessors) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2021 20:18:39 -0000 Hi. In trying to look for some other things today, I was reminded of an issue that I think we should be clear about. RFC 2821, and hence 5321 and, in its present form, 5321bis, are badly organized and show the results of basically being a merge of three separate documents written at very different times. Those documents -- and consequently different sections of 2821 and 5321 -- depending a bit on how you count, show the different writing styles and perhaps the motivations of as many as seven different authors. The result is that it is over-long and it is hard to find things. As a specific example from yesterday, Dave wrote "with apologies to all, for my reading comprehension, limitations, but would someone point to the place in RFC 5321 where the semantics of the FOR clause are explained, and especially in terms of it's coming from a RCPT TO?" The implicit question of whether that portion of the specification appears and where to find it turns out to be hard to answer, much harder than it ideally should be, and that problem is by no means limited to a particular clause in a particular trace header. We ended up in this uncomfortable situation because of a decision at the time of DRUMS, reaffirmed at the time of YAM, that the disadvantages of doing things that way were outweighed by the risks of making inadvertent and problematic changes in the process of a rewrite. It doesn't make much difference then and shouldn't now, but I came to conclude (along with many others) that it was the right decision even though I hated it then, still do, and my dislike gets stronger every time someone says "I dare you to find where it says that" or "probably this paragraph should be somewhere else". I'm adding a warning note about this to 5321bis-02. The WG should decide whether it should be rewritten or removed prior to Last Call or publication. Two questions I'd like WG participants to think about: (1) How much reorganizing and rewriting do we want to do and what are our stopping rules? Moving a paragraph from one place to another (as in Erratum 1851; Ticket #28) seems rather easy and safe. Changing section titles and/or rewriting their introductory paragraphs may be a bit more risky. Or, in principle, we could reverse the decision above and start on a large-scale rewrite. WHatever we choose, I think it would help to have some sort of consensus about our target sooner rather than later. (2) Are there ways that we can mitigate the problems with finding things. The index in 5321 (and carried forward into 5321bis) was created as part of a compromise with the IESG after the Last Call closed on what became 5321. Because of how elements are handled in xml2rfc v2, those index entries should up as pointing to page numbers (as do the index entries in RFC 7749. Presumably xml2rfc v3 will show section numbers. Do we want to retain the index? If so, are there additional things that could and should be indexed? In particular, it occurs to me that, with some hours of work, I could index keywords from section titles. Would that be worth doing in terms of finding information or is the table of contents sufficient? Other ideas? thanks, john From nobody Fri Jan 1 14:17:29 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8F13A0D43 for ; Fri, 1 Jan 2021 14:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 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, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Tibp1i+N; dkim=pass (2048-bit key) header.d=taugh.com header.b=smImYFBN 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 c9cgrEGtl8mY for ; Fri, 1 Jan 2021 14:17:26 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 6E4903A0D45 for ; Fri, 1 Jan 2021 14:17:25 -0800 (PST) Received: (qmail 50504 invoked from network); 1 Jan 2021 22:17:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=c546.5fef9f74.k2101; bh=aY5knwoiSiLrgXV+PMcsguBiOpm3Kvofv4+ZGE2PksA=; b=Tibp1i+Nkgtam6pC4Ny/4gIa/lFtzq2qtCtqL1xNnxwJh2RTGag4EN+eaJ4zoZfw7F5qGKPoTg2gLRws2z1bcVfA9SOZnHYEUyWy/G+v0vMNs4Zr1NHShZU5tmgeO5AgEdxAnwbYtD+HxJvFtV7r1kMv8nDt98ywNVHVgFSA3acJjVX+56Jr5AHuV3pHdegd8WC/FawJBR72JBGMqCpbbRvLWfJF0JJpUrpr8N4yO2flzcQWgyhopVKF7I/EMqNojkyKa2kOvpI2OfZrN2yrIEbQMBEWZe+zef5vIxpub0gByB1vj6FwxytG1s7tHMiSdpo7fpNvPM+s2YR23/fzjQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=c546.5fef9f74.k2101; bh=aY5knwoiSiLrgXV+PMcsguBiOpm3Kvofv4+ZGE2PksA=; b=smImYFBNi/wAiFNDmzIH2yQ7ekk2geZqsPJfVa8zNLrG0Gukx+teDxphdtTbu2sGlw16tquzfSCnjOKNU2I2r10/RnqnekKBAEpMYZGoEfyTT0qZkhXzxvNtNL0lgLkEKRJjyUh6IPJ/PvYeMi2ups5+BE26QqK+IVRIspSNIQOsLCXVwZiX5n1HR8XOT37RCONcKb/bXzGTxkX1CAN6vIMqmcEUXTzc/AsldsJvUU2hMfpGT5ohKxUCx0YrlFFdYF0avp9EHmrb6lVFi/HlQ4NT3kMFouRKEfQfuHy82Q8aYLtm/0f9D1VXw9cHi215WJ8d1KSTq4hlE4Mkv8RIHg== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 01 Jan 2021 22:17:24 -0000 Received: by ary.qy (Postfix, from userid 501) id ED67D45047D9; Fri, 1 Jan 2021 17:17:23 -0500 (EST) Date: 1 Jan 2021 17:17:23 -0500 Message-Id: <20210101221723.ED67D45047D9@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2021 22:17:28 -0000 In article you write: > Should the recipient's MUA have access to the /sequence/ of RCPT TO > addresses used to get to them? If we're documenting existing practice, which I think would be a good idea, yes. R's, John From nobody Fri Jan 1 14:23:48 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0B03A0D6F for ; Fri, 1 Jan 2021 14:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Atceqkd8; dkim=pass (2048-bit key) header.d=taugh.com header.b=vxAZxTBc 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 geo-dCB7RdhP for ; Fri, 1 Jan 2021 14:23:44 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 BAB5B3A0D66 for ; Fri, 1 Jan 2021 14:23:43 -0800 (PST) Received: (qmail 53117 invoked from network); 1 Jan 2021 22:23:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=cf7b.5fefa0ee.k2101; i=johnl-iecc.com@submit.iecc.com; bh=+YWWo4Zjg8/B3jG6w2442IZQ37OS1lP7aU26sSY7IrA=; b=Atceqkd8RMQs50JwWNnExPL+nGWeQPs0iwfDYz3jQKELA1AZ7od6G5I8D5GrmPG2tU50ydJs/bNRpI9ydTwhPMF/T4W+zJ8KLGSzST5tzfZm/oW6P6/Zx5DDGt67S7cWRoF3/S9kH0k7d6hTraslebY3esqd+/1tVl4r8o1HEZ52ytx2QYySO6ALnsjFAq+41PigsYThy/hbQjb6Mbvs20v1RmIebC6TH9CIfu4M8zhe+xF2F5ZVAXODmBsjlXr6tnjHS/wOUd0p1pQnSWpN15EL83hv7Sc+Ijp2b3QPWiCD28EovnDSO5N9Jn9lReGeiQIAptCwjJayLxZTOwAa4g== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=cf7b.5fefa0ee.k2101; olt=johnl-iecc.com@submit.iecc.com; bh=+YWWo4Zjg8/B3jG6w2442IZQ37OS1lP7aU26sSY7IrA=; b=vxAZxTBcMzg8Z1ENSQgLJ3VaehIyDT92NvSc4R9g9mWj8OohImjtDlOKiSqi3VNWu1YFa9RKoqffavyNaSHmk/LwCRuimp5dDJ7JQiakcVVtPOavPyAZVhhllZsQH940k8sF3PU+1CAYRUVAl42a+jdot2P66i6oCgYh55y0qYkhi91b3RUjoFiFXIJceB5xtJyLFZBxJkNr8a4HuvCT4wfnq4WFeSaYbF6OfPvwDtCWWU02UWNP0aWWfBDduiGOTm0vnqFxNohKD9ml2eJIeNXn1CVEfrOlOgKUQh9RkS8XjzWQbDbAFdJJ5A1ruGF3S8GlwmHIQCKMnFgbSLbP7g== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 01 Jan 2021 22:23:41 -0000 Date: 1 Jan 2021 17:23:41 -0500 Message-ID: <4860de0-38f4-3d86-6c55-398f906242e@taugh.com> From: "John R Levine" To: emailcore@ietf.org Cc: "Dave Crocker" In-Reply-To: <20210101221723.ED67D45047D9@ary.qy> References: <20210101221723.ED67D45047D9@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2021 22:23:46 -0000 On Fri, 1 Jan 2021, John Levine wrote: > In article you write: >> Should the recipient's MUA have access to the /sequence/ of RCPT TO >> addresses used to get to them? > > If we're documenting existing practice, which I think would be a good idea, yes. Also remember that it's used to detect mail loops, and if you have a loop like A->B->C->A you need the history to see that you're looping. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Jan 1 14:38:25 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567073A0C51 for ; Fri, 1 Jan 2021 14:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ZS13APtsgrhS for ; Fri, 1 Jan 2021 14:38:22 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD313A0C13 for ; Fri, 1 Jan 2021 14:38:22 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kvT3t-000Mv2-HC; Fri, 01 Jan 2021 17:38:21 -0500 Date: Fri, 01 Jan 2021 17:38:15 -0500 From: John C Klensin To: dcrocker@bbiw.net cc: emailcore@ietf.org Message-ID: <092D2182F3BEFC786DBAD1CD@PSB> In-Reply-To: References: <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2021 22:38:24 -0000 --On Friday, January 1, 2021 08:24 -0800 Dave Crocker wrote: > On 12/31/2020 1:09 PM, Dave Crocker wrote: >> 3. ? > > > Drat. Just started to throw some basic text into a draft and > I've already run into an issue that might or might not creates > some challenges. > > Rather than pursue this in terms of fine-grained details, I'll > ask you all to first consider what information we would like a > recipient's MUA to have access to. Then we can worry about > how to engineer the details. > > In the simple case, the RCPT TO contains an address and, > indeed, the recipient's MUA resides at that address. The > message has gone through a single SMTP posting/delivering > sequence. > > Mailing lists (including Aliases) and other post-processing > facilities, make things more interesting. They create > multiple posting/delivery sequences. The final recipient > address is not what the author generated in the initial RCPT > TO field. > > Should the recipient's MUA have access to the /sequence/ > of RCPT TO > addresses used to get to them? > > Should they have only the final one? > > Should they have only the original one? > > Should they...? > > > Thoughts? Dave, Despite your comment about semantics of the "for" clause (with which I agree - see note about navigating 5321bis), I think two parts of the above are fairly clear for another reason: if the message passes through an MTA and is either passed along or altered an any way, the general expectation is that it will put in a Received: header field. And stripping or altering prior Received: headers or header fields is generally considered bad practice [1]. If either of those things are not clear enough in 5321bis, I encourage you to post a specific comment about that and encourage either Alexex to open a ticket and/or me to make Appendix G longer [2]. First, one Received: header field, at most one FOR clause and, if FOR is present, its value is one (see the syntax for FOR) Mailbox (or, in principle, a PATH, but source routes are rather strongly deprecated (see Section 3.3 and Appendix C). So, if one wanted to have multiple destination addresses, there would be no place to put them. In addition, while 5321 does not appear to make the issue explicit, the discussion in Section 3.3 about exposure of addresses can be read as discouraging use of FOR clauses in trace information entirely. Beyond that, while, as you have pointed out, there is no specification of semantic in 5321 (or 821 or anything in between), there are common-sense limitations on what can go there. For unextended SMTP MTA in mail transport (not submission server) use, the only places a Mailbox can cone from are a MAIL command (makes no sense), RCPT command(s), and prior "Received:" header fields (which it is prohibited from inspecting). A submission server (or other MTA communicating directly with an originating MUA if there is such a thing) might have additional or alternate information that could, in principle, be put into the FOR clause, but that is it. So, if something is going to be copied into a Received-type trace field, it has to come out of the RCPT commands to the SMTP server inserting the trace field (again, possibly excepting the first hop). That doesn't answer any of your questions above, but it imposes rather severe constraints on the information that might be available. best, john [1] See the paragraph starting "As discussed in Section 6.4..." in Section 3.6.3. I now wonder whether that section should be retitled or reorganized because it contains significant text that is not limited to Message Submission at all. Watch for a separate message on parts of those two sections. [2] Except for order and unless one of us gets it wrong, those options are essentially equivalent. > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net From nobody Fri Jan 1 15:57:05 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CF73A0E3C for ; Fri, 1 Jan 2021 15:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 CKomK-R5a5Qi for ; Fri, 1 Jan 2021 15:57:02 -0800 (PST) Received: from dog.birch.relay.mailchannels.net (dog.birch.relay.mailchannels.net [23.83.209.48]) (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 64DE03A0E3B for ; Fri, 1 Jan 2021 15:57:02 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 4E3F112181F; Fri, 1 Jan 2021 23:57:01 +0000 (UTC) Received: from nl-srv-smtpout4.hostinger.io (100-96-87-21.trex.outbound.svc.cluster.local [100.96.87.21]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 4806C121832; Fri, 1 Jan 2021 23:57:00 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout4.hostinger.io ([UNAVAILABLE]. [145.14.159.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Fri, 01 Jan 2021 23:57:01 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Tasty-Battle: 14971e017bc59a4e_1609545420960_3820013226 X-MC-Loop-Signature: 1609545420960:63895799 X-MC-Ingress-Time: 1609545420959 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout4.hostinger.io (smtp.hostinger.com) with ESMTPSA id 2C49D31A0C60; Fri, 1 Jan 2021 23:56:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1609545418; bh=Vg6qQPTD0OzAOF28d2/wZ1h6JxGfCpoeM4AKQAeyiAI=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=oFCkOiuRwdaeDcNSMVeubRkZSq3TwqOb6f5HN4A7Kl/9zuc0OYyOR+eH/hgqZ+750 yKRg1OYRewe4ELpNsHacjaYxPYK9r2nhbLo/NCLvRiM3cAUpuu7yMZc7hBE0hihIfq 0UvAeU8iVmkYm9Zb18E93hbFGewjDnbNcefspvFypgJEY5UiOsiWrWgvl3sIInFcO/ 8U/ckkIh/+fP5lJ/Ax3Kxbx3a2YVKK7XAWFkR7CldkCfsDsFyCVqSbJNm7WJJ72VVC Hv0pA2ZkyKdIComi1ongWeC4YMLQzzgiSvgWigSjPil20SIy8d0YX50VB3VNuhjYUm lSNfuusNWOF+A== Reply-To: dcrocker@bbiw.net To: John C Klensin , emailcore@ietf.org References: <8034D30CAC474E52B15C1AC4@PSB> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Fri, 1 Jan 2021 15:56:55 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <8034D30CAC474E52B15C1AC4@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Navigating 5321bis (and predecessors) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2021 23:57:04 -0000 On 1/1/2021 12:18 PM, John C Klensin wrote: > (1) How much reorganizing and rewriting do we want to do and > what are our stopping rules? None of the first and as little as is reasonable of the latter. The purpose of the current effort is to expedite elevation to full Standard. Any effort that is 'substantial' puts that at risk. In the case of the particular issue I raised about 'FOR', it makes sense to add some text that defines its semantics. It doesn't make sense to make a major effort of -- or resulting from -- that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jan 1 17:25:19 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E733A0418 for ; Fri, 1 Jan 2021 17:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=qhuhbD18; dkim=pass (2048-bit key) header.d=taugh.com header.b=lE/a2Om6 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 JUK8hKL6OW3z for ; Fri, 1 Jan 2021 17:25:14 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 194BB3A040B for ; Fri, 1 Jan 2021 17:25:13 -0800 (PST) Received: (qmail 12983 invoked from network); 2 Jan 2021 01:25:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=32b4.5fefcb78.k2101; i=johnl-iecc.com@submit.iecc.com; bh=g+/CZi6z6P2nYJWRKfMt7APdY2oGVHoYyDE3U3t1po8=; b=qhuhbD18g8a4HwAUFOEXcc4EwIuJgQnH059VdXMtM7qMA/Sf1bZjIyu3r9RuALaYVHwbhXDXflX7Z+0q6LnWWcJSaPZKcvlxfHJ4OcS3WCpUogYIjRxbv+5oDfjS/gestV9ONKaUJDcL9H0iH3GiZr01OIZxdMpxMwxapyMRuft5jV9urz4q+iBsalsmW7kQPLLmp3dtfHYOeHtthD/E4h7Za45DmPzrG3/rrEfBN4KDAsCrCZyd3NOEVHl1ieo5+cLlwVKJuiZX/tvkAY+IXjChvWouXeShf7dQmESgiirfQ48kulWR0uFNGjRSoN/QPCVXYz8CpDJS1HVH+WD80A== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=32b4.5fefcb78.k2101; olt=johnl-iecc.com@submit.iecc.com; bh=g+/CZi6z6P2nYJWRKfMt7APdY2oGVHoYyDE3U3t1po8=; b=lE/a2Om66d/EKZgBFNihN6R38Qc9o3N0xkMlBztHfqV4ilB9DpQBd39riCbgu1PcA+dTgy/IrmVUn1+/94Skjg5NFRc71IMvrxQlK5rKHUC8wdY+emFE/Vwi3Eb/dyQCLkxP7anPw0hl8Py9m07lQ6MIKruupQ671RNPQgJTC5rGZy+3BhPf8niDZZxleWH/G1T0xp9xuMEwu7kkPJB/Ri/KwpD2pChQ6sSSZo5em2QhNVN5t2M4veaVrQx9FVLuWItp3ALJbuU3qQ/3+ZMMNIxSdL3PcxkkwRRG/0sRQwlNM1VGWN44i0N2TPeftpbXwqcOVB9+dm7gROiWfGJbBA== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 02 Jan 2021 01:25:12 -0000 Date: 1 Jan 2021 20:25:11 -0500 Message-ID: From: "John R Levine" To: "Dave Crocker" , emailcore@ietf.org In-Reply-To: <5461cf6d-270a-cf39-12c0-9754acf90ed2@dcrocker.net> References: <20201231223339.D22303F108F2@ary.qy> <5461cf6d-270a-cf39-12c0-9754acf90ed2@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 01:25:16 -0000 >>> 1. Why a separate header field, rather than Received's FOR clause? >> What jck said, the mailbox into which a message is delivered often has >> a different name from what was in the RCPT TO. That's particularly >> likely on systems that handle mail for multiple domains. > > with apologies to all, for my reading comprehension, limitations, but would > someone point to the place in RFC 5321 where the semantics of the FOR clause > are explained, and especially in terms of it's coming from a RCPT TO? I don't think it does. Section 4.4 says it contains one path even if there are multiple RCPT commands, 7.2 says sort of indirectly not to put blind recipient addresses into the received header, 7.6 reiterates the blind recipient stuff. On the other hand I think it is clear from context that the FOR clause is supposed to contain a RCPT TO argument, with considerable ambigiuity which one to use if there were several recipients, and whether to include it at all. The stuff in 7.2 and 7.6 seems to be saying to look at the message header and only include the FOR if it matches one of the header recipients, but ugh. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Jan 1 18:46:07 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18BC3A0AD5 for ; Fri, 1 Jan 2021 18:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9xjSrY6Ry6A5 for ; Fri, 1 Jan 2021 18:46:03 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4348D3A0AD4 for ; Fri, 1 Jan 2021 18:46:02 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kvWvZ-000OTK-DW; Fri, 01 Jan 2021 21:46:01 -0500 Date: Fri, 01 Jan 2021 21:45:54 -0500 From: John C Klensin To: dcrocker@bbiw.net, emailcore@ietf.org Message-ID: <9FA761F82035CF5880F22A03@PSB> In-Reply-To: References: <8034D30CAC474E52B15C1AC4@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Navigating 5321bis (and predecessors) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 02:46:05 -0000 --On Friday, January 1, 2021 15:56 -0800 Dave Crocker wrote: > On 1/1/2021 12:18 PM, John C Klensin wrote: >> (1) How much reorganizing and rewriting do we want to do and >> what are our stopping rules? > > None of the first and as little as is reasonable of the > latter. The purpose of the current effort is to expedite > elevation to full Standard. Any effort that is 'substantial' > puts that at risk. Speaking personally, agreed. However, I note that we have already moved one paragraph and that counts as "reorganizing", at least as I used that term. I would summarize the principle as "don't open cans of worms", but that interpretation of your comment has some interesting implications. > In the case of the particular issue I raised about 'FOR', it > makes sense to add some text that defines its semantics. It > doesn't make sense to make a major effort of -- or resulting > from -- that. An interesting example because, as soon as we try to pin down the semantics, we probably should address the question of whether, in today's privacy-sensitive world, supplying that clause at all is a good idea [1]. It may be relevant to a discussion of that topic that, while hop-by-hop transport encryption would hide that information on the wire, message headers (including trace fields) need to be in cleartext for SMTP trace fields/ time stamps to function properly. To make the situation a little more entertaining, RFC 6409 is not explicit as to whether the submission server is required to insert a time-stamp field although the requirement in the third paragraph of Section 8 certainly implies that. Because a submission server is explicitly allowed to resolve local aliases (important for SMTPUTF8 and I have no idea what people on this list call others in the privacy of their local environments), exposing one of those aliases in a FOR field might be a bad idea even if it had the syntax of a Mailbox name. In other words, while I would favor putting in some words about the semantics of the FOR clause (and any other clauses of a time-stamp field whose semantics are missing or vague), we need to understand that even something that seemingly trivial might open one of those cans of worms. john [1] Note that aspect of the FOR clause is already addressed, albeit with a bit of handwaving, in Section 7.6 _and_ I don't even know exactly what the last sentence of that section means given that a given Received: field can only accommodate at most one FOR clause with exactly one Mailbox (now noted in -02). From nobody Fri Jan 1 18:54:21 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD953A0AEE for ; Fri, 1 Jan 2021 18:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3HXCzcx56suH for ; Fri, 1 Jan 2021 18:54:18 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECB3E3A0AEC for ; Fri, 1 Jan 2021 18:54:17 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kvX3W-000OWn-3t; Fri, 01 Jan 2021 21:54:14 -0500 Date: Fri, 01 Jan 2021 21:54:07 -0500 From: John C Klensin To: John R Levine , Dave Crocker cc: emailcore@ietf.org Message-ID: <359B212EA8F6B28438D0106C@PSB> In-Reply-To: References: <20201231223339.D22303F108F2@ary.qy> <5461cf6d-270a-cf39-12c0-9754acf90ed2@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 02:54:19 -0000 --On Friday, January 1, 2021 20:25 -0500 John R Levine wrote: >... > The stuff in 7.2 and 7.6 seems to be saying to look at the > message header and only include the FOR if it matches one of > the header recipients, but ugh. FWIW, especially given the other text in the document that strongly discourages looking at and interpreting the message header, I don't read those sections that way. Instead, I can read them as making a strong case that, if multiple RCPT commands have been [successfully ?] processed, putting in a FOR clause is just a bad idea. Which brings me to the next obvious question: should we just go ahead and say that in 7.2 (or in the text about semantics that I hope to see soon). And, if we do that, should we just lose the last sentence of 7.6 or change it to discuss other information that might go into FOR but be sensitive? john From nobody Sat Jan 2 05:48:15 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88883A0489 for ; Sat, 2 Jan 2021 05:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 EONChbJAGGeC for ; Sat, 2 Jan 2021 05:48:12 -0800 (PST) Received: from hedgehog.birch.relay.mailchannels.net (hedgehog.birch.relay.mailchannels.net [23.83.209.81]) (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 550AE3A0475 for ; Sat, 2 Jan 2021 05:48:11 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 5EC2E3618B4 for ; Sat, 2 Jan 2021 13:48:09 +0000 (UTC) Received: from nl-srv-smtpout2.hostinger.io (100-96-5-83.trex.outbound.svc.cluster.local [100.96.5.83]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 2275036159E for ; Sat, 2 Jan 2021 13:48:07 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout2.hostinger.io ([UNAVAILABLE]. [145.14.159.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Sat, 02 Jan 2021 13:48:09 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Bitter-Bored: 7d7006542fb4ebaa_1609595288647_901055196 X-MC-Loop-Signature: 1609595288647:857054098 X-MC-Ingress-Time: 1609595288647 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout2.hostinger.io (smtp.hostinger.com) with ESMTPSA id 24BD3333EFB7 for ; Sat, 2 Jan 2021 13:48:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1609595286; bh=hrv9uoUnTLyr53Tp1GsSVJR1X7mSOznBocCIC+GK8Zc=; h=Reply-To:Subject:From:To:References:Date:In-Reply-To; b=qDYuovSoTBGtFVccC36TkE6IoccfwbHToz1qeAJxHVhLaApnQBSIRUilIIdTkhK3j 3+WD5WpQB3PiDAj98b3hT0UJQjSrQcN6NnZBlK8PQtIoizb6n2s58onZN1ZkMUDA/B qzZPRC2Wl56BubKBhrgaZFGBlLd/gTBbUYzbrmSEG9kTZ7xnBYMldXW3o3O4QTP3rP yRGZswrtlU2tCinGt4Jmc5qQBQvVu2Loqwu6WASRG5S1Nd6h3/Tn+Q7MIeHiW0chw2 FVAr+5IJPalAQO3e6LmQr1BY7DZ2kQ9pTEFNzzJcT5bdkN8m0gJF7aSySvo1WRnYX1 Jk3J52q7Zup0g== Reply-To: dcrocker@bbiw.net From: Dave Crocker To: emailcore@ietf.org References: <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> Organization: Brandenburg InternetWorking Message-ID: <0ea03115-8730-1759-58ec-a4fbcd8508e6@dcrocker.net> Date: Sat, 2 Jan 2021 05:48:03 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 13:48:14 -0000 On 1/1/2021 8:24 AM, Dave Crocker wrote: > >      Should the recipient's MUA have access to the /sequence/ of RCPT TO >      addresses used to get to them? If the recipient MUA is to have access to the sequence of RCPT TO addresses, there are two ways to record this: 1) A single Deliver-To: header field, showing the (full) sequence 2) A sequence of Deliver-To: header fields, with each one showing one RCPT TO address. The second would echo the approach taken for Received: header fields, of course. It seems the easier choice. Any site performing the delivery transition of responsibility, from the MHS to the addressee's control, slaps a Deliver-To: header field, with that one address on it. The MUA can construct the sequence by scanning for these header fields, from botton to top of the header. Thoughts? Also, I think I've seen some expression of concern about *privacy* sensitivities, in showing previous Delive-To addresses. I'm not finding myself understanding that well enough to write anything about it. Can we get some discussion of it? d/ ps. There often is confusion about what 'delivery' means. This was a point of very focused discussion, during the development of RFC 5598, with a few folk driving home the rather unusual realization that it does not take place during a communication exchange, but takes place /within/ the MDA: > 4.3.3. Mail Delivery Agent (MDA) > > A transfer of responsibility from the MHS to a Recipient's > environment (mailbox) is called "delivery". In the architecture, as > depicted in Figure 5, delivery takes place within a Mail Delivery > Agent (MDA) and is shown as the (D) transition from the MHS-oriented > MDA component (hMDA) to the Recipient-oriented MDA component (rMDA). -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jan 2 06:37:21 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97923A098C for ; Sat, 2 Jan 2021 06:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=XpE7m8Rr; dkim=pass (2048-bit key) header.d=wizmail.org header.b=HowBK5Mi 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 0GDrXVaIcsGR for ; Sat, 2 Jan 2021 06:37:18 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 662663A0983 for ; Sat, 2 Jan 2021 06:37:17 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Subject:From:References:To:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=xu7czfgpk6CmXd06CRrtEkFj+jA1+lMT7pO84ojki5I=; b=XpE7m8RrWLaQhQ4UDhIhbQJtLB KIEVEXkfbSTvqsgtfoxJc8G3A3KX3hz81w07bYNM7Ejx5CL4pY17eyIKtgCw==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Subject:From:References:To:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=xu7czfgpk6CmXd06CRrtEkFj+jA1+lMT7pO84ojki5I=; b=HowBK5MieK/65fatVde8phFqam EgWjchN6wPr8o+TbS4qWNuAuTIcol+N+B3fEwhgqoBZh1rKDbu8f+xwWWI6fNNoxCmA7rzyOz4EBt P01WpAmEut5zwwKDcq5MeoBZ1tJ9oNWcMoYN1/grzV1i7Tx7LxRGx+Gqim0bRhVgWd2jwlnjppbC6 U5ZjlxtBmDqa3ZP9mZjcNQdorkiTPRrzbql2hcTW5jg/aDNSR/aTvnRcnl9aYaiEXoq5dYgb+pzSB 87LdPv2t163MqghuSKb4IMk/EmZX2TyA6/ogtlaY27x4XGhAFRRJEuqstXUDRaWquygETWhbJIxUx m77+wuxw==; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=46.33.133.68; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [46.33.133.68] (helo=lap.dom.ain) (from_AS 51561) by wizmail.org (Exim 4.94.110) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1kvi1n-008YF6-6T for emailcore@ietf.org (return-path ); Sat, 02 Jan 2021 14:37:11 +0000 To: emailcore@ietf.org References: <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> <0ea03115-8730-1759-58ec-a4fbcd8508e6@dcrocker.net> From: Jeremy Harris Message-ID: Date: Sat, 2 Jan 2021 14:37:09 +0000 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: <0ea03115-8730-1759-58ec-a4fbcd8508e6@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 14:37:21 -0000 On 02/01/2021 13:48, Dave Crocker wrote: > Any site performing the delivery transition of responsibility, from the MHS to the addressee's control, slaps a Deliver-To: header field, with that one address on it. > delivery ... takes place /within/ the MDA I think this implies that the address is site-meaningful and not necessarily externally-meaningful nor qualified. For example, a message received with an envlope RCPT of "root@site.example.com" is locally aliased to "fred", has "Deliver-To: fred" prepended and then added to fred's mailbox. -- Cheers, Jeremy From nobody Sat Jan 2 08:24:55 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1370F3A0C10 for ; Sat, 2 Jan 2021 08:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=NLtiHWOm; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=rEJzUrqf 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 LpNGBEHAXV1h for ; Sat, 2 Jan 2021 08:24:51 -0800 (PST) Received: from mail.winserver.com (winserver.com [76.245.57.69]) (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 AE5F53A0C0F for ; Sat, 2 Jan 2021 08:24:51 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1781; t=1609604683; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=FYDkwFKOWtuE+hiiAxKJRr+DOyFw N+0ljaPJGAm3Bvo=; b=NLtiHWOmEZsUJqewmjzrLyrN5tX7Jt7R0KEDZ5mMeOt4 GcpGllvHeptlHSUOoJRNq14Ygl+hoxzxsdOJ4eMm0YdXWp7dan92o9XlYCsjfbdJ /d/OV1oc7mneWHLekzJ0WaW2jm9AJuqE1Iz0neGDIxRpnreNPMwhOKpQEIQc4VU= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Sat, 02 Jan 2021 11:24:43 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 3044744478.1.1292; Sat, 02 Jan 2021 11:24:43 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1781; t=1609604306; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=FYDkwFK OWtuE+hiiAxKJRr+DOyFwN+0ljaPJGAm3Bvo=; b=rEJzUrqfNzNak51c8ZPf3kb 5EHoxIDtC+ufi1sY/uq+cLLKiF1M9G0WyiyiYH0lG4pruqPKxZ28Zqui45v35Hhv noW0Vxc9I4AMqy38claM3MDYUXfwfqKptpriuO+Hee/gZ8QeQUmY5O6DvOnLQoGl jb60ujnUjHwAWwPlto3E= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Sat, 02 Jan 2021 11:18:26 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2911610486.1.6064; Sat, 02 Jan 2021 11:18:25 -0500 Message-ID: <5FF09E4F.8080302@isdg.net> Date: Sat, 02 Jan 2021 11:24:47 -0500 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: emailcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 16:24:54 -0000 On 12/31/2020 10:55 AM, John R Levine wrote: > RFC5321 says that when a message is delivered the envelope MAIL FROM > address goes into a Return-Path header, but says nothing about the > RCPT TO address. For Return-Path, only for a relay/route, not for the MDA. In our system, the MDA/SMTP Gateway has no need for the Return-Path and thus, it is removed which is carry on code from the UUCP Gateway days of removing the "From " field (note no colon) once final destination is established. > Many MTAs put that in a Delivered-To header and have > done so for a long time. I know that Postfix and qmail do. Yet wcSMTP and others do not. Not a justification. Tracing the target address can be and is done with the initial SMTP 5322.Received trace line. > I think this is sufficiently established "Sufficiently established?" Without getting input from all other SMTP developers? > ... that we can add it to > 5321bis. We could say that the delivery SMTP server SHOULD insert a > Delivered-To line when it inserts a Return-Path line, and SHOULD NOT > remove existing Delivered-To lines. -1 for a SHOULD. Maybe +1 with a small "may" or "could" but lets keep in mind we already have a 5322.Received header that resolves this tracer bit, for example for the OP message: Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for hsantos@isdg.net; Thu, 31 Dec 2020 10:55:39 -0500 A SHOULD brings back a reinforcement consideration to a "To:" field that was relaxed when we went from RFC822 to RFC2822. Also consider some SMTP software MAY add a 5222.To if missing. If the 5322.To field is not required, than neither should 5322.Delivered-To. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Sat Jan 2 10:48:49 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE3E3A0CE0 for ; Sat, 2 Jan 2021 10:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 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, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=KE+Ym4i4; dkim=pass (2048-bit key) header.d=taugh.com header.b=tTfuK5+f 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 BaxFJHVbtB7N for ; Sat, 2 Jan 2021 10:48:46 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 57F383A0CDF for ; Sat, 2 Jan 2021 10:48:46 -0800 (PST) Received: (qmail 31416 invoked from network); 2 Jan 2021 18:48:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7ab6.5ff0c00d.k2101; bh=Qsbs4HTQkhDJL9zo61N9bDCJ75fQH6y8ilO0x7BhFEc=; b=KE+Ym4i46A4GTmfGT/wCNgAxHtVBlggO1G5rGGIPihgK8J5VCVVOKNp1Oaz9lIgBoagW08hkjIxC65FI38XaScmC9+4rACKpDYLecJ/wSP25Vk8J8mIUIneANSgMfmC7Jeb7h7fS+3XBbXOzqktsZ6RhXuo6P2B3EbJ63/flppqGJDLjB0KL+/zUdcvz3+nkOziWmyo1Lehi3eMFJIl1ZAYVv7AanOeOpwZkJImb8ZTtazekER27m0JedztDlVB1vdVeHCLSNUHn4zmC1NVjQniS6rem3uVVwDkqCuz4m7WO4q6rXkvCENXOWgnVDHNqRtmnOeoBdfj8HZjcCQSg8Q== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7ab6.5ff0c00d.k2101; bh=Qsbs4HTQkhDJL9zo61N9bDCJ75fQH6y8ilO0x7BhFEc=; b=tTfuK5+fP0C/GtE0G20vB1PEOi4VuIre7z6Me3un35iT0zHz7HS9X4WCb0FoOBJMJvU3ejebXqxCoASNZ77kGFha5hsvPNQWzsbYWOD1qdY+cI+q+NApl0HrqsP0mNgbTqG+185Gze+lSeMw4f+4RHtPfrunC1P9U6ss+jpNa0L8cPC21E30sjU1cgEqQKncsfIvgN9+yBiDOlXIcwY3oeTUdnIcPSps/1KdQ4Ol+Q81B1Ow+cwXdSofZ8xnkeowtPnOdumXyCz9wWGS8V87+V5AeYxim+3gwF8dZbiWWvJ7G1R8bZlpgViT6SNmRbaslDqMwQaDHhxM+KuZXdClDA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 02 Jan 2021 18:48:45 -0000 Received: by ary.qy (Postfix, from userid 501) id 95F084A14820; Sat, 2 Jan 2021 13:48:42 -0500 (EST) Date: 2 Jan 2021 13:48:42 -0500 Message-Id: <20210102184844.95F084A14820@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <0ea03115-8730-1759-58ec-a4fbcd8508e6@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 18:48:48 -0000 In article <0ea03115-8730-1759-58ec-a4fbcd8508e6@dcrocker.net> you write: >If the recipient MUA is to have access to the sequence of RCPT TO >addresses, there are two ways to record this: > > 1) A single Delivered-To: header field, showing the (full) sequence > > 2) A sequence of Delivered-To: header fields, with each one showing >one RCPT TO address. The latter is existing practice, and I'm pretty sure nobody plans to change, so please write it up that way. R's, John From nobody Sat Jan 2 11:03:42 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB0F3A0CF2 for ; Sat, 2 Jan 2021 11:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=leo.gaspard.io 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 DeNKq2lbFACk for ; Sat, 2 Jan 2021 11:03:39 -0800 (PST) Received: from smtp.gaspard.ninja (grym.ekleog.org [94.23.42.210]) (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 A2C563A0CF0 for ; Sat, 2 Jan 2021 11:03:37 -0800 (PST) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id f5e69265 for ; Sat, 2 Jan 2021 19:03:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=leo.gaspard.io; h= from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=grym-20170528; bh=nS7LydWt27ruSz4i ayxzDbTRSwU=; b=AZTzSfVVYoCf7f7u4jFQPBUz44qnet8mIYMeooFwBj1t9fDu Og8TNeF9P2/WTLMhXEvvF5UhLRGO69DJRUwUnIA3Mg50+9TvMA4b9ojN1uzjRdjf Dk8pnEYWDq4MvKoIiD7ORkUqT2HzCQmEddOCl/wx7JtgaIUiVG6aAIlx+T4= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPS id 76c09a6d (TLSv1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256:NO) for ; Sat, 2 Jan 2021 19:03:32 +0000 (UTC) Received: from localhost (llwynog [local]) by llwynog (OpenSMTPD) with ESMTPA id 6a349dfe for ; Sat, 2 Jan 2021 19:03:32 +0000 (UTC) From: Leo Gaspard To: emailcore@ietf.org Date: Sat, 02 Jan 2021 20:03:32 +0100 Message-ID: <87turzkvp7.fsf@llwynog.ekleog.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Emailcore] SMTP compliance suite? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 19:03:42 -0000 Hello world, With the evolution of mail systems and the RFCs and pre-RFCs that are related to them, I wonder whether there would be interest from other people than me for an =E2=80=9CSMTP compliance suite 2020=E2=80=9D in the X= MPP spirit? The idea would be to take all the RFCs and pre-RFCs that are related to mail systems, classify the MTAs in a few categories (eg. off the top of my head, =E2=80=9Csubmission=E2=80=9D / =E2=80=9Cforwarding=E2=80=9D / =E2= =80=9Cdelivery=E2=80=9D would probably be the three main categories), and explicitly indicate for each category which RFCs and pre-RFCs should be implemented, and which ones should not. As a less directly compliance-suite-y extension, maybe it could include best practices on how to implement said RFCs (eg. =E2=80=9CA submitting mail server that does not expect to send emails to mailing lists SHOULD have a p=3Dreject DMARC policy=E2=80=9D =E2=80=94 though I'm not totally sure we= 'd already be ready for that, but let's not discuss this particular example in this thread) What do you think about this idea? Cheers, Leo From nobody Sat Jan 2 13:10:02 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52EEA3A0E0D for ; Sat, 2 Jan 2021 13:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 qkDEVeHZc67j for ; Sat, 2 Jan 2021 13:09:58 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82CF3A0E0B for ; Sat, 2 Jan 2021 13:09:58 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kvo9r-0003tM-9O; Sat, 02 Jan 2021 16:09:55 -0500 Date: Sat, 02 Jan 2021 16:09:49 -0500 From: John C Klensin To: Jeremy Harris cc: emailcore@ietf.org Message-ID: In-Reply-To: References: <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> <0ea03115-8730-1759-58ec-a4fbcd8508e6@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 21:10:00 -0000 --On Saturday, January 2, 2021 14:37 +0000 Jeremy Harris wrote: > On 02/01/2021 13:48, Dave Crocker wrote: >> Any site performing the delivery transition of >> responsibility, from the MHS to the addressee's control, >> slaps a Deliver-To: header field, with >> that=C2=A0one=C2=A0address=C2=A0on=C2=A0it. >=20 >> delivery ... takes place /within/ the MDA >=20 > I think this implies that the address is site-meaningful and > not > necessarily externally-meaningful nor qualified. For example, > a message received with an envlope RCPT of > "root@site.example.com" > is locally aliased to "fred", has "Deliver-To: fred" prepended > and then added to fred's mailbox. Thinking about the above comment and several others in this thread, if "Envelope-to" actually has the semantics of "relevant RCPT to associated with the current delivery" (Jeremy, I think that is the case in exim, but please confirm), then it and "Deliver-to" have different semantics and are processed at different points in the delivery process -- the former by the final MTA and the latter by the MDA. Should we be defining both, making it clear that they are different, and then making whatever recommendations seem appropriate about which one (or both) should be provided? john From nobody Sat Jan 2 13:56:56 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180AB3A0E6B for ; Sat, 2 Jan 2021 13:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=o8XdNNAG; dkim=pass (2048-bit key) header.d=wizmail.org header.b=k1n4wcHi 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 D476xmCYhkeD for ; Sat, 2 Jan 2021 13:56:53 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 764D53A0E6A for ; Sat, 2 Jan 2021 13:56:52 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Subject:From:References:To:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=Iiw0VLDVGMH3AvTnkv4O7/DDRzIjgj9Kq968PDeBQJM=; b=o8XdNNAGnT/ZDz/7mKqcgDar6d LMHnJbRJqPt30OtFfnGMe59P6dmySRhUHJgek8XPEAezlh31r5y//ETblmBg==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Subject:From:References:To:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=Iiw0VLDVGMH3AvTnkv4O7/DDRzIjgj9Kq968PDeBQJM=; b=k1n4wcHi697WZy+TzLUzx1fVuR ytbof86QfsEaXspgaNS4PYWulVVlL+lt9zP3Ee5ksw0tweN5glBjYLQrh14ZzQAec7UAHmCqyZAoX OpuEfsjHBNgKA0c7SCv1VBJNuVCjynEnEMmolYDqxpFGHKxarzIVXdo8m8irBotd6m90eu3Ok63Gn X6mGEWi8O7ldB36S37G6VYYe7yXxN/H+gUkZus1G977QvT9Fw4HizXXjuLqmSprhVnc9XnInlnwqj bMBbVfeXTM4wr4dA7VtJzX34Frk4pxQq0499nMg9gCQdckQZnMmywEv46fjPC4wUHXRfRYK1x30p0 SaBySy/g==; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.94.110) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1kvotG-008gFA-Fs for emailcore@ietf.org (return-path ); Sat, 02 Jan 2021 21:56:50 +0000 To: emailcore@ietf.org References: <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> <0ea03115-8730-1759-58ec-a4fbcd8508e6@dcrocker.net> From: Jeremy Harris Message-ID: Date: Sat, 2 Jan 2021 21:56:49 +0000 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 21:56:55 -0000 On 02/01/2021 21:09, John C Klensin wrote: > if "Envelope-to" actually has the semantics of "relevant > RCPT to associated with the current delivery" (Jeremy, I think > that is the case in exim, but please confirm) Yes. Though it can be a list of such RCPTs, given aliasing that results in a single message delivered from a single SMTP session (after deduplication during delivery). > Should we be defining both, making it clear that they are > different, and then making whatever recommendations seem > appropriate about which one (or both) should be provided? I agree that Envelope-To: and Delivered-To: are different. I'm not convinced that this document is the right place for either. I guess there's a benefit in writing down the definitions somewhere; the cost is "only" cruft that obscures the minimum requirements for implementing an MTA. -- Cheers, Jeremy From nobody Sat Jan 2 14:15:35 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F463A0E93 for ; Sat, 2 Jan 2021 14:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 SUpiAKcXRf2x for ; Sat, 2 Jan 2021 14:15:33 -0800 (PST) Received: from bird.elm.relay.mailchannels.net (bird.elm.relay.mailchannels.net [23.83.212.17]) (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 C9F343A0E92 for ; Sat, 2 Jan 2021 14:15:32 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A38B7541087; Sat, 2 Jan 2021 22:15:31 +0000 (UTC) Received: from nl-srv-smtpout2.hostinger.io (100-98-64-116.trex.outbound.svc.cluster.local [100.98.64.116]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id BCBC45410BF; Sat, 2 Jan 2021 22:15:30 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout2.hostinger.io ([UNAVAILABLE]. [145.14.159.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Sat, 02 Jan 2021 22:15:31 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Sponge-Bubble: 3a0aa36e739b01ca_1609625731450_3125700256 X-MC-Loop-Signature: 1609625731449:685358359 X-MC-Ingress-Time: 1609625731449 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout2.hostinger.io (smtp.hostinger.com) with ESMTPSA id 8F8FF32220A8; Sat, 2 Jan 2021 22:15:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1609625729; bh=Bfn9KMje96m+XHzXQ9Q85V+gri5p/RY2BcfT3m7JR50=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=QStbsXm7An5h4AfvNH6hqYOwj9nymphley32Be/n+6HNhnAu3gvMdsC+WrjZYcIZF HfmqJ5IFk7bYPxKPm+USmJDM2cGYQkspep117HeuOxlXQPrJ02dWYqsA924YgiXfKr W5p0HWatAXfkBSLA4NqfR2N6NgO9l/xgbNnYlRQoW0ttPm6UqJMb7ZDc5+2UtAEthh fsJBXCEj/oNyhca8FLH4As5UfyL5LbhetSKwlw7ZEGtDyn2KLSeXun18mZFCxafI1b Ku3ldWQbVDDIPFt3yUmdPy/YZtRt41v+DZLVjmPB8pXIcb3jA7qnXXpfIbSE9LZI5z jN98NsdTM3OWg== Reply-To: dcrocker@bbiw.net To: Jeremy Harris , emailcore@ietf.org References: <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> <0ea03115-8730-1759-58ec-a4fbcd8508e6@dcrocker.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <01cc225f-ca8b-4462-7292-5f3a9af0b925@dcrocker.net> Date: Sat, 2 Jan 2021 14:15:26 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 22:15:35 -0000 On 1/2/2021 6:37 AM, Jeremy Harris wrote: > On 02/01/2021 13:48, Dave Crocker wrote: >> Any site performing the delivery transition of responsibility, from >> the MHS to the addressee's control, slaps a Deliver-To: header field, >> with that one address on it. > >> delivery ... takes place /within/ the MDA > > I think this implies that the address is site-meaningful and not > necessarily externally-meaningful nor qualified.  For example, > a message received with an envlope RCPT of "root@site.example.com" > is locally aliased to "fred", has "Deliver-To: fred" prepended > and then added to fred's mailbox. It's possible that one or another address -- notably the last one -- might only be site-meaningful, I suppose. I'd be inclined to have the spec mitigate against that, though, by requiring it list the address in a way that is globally useful. That is, after all, what the right-hand-side domain name is for. (Note that the left-hand side is only ever site-meaningful, for Internet mail. There is never a global interpretation of the LHS.) Also note that 'delivery' is a transition out of the handling system. Just prior to that moment, the address being used is a classic Internet mail address, which is globally meaningful. And it is to that address that the mail is being delivered. Discussions have tended to imply or assert that delivery occurs at various other places or that things that occurr afterwards are, nonetheless, inside the MHS. If a message reaches the RCPT TO address, anything that happens afterwards, such as being sent on to a new address, happens after delivery and involves a new submission. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jan 2 14:27:05 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902403A0EC9 for ; Sat, 2 Jan 2021 14:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 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, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=t3b7h5hn; dkim=pass (2048-bit key) header.d=taugh.com header.b=l+LpJWG7 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 qgPIW4TxDJae for ; Sat, 2 Jan 2021 14:27:02 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 CE2CB3A0EC4 for ; Sat, 2 Jan 2021 14:27:01 -0800 (PST) Received: (qmail 10189 invoked from network); 2 Jan 2021 22:27:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=27cb.5ff0f334.k2101; bh=PuozH0zt6xJurlRdB2hMhunzEnUiP8mOkeLn1Uoqzkg=; b=t3b7h5hnK0rODwY5uGlRIBIDWP3F67uaH4xvxtrmewHbgy+2VnwpLL/PZ3/7ZOKeMK8F49WY7ZRdk3iCgD4Js/pbirEZD5v+Ss8tq1H/CNldBZ+IZEMOVPD91XiqrciiJYMeX/nQ+nOAQXCEfhnv8MXWtqn+mvloRRDJMaDtt/oo+SC5DFs0/gvJOKizEYX7FJ4nHvICgPXZur1+WoY+610cZYY/QrXlp9Sp9lTUevzJzKMT3KOdN4DNjFIj6ICrn2C4WxKAM37BwHwpxpQhfFHprLPtjCDyX8Bps0qXwUs7QjZ/uPY5lufvlLTEx1QVrQZ2mTVFtx/X2Nj8hXpYaA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=27cb.5ff0f334.k2101; bh=PuozH0zt6xJurlRdB2hMhunzEnUiP8mOkeLn1Uoqzkg=; b=l+LpJWG7hRuk4k7IuTBelfCETr3lkgudEzMn/bi39J/WDNOe/uqwkMI3g9CJIh5Xygj7qs65jnqsp0KfwJmskehX1LWbXehTCtljyZPOBnz7pysx++HcA96BpE24CSUa394nVfmct5PRFhOUn9Y8IrEb0xflLQT640wLy8AZz5BxFqj2cYmQ7RAb1iw5MA76SXaJGkLIQjmKhb/JzrI687nPzULg7sdCCCkhw2gg8WE4wtgM8wjxgz0kyfeSlOfyvYD442JRG7XqVMrCmIzzyibhq60X86g8CC+amqSYTuW7K16NAsCm8wuvfaStX1ntQYnpCnNBkZhCjVrY5Pz4fg== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 02 Jan 2021 22:27:00 -0000 Received: by ary.qy (Postfix, from userid 501) id E290E4A396E1; Sat, 2 Jan 2021 17:26:58 -0500 (EST) Date: 2 Jan 2021 17:26:58 -0500 Message-Id: <20210102222659.E290E4A396E1@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: jgh@wizmail.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 22:27:04 -0000 In article you write: >> Should we be defining both, making it clear that they are >> different, and then making whatever recommendations seem >> appropriate about which one (or both) should be provided? > >I agree that Envelope-To: and Delivered-To: are different. Agreed. What's the difference between Envelope-To and the FOR clause in a Received header? >I'm not convinced that this document is the right place >for either. I guess there's a benefit in writing down the >definitions somewhere; the cost is "only" cruft that >obscures the minimum requirements for implementing an MTA. I think we have general agreement that if this goes anywhere it's a different draft, not 5321bis. R's, John From nobody Sat Jan 2 14:40:20 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F893A0EF1 for ; Sat, 2 Jan 2021 14:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 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, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=tOQUxLN9; dkim=pass (2048-bit key) header.d=taugh.com header.b=vmjldbls 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 4iLsM8CajV4d for ; Sat, 2 Jan 2021 14:40:16 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 51F403A0EDA for ; Sat, 2 Jan 2021 14:40:16 -0800 (PST) Received: (qmail 13810 invoked from network); 2 Jan 2021 22:40:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=35f0.5ff0f64e.k2101; bh=6bDPSkfEFMCCyWZ2oGySzxEtzgSEodemI+UW7h1bnXc=; b=tOQUxLN9N9Xu6DegmxSZCm5yXp+Q8eoj4ZeXKIGGIt79sH19CA71ZwCf32RrlNGrbWvmNmcMttfRY59fsgS32AauwkxT+/Dspct5dH/pAADpKeK2eNmZRLBmcVT+uRBuuKfFiH/yBZi1i8rfy9T4uPAJnRhH9ZhBjqhnUuACWexBMPC4+OU5VGCn1N3kpt8qz2iwFCD7N3Hld2Ft7s1DNeswQEhm63/v8d3N9jM94a2+K3VSzDzFScfXJJdl0oBYdE9dcO/R1wmJ8rxbmAqp2J/3R6IRW3JqlZ21Oc1lntqxSRGo909JKpVlb7jYV4TQDeikuwKAw5fxAeYu58YcLA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=35f0.5ff0f64e.k2101; bh=6bDPSkfEFMCCyWZ2oGySzxEtzgSEodemI+UW7h1bnXc=; b=vmjldblsc8JFGKYt8IYEJVH7pAdMu1wGyZrBDGns4xtFq5D6WIMwu3vrPPpGWadXaZ7K4OxwSmE6KheCoyImc7SVJzVEcXoSp2j3Rdopl4zMzY7+k+4k7iQyKW50X5Q5Ef+qu9U/LBotsKSZ3RFYlKU3CngLIBqhqHwD0ejP4um2xkXE606BRY+ofiQiWgGZds79lVGHL+nKG3Kgp2M80uHCcwVX8TaaAQrwTfTAkVc40OZh2EnrI3Hd5M7Sljqog2xbv/B4AZBwUXhOOkc6HJ/C6p4P70XEEchYtwK2v2SnSoj2FadhWlKK3rgytVqkSkbjFsbPZp8fVIxxKxEzoA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 02 Jan 2021 22:40:13 -0000 Received: by ary.qy (Postfix, from userid 501) id 5D1E64A3E709; Sat, 2 Jan 2021 17:40:12 -0500 (EST) Date: 2 Jan 2021 17:40:12 -0500 Message-Id: <20210102224013.5D1E64A3E709@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: ietf@leo.gaspard.io In-Reply-To: <87turzkvp7.fsf@llwynog.ekleog.org> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] SMTP compliance suite? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 22:40:19 -0000 In article <87turzkvp7.fsf@llwynog.ekleog.org> you write: >With the evolution of mail systems and the RFCs and pre-RFCs that are >related to them, I wonder whether there would be interest from other >people than me for an “SMTP compliance suite 2020” in the XMPP spirit? I wrote some scripts to test EAI compliance in MSA, MTA, and MDA (POP/IMAP) software for the UASG. You can find it here: https://github.com/jrlevine/eaitesttools The MSA and MTA tests sort of by default check the SMTP compliance of whatever I'm testing. Not surprisingly, SMTP compliance was excellent in MSA and MTA software not written in Redmond WA, and there the errors were largely cosmetic, e.g., minor syntax errors in generated Received headers. I would be pretty surprised if any MSA or MTA you ever heard of failed any test that anyone cared about. Is there anything in particular you were hoping to find out? R's, John From nobody Sat Jan 2 14:41:56 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB6A3A0EFC for ; Sat, 2 Jan 2021 14:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=aZWTFOvI; dkim=pass (2048-bit key) header.d=wizmail.org header.b=ZHgG3AFf 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 q7t23PZm5H-s for ; Sat, 2 Jan 2021 14:41:53 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 EBD3F3A0EFA for ; Sat, 2 Jan 2021 14:41:52 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Subject:From:References:To:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=HxKYRyGh44ERAgY7oEq/ZgjtcI3a7OkvnnE7JAQqnZ8=; b=aZWTFOvI409oVLJ8aj0DhNvDPe XUPD5vYHAN2C4svlH6Ye5Ism4f5ay18RwQ9UXTKi5X7GPqaKYKF85+slBzCg==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Subject:From:References:To:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=HxKYRyGh44ERAgY7oEq/ZgjtcI3a7OkvnnE7JAQqnZ8=; b=ZHgG3AFfXUfnab18Cm9CypZMmb CtFxM0IlCHQ459X5Df8ZQs67vt6kowMcirDQmjlC6orcT+W2SBxUgxGupuKINid96Zzpl4KsmO5pS IQ1eW7MchnleuNBr67juY+hb98TjFCqqJ8AA17hW/vOckE/InJpGWBBQgLXW+ai+l6Ov54JaWPCHo EPyihjVBzHer9VVE2wZaCwefZlaGENpnLLB+BPEVPLjevZNHf9m15CJtmRE+wUV1cs5tBkfdFsRoZ 4shIrF7IfOtByka5C2CY16y4tgCSqEmIKJA5Gyvnc8HfLmsDNb45EMbvOP7FtZduM/LE1bw3b4+3P ZqyPPFPw==; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.94.110) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1kvpap-008h8F-7z for emailcore@ietf.org (return-path ); Sat, 02 Jan 2021 22:41:51 +0000 To: emailcore@ietf.org References: <20210102222659.E290E4A396E1@ary.qy> From: Jeremy Harris Message-ID: <11d3fbf3-b5e9-b876-88d0-6e60465e070b@wizmail.org> Date: Sat, 2 Jan 2021 22:41:50 +0000 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: <20210102222659.E290E4A396E1@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 22:41:55 -0000 On 02/01/2021 22:26, John Levine wrote: > In article you write: >>> Should we be defining both, making it clear that they are >>> different, and then making whatever recommendations seem >>> appropriate about which one (or both) should be provided? >> >> I agree that Envelope-To: and Delivered-To: are different. > > Agreed. What's the difference between Envelope-To and the > FOR clause in a Received header? Exim ducks, and only includes a "for" clause in the Received: for single-RCPT messages. On the other hand, a message which is (locally) aliased to more than one destination name, which are then further aliased to a single final name - will (assuming env-to was configured) get an Envelope-To: with multiple copies of the RCPT. -- Cheers, Jeremy From nobody Sat Jan 2 16:37:58 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6516B3A106D for ; Sat, 2 Jan 2021 16:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GhznSTEit4GN for ; Sat, 2 Jan 2021 16:37:56 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41FC83A106A for ; Sat, 2 Jan 2021 16:37:56 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kvrP8-0004jd-JA; Sat, 02 Jan 2021 19:37:54 -0500 Date: Sat, 02 Jan 2021 19:37:48 -0500 From: John C Klensin To: Jeremy Harris , emailcore@ietf.org Message-ID: In-Reply-To: References: <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> <0ea03115-8730-1759-58ec-a4fbcd8508e6@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2021 00:37:57 -0000 --On Saturday, January 2, 2021 21:56 +0000 Jeremy Harris wrote: >> Should we be defining both, making it clear that they are >> different, and then making whatever recommendations seem >> appropriate about which one (or both) should be provided? > > I agree that Envelope-To: and Delivered-To: are different. > > I'm not convinced that this document is the right place > for either. I guess there's a benefit in writing down the > definitions somewhere; the cost is "only" cruft that > obscures the minimum requirements for implementing an MTA. My understand was that we had gotten to "separate document", or at least "not in 5321bis" some day ago. I hope that is the case and that the perceived agreement holds. best, john From nobody Sat Jan 2 16:47:42 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4FD3A109C for ; Sat, 2 Jan 2021 16:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 gYg_6Mz-ZHCc for ; Sat, 2 Jan 2021 16:47:39 -0800 (PST) Received: from donkey.elm.relay.mailchannels.net (donkey.elm.relay.mailchannels.net [23.83.212.49]) (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 5723F3A109B for ; Sat, 2 Jan 2021 16:47:39 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 723C93421CC; Sun, 3 Jan 2021 00:47:38 +0000 (UTC) Received: from nl-srv-smtpout2.hostinger.io (100-96-9-178.trex.outbound.svc.cluster.local [100.96.9.178]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 344EF3421C0; Sun, 3 Jan 2021 00:47:37 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout2.hostinger.io ([UNAVAILABLE]. [145.14.159.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Sun, 03 Jan 2021 00:47:38 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Robust-Harmony: 2518764b6babc6bb_1609634857886_951089898 X-MC-Loop-Signature: 1609634857886:233679948 X-MC-Ingress-Time: 1609634857885 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout2.hostinger.io (smtp.hostinger.com) with ESMTPSA id 25808310E4E2; Sun, 3 Jan 2021 00:47:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1609634855; bh=Ce7+/bfSgLjSWcRHJcfyvYRe5q8Oq1ML8E+aonkeI24=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=UKuT/WXMc7mktBMB1jHfiVLoaTm+5x58K25SMf4ktjpKxokWZJhVh0SGIRkRzdeUn Ud9+oz4Q+ZMYPheJvPrzgIYM/6w6CJbII6aQ8/AfWYwBNxOI7C/oBGePILLldsKhJi B8mw2mZlxBSxAi+F97yy0kLGnvnI9ZhAP6qSmP1ndXA8eVahDhV7M0rd06jlpogacg PdDfQl88C25HTIz+ug8pdg2WY/9KekEykWJDX31iAd8dMnenzU1ZkaoEwgfEiagcsS iDwWc66XBFp1guAx77HcErbOWyU9ecWm0kjvY85TX26pmegWs1BmwuptKGBeh1K3Gz ht6a9uWtIoZgQ== Reply-To: dcrocker@bbiw.net To: Leo Gaspard , emailcore@ietf.org References: <87turzkvp7.fsf@llwynog.ekleog.org> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <95d12af3-7406-1399-8d26-47d8ed00bbda@dcrocker.net> Date: Sat, 2 Jan 2021 16:47:32 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <87turzkvp7.fsf@llwynog.ekleog.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] SMTP compliance suite? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2021 00:47:41 -0000 On 1/2/2021 11:03 AM, Leo Gaspard wrote: > The idea would be to take all the RFCs and pre-RFCs that are related to > mail systems, classify the MTAs in a few categories (eg. off the top of > my head, “submission” / “forwarding” / “delivery” would probably be the > three main categories), and explicitly indicate for each category which > RFCs and pre-RFCs should be implemented, and which ones should not. Do you mean something in a style like this: https://bbiw.net/clusters/#suitemail d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jan 2 19:57:02 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA7D3A13AC for ; Sat, 2 Jan 2021 19:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com 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 nw38UxxiMV4H for ; Sat, 2 Jan 2021 19:56:58 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 60FA03A13AB for ; Sat, 2 Jan 2021 19:56:57 -0800 (PST) Received: (qmail 38268 invoked from network); 3 Jan 2021 03:56:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=9572.5ff14088.k2101; i=johnl-iecc.com@submit.iecc.com; bh=FCTmJmXzBdv726yC1Kyxx7sT8ArhdkLAI8aPcUqbjQ0=; b=E6gUC3maWlo9Va4FRh6kcB9+DTDpX++2YfxG4xkdgN/k14ImDDubwnYN/L3Tdlclzad/yhcR26wXEbKRpDUmcIWxiahA1lNJUj+p37Hri0CB55I+9vfxGyQ5X0/Mm08jd2I9jFjWUBpUEkDNcwdbq6F+5QtrI5i1U4iSgJ8jq7TYXH7ucsWZ9renHTqrULaxWWY+f7MRmFxy2jYw5hwWiWfQeNzpNZVFKZ3nBf9YOtCVYaDIzcH+37QmhIAjzcLYQe/1Pg330lstZf1y7Q7cQAkMX33CoC6fY4vWa2NBSqfDgf8Prxa4wXKFq9LjdqSa9ph6BqWvxh8ksk/17XvhJg== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 03 Jan 2021 03:56:56 -0000 Date: 2 Jan 2021 22:56:55 -0500 Message-ID: <677aa5c8-9016-c6e8-2726-b6bd526afd3@iecc.com> From: "John R. Levine" To: "Jeremy Harris" , emailcore@ietf.org In-Reply-To: <11d3fbf3-b5e9-b876-88d0-6e60465e070b@wizmail.org> References: <20210102222659.E290E4A396E1@ary.qy> <11d3fbf3-b5e9-b876-88d0-6e60465e070b@wizmail.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2021 03:57:00 -0000 > Exim ducks, and only includes a "for" clause in the Received: > for single-RCPT messages. > > On the other hand, a message which is (locally) aliased to > more than one destination name, which are then further aliased > to a single final name - will (assuming env-to was configured) > get an Envelope-To: with multiple copies of the RCPT. I'm confused. Does it add an env-to each time a message gets aliased to a new address? Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Jan 2 19:59:32 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBB93A13B2 for ; Sat, 2 Jan 2021 19:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 V-6cLOxvIleQ for ; Sat, 2 Jan 2021 19:59:29 -0800 (PST) Received: from aye.elm.relay.mailchannels.net (aye.elm.relay.mailchannels.net [23.83.212.6]) (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 621263A13B1 for ; Sat, 2 Jan 2021 19:59:29 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 381BC3619E4; Sun, 3 Jan 2021 03:59:28 +0000 (UTC) Received: from nl-srv-smtpout3.hostinger.io (100-96-8-104.trex.outbound.svc.cluster.local [100.96.8.104]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id D1965361DCA; Sun, 3 Jan 2021 03:59:26 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout3.hostinger.io ([UNAVAILABLE]. [145.14.159.243]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Sun, 03 Jan 2021 03:59:28 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Skirt-Bitter: 190241845e2d8173_1609646367915_2900676446 X-MC-Loop-Signature: 1609646367915:3903336109 X-MC-Ingress-Time: 1609646367915 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout3.hostinger.io (smtp.hostinger.com) with ESMTPSA id 91A1E31C2C49; Sun, 3 Jan 2021 03:59:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1609646365; bh=WZpfwamHP+Skdj+YR9d5DoEUBg5YKaxPjnj8Va6UMj4=; h=Reply-To:Subject:From:To:References:Date:In-Reply-To; b=bu5wqXF2QbI1Lm3q3XHVD8ymgsgCluMn4n2sZ3N6jtuTPE7rclrmQg6GgMc/2dJv+ iy8sBoOWXmuftZULf8BkuK7JR0RVItMpobXZK+qd97WPLcOxlUZsx05OMkNB4CxBEx WhCN3Wq7Hb6W4oS4VL2+Zi0gHhcz4JF/XaZLz9r7WRGM5bwyb9+mKsFlrca8QvWm8f Cw7Ce/bSDAEhQoZtvHW4lgxjWXKPvNZ5I2r1lpyd2rZuwDZx5C1OaDsuShNmdXFZhK tl++TKQLlLpKqhnIc1fIvPvIDaNJHELsOy7SY7Qmd9hkETCCeJkZcx6ycA1aI4vOay Is2yh1lz59TSw== Reply-To: dcrocker@bbiw.net From: Dave Crocker To: Leo Gaspard , emailcore@ietf.org References: <87turzkvp7.fsf@llwynog.ekleog.org> <95d12af3-7406-1399-8d26-47d8ed00bbda@dcrocker.net> Organization: Brandenburg InternetWorking Message-ID: Date: Sat, 2 Jan 2021 19:59:21 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <95d12af3-7406-1399-8d26-47d8ed00bbda@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] SMTP compliance suite? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2021 03:59:31 -0000 On 1/2/2021 4:47 PM, Dave Crocker wrote: > classify the MTAs in a few categories (eg. off the top of > my head, “submission” / “forwarding” / “delivery” a further review of the above makes me wonder whether just reading RFC 5598 would suffice? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jan 3 01:47:07 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201AB3A0C8B for ; Sun, 3 Jan 2021 01:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=YFJW2fY1; dkim=pass (2048-bit key) header.d=wizmail.org header.b=d8gaNWHt 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 jcjYIjmF194e for ; Sun, 3 Jan 2021 01:47:02 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 AF2783A0C8A for ; Sun, 3 Jan 2021 01:47:01 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:References:To:Subject:From:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=bWSzsusIKSWKSKyNaucLAg8SXmABj5MRF37L+m1epRQ=; b=YFJW2fY1bg8e3e74THm/WxinaG +y0JRaiu8Kw2PpMK/Dg8sR+CfsZ4bODvgtHHnl8Ijj3fv9vAj7r+m8zCpYAA==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:References:To:Subject:From:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=bWSzsusIKSWKSKyNaucLAg8SXmABj5MRF37L+m1epRQ=; b=d8gaNWHt0+5ddS8SPCXpFg0/zK T7Yf6ECpyQ3Nx5ZVOdtLRw+OU13SRDPaN32/miLIL+Ah6BLr4V6aAv6oYb7kr8XazgzNX/G78Lh3K xltzdNSg1+e/oSacyZqINSuGP+YXQKfCJ7dPDiY0JIZQcvfZM0NnkJutS5sA4TK6cMTAYFs9Lecn3 vxY2ESlQclos9tCAg5RS6aUtYirQOp438dR8odpA5TxAQ91T4wwbXoqdErDLH0faUzpwGN1H9dPz2 hjQddPthFvv3cY+8GFATaC9dHLiIL9HfU0+JX9BqlrBxGUzatoHqRot2vT2Sc57oHMcUAtNSu6Oyj rtMUYFAQ==; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=46.33.133.68; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [46.33.133.68] (helo=lap.dom.ain) (from_AS 51561) by wizmail.org (Exim 4.94.110) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1kvzyU-008uJr-EJ for emailcore@ietf.org (return-path ); Sun, 03 Jan 2021 09:46:58 +0000 From: Jeremy Harris To: emailcore@ietf.org References: <20210102222659.E290E4A396E1@ary.qy> <11d3fbf3-b5e9-b876-88d0-6e60465e070b@wizmail.org> <677aa5c8-9016-c6e8-2726-b6bd526afd3@iecc.com> Message-ID: Date: Sun, 3 Jan 2021 09:46:57 +0000 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: <677aa5c8-9016-c6e8-2726-b6bd526afd3@iecc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2021 09:47:05 -0000 On 03/01/2021 03:56, John R. Levine wrote: >> On the other hand, a message which is (locally) aliased to >> more than one destination name, which are then further aliased >> to a single final name - will (assuming env-to was configured) >> get an Envelope-To: with multiple copies of the RCPT. > > I'm confused.  Does it add an env-to each time a message gets aliased to a new address? No, it's a one-time job adding one header but with multiple addresses, being the sources for the multiple aliasing paths that produced the message being delivered. -- Cheers, Jeremy From nobody Sun Jan 3 03:45:45 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A8A3A0D8B for ; Sun, 3 Jan 2021 03:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=leo.gaspard.io 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 ZkGokALqEQV3 for ; Sun, 3 Jan 2021 03:45:41 -0800 (PST) Received: from smtp.gaspard.ninja (grym.ekleog.org [94.23.42.210]) (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 397583A0D89 for ; Sun, 3 Jan 2021 03:45:40 -0800 (PST) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id 07ef68ac; Sun, 3 Jan 2021 11:45:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=leo.gaspard.io; h= from:to:subject:in-reply-to:references:date:message-id :mime-version:content-type:content-transfer-encoding; s= grym-20170528; bh=Pn3UwhJSwnCm1VSLbtTqt1alk2Q=; b=xRmD0HzokFIoir oAS9/8TqGyAIrjNO2jt7WsYIp4JAsQE5WzjVh427wBkFJ6/5GyAunaFJJpe1QGYb 2XAX/GP2zCTDQOaZswWQrc+iEAhn7c386Qh08/Qn9blP6Uya4gbQRBEKIaYHsqyL p2c/hykhrlVYhcX4Nzr1TKuu0u504= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPS id 7f00645f (TLSv1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256:NO); Sun, 3 Jan 2021 11:45:34 +0000 (UTC) Received: from localhost (llwynog [local]) by llwynog (OpenSMTPD) with ESMTPA id 45ffe023; Sun, 3 Jan 2021 11:45:32 +0000 (UTC) From: Leo Gaspard To: dcrocker@bbiw.net, emailcore@ietf.org In-Reply-To: References: <87turzkvp7.fsf@llwynog.ekleog.org> <95d12af3-7406-1399-8d26-47d8ed00bbda@dcrocker.net> Date: Sun, 03 Jan 2021 12:45:32 +0100 Message-ID: <87lfdakzvn.fsf@llwynog.ekleog.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] SMTP compliance suite? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2021 11:45:44 -0000 Dave Crocker writes: > Do you mean something in a style like this: > > https://bbiw.net/clusters/#suitemail > > [and] > > a further review of the above makes me wonder whether just reading RFC=20 > 5598 would suffice? Something like the first link sounds indeed like exactly what I'm hoping could get consensus for a 202x edition, thank you, I didn't know of this website and it looks awesome! (Unfortunately the link is missing to mention eg. DMARC, so it is not already what I'm looking for, and would need at least updating.) Also, it would maybe be useful to have such a compliance suite also include documents that were well-known but should not be implemented (currently thinking of SRS, not mentioned here, and for which I'm personally still unclear as to whether forwarders SHOULD, SHOULD NOT or MAY implement it as different destinations appear to have different recommendations) =E2=80=94 this would be going beyond the scope of XMPP compliance suites, but on the other hand SMTP has a long history of tried experiments and it's not always clear which ones were ever formally retired or not. What I'm thinking is, if we could get such an SMTP compliance suite be published as an RFC, it might help formally retiring retired experiments, as well as clarifying which ones are still running. And maybe even add in best practices for how people nowadays are expected to implement the quoted RFCs (eg. I'd expect best practices for DMARC policy to start like =E2=80=9Ceither have p=3Daccept or pct=3D0 if you want= to send mail to mailing lists=E2=80=9D nowadays, and to with time eventually crank = up to =E2=80=9Cp=3Dreject pct=3D100=E2=80=9D =E2=80=94 but this requires the abil= ity to make evolving-with-time recommendation) Now=E2=80=A6 I am not sure RFCs are the proper medium to define such a compliance suite? But on the other hand, I don't see who else would have legitimate authority to say =E2=80=9Cthere is consensus and this is the set= of protocols that should be implemented nowadays to make both the mail ecosystem and your own mail setup work best=E2=80=9D From nobody Sun Jan 3 09:23:21 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790513A1052 for ; Sun, 3 Jan 2021 09:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 0U_Uk2mGZdyK for ; Sun, 3 Jan 2021 09:23:15 -0800 (PST) Received: from denver.dinauz.org (denver.dinauz.org [37.59.56.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678FB3A1050 for ; Sun, 3 Jan 2021 09:23:14 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id 2C1FD60588 for ; Sun, 3 Jan 2021 18:23:11 +0100 (CET) Received: from denver.dinauz.org ([127.0.0.1]) by localhost (denver.dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mj5HT3zXvejV for ; Sun, 3 Jan 2021 18:23:11 +0100 (CET) Received: from macbook-pro-de-julien.home (lfbn-idf3-1-527-171.w86-252.abo.wanadoo.fr [86.252.110.171]) by denver.dinauz.org (Postfix) with ESMTPSA id 07D4860583 for ; Sun, 3 Jan 2021 18:23:11 +0100 (CET) To: emailcore@ietf.org References: <59447e97-5446-401b-8b40-e0d09118acb2@www.fastmail.com> From: =?UTF-8?Q?Julien_=c3=89LIE?= Message-ID: <6580dd9f-b566-5c30-e6ed-2ea9121a5ae5@trigofacile.com> Date: Sun, 3 Jan 2021 18:23:10 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <59447e97-5446-401b-8b40-e0d09118acb2@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #28: Erratum 1851: Location of text about TCP connection has closure/reset X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2021 17:23:18 -0000 Hi Alexey, >> o After detecting the need to shut down the SMTP service and >> returning a 421 reply code. This reply code can be issued after >> the server receives any command or, if necessary, asynchronously >> from command receipt (on the assumption that the client will >> receive it after the next command is issued). >> >> I'm wondering whether the part in parenthesis really occurs in practice, >> notably when the closure is asynchronous from command receipt. Maybe it >> should be reworded this way: "on the assumption that the client will >> receive it after the next command is issued or read it before closing >> the connection at its side"? > > I think we should open a separate ticket on this. Ticket #46 just opened, thanks. -- Julien ÉLIE « Hâte-toi de bien vivre et songe que chaque jour est à lui seul une vie. » (Sénèque) From nobody Sun Jan 3 09:35:57 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2549A3A0D12 for ; Sun, 3 Jan 2021 09:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 eWXAYQtKvdHY for ; Sun, 3 Jan 2021 09:35:53 -0800 (PST) Received: from denver.dinauz.org (denver.dinauz.org [37.59.56.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1803E3A0C45 for ; Sun, 3 Jan 2021 09:35:47 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id 6280A60588 for ; Sun, 3 Jan 2021 18:35:46 +0100 (CET) Received: from denver.dinauz.org ([127.0.0.1]) by localhost (denver.dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DK5_rfIWdn92 for ; Sun, 3 Jan 2021 18:35:46 +0100 (CET) Received: from macbook-pro-de-julien.home (lfbn-idf3-1-527-171.w86-252.abo.wanadoo.fr [86.252.110.171]) by denver.dinauz.org (Postfix) with ESMTPSA id 3916960583 for ; Sun, 3 Jan 2021 18:35:46 +0100 (CET) To: emailcore@ietf.org References: From: =?UTF-8?Q?Julien_=c3=89LIE?= Message-ID: <61ccc7cc-6544-1f68-f3e5-276fb10f6abf@trigofacile.com> Date: Sun, 3 Jan 2021 18:35:46 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #28: Erratum 1851: Location of text about TCP connection has closure/reset X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2021 17:35:55 -0000 Hi all, > Strawman proposal: Section 4.1.1.5 is indeed a wrong place for this > text. I think Section 3.8 is the right place for it. The last paragraph > of 3.8 already contains the following text: > > SMTP clients that experience a connection close, reset, or other > communications failure due to circumstances not under their control > (in violation of the intent of this specification but sometimes > unavoidable) SHOULD, to maintain the robustness of the mail system, > treat the mail transaction as if a 451 response had been received and > act accordingly. Incidentally, I see in rfc5321bis-01 that the suggested response code in erratum 1851 has been changed from 451 to 421 (in Section 3.8). Is 421 really the right code to assume in the above paragraph in Section 3.8? 451 is described as: 451 Requested action aborted: error in processing If not mentioned elsewhere in the document, nobody will know its intended use case. 421 is described as: 421 Service not available, closing transmission channel (This may be a reply to any command if the service knows it must shut down) Though 421 mentions the closure, it does not suggest the abortion (451) whereas the above paragraph in Section 3.8 hints at that. -- Julien ÉLIE « Il n'y a qu'un remède à l'amour : aimer davantage. » (Henry David Thoreau) From nobody Sun Jan 3 09:38:56 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7825B3A1059; Sun, 3 Jan 2021 09:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 i5b8F0hSaad1; Sun, 3 Jan 2021 09:38:52 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9552A3A1058; Sun, 3 Jan 2021 09:38:52 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kw7L9-000AJd-9N; Sun, 03 Jan 2021 12:38:51 -0500 Date: Sun, 03 Jan 2021 12:38:44 -0500 From: John C Klensin To: Leo Gaspard , emailcore@ietf.org Message-ID: <36863283686B78FFFEA96D00@PSB> In-Reply-To: <87lfdakzvn.fsf@llwynog.ekleog.org> References: <87turzkvp7.fsf@llwynog.ekleog.org> <95d12af3-7406-1399-8d26-47d8ed00bbda@dcrocker.net> <87lfdakzvn.fsf@llwynog.ekleog.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] SMTP compliance suite? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2021 17:38:55 -0000 --On Sunday, January 3, 2021 12:45 +0100 Leo Gaspard wrote: >... > What I'm thinking is, if we could get such an SMTP compliance > suite be published as an RFC, it might help formally retiring > retired experiments, as well as clarifying which ones are > still running. And maybe even add in best practices for how > people nowadays are expected to implement the quoted RFCs (eg. > I'd expect best practices for DMARC policy to start like > "either have p=3Daccept or pct=3D0 if you want to send mail to > mailing lists" nowadays, and to with time eventually crank > up to "p=3Dreject pct=3D100" =E2=80=94 but this requires the = ability > to make evolving-with-time recommendation) >=20 > Now=E2=80=A6 I am not sure RFCs are the proper medium to = define such > a compliance suite? But on the other hand, I don't see who > else would have legitimate authority to say "there is > consensus and this is the set of protocols that should be > implemented nowadays to make both the mail ecosystem and your > own mail setup work best" Leo, Your original question was, I think, interpreted in several different ways and I'm glad you found several of those responses helpful. I want to address the above, which is not about the desirability of conformance/compliance suites or where to find them about about the IETF going into that business. First, to clarify a bit more, IETF has explicit provisions for documents that say "we recommend you do X" or even "start with N and gradually work up to M". Depending on how they are written, what issues are addressed, and how they related to the technical specifications themselves, those document can be either "Applicability Statements" (A/Ss) or "Best Current Practice" (BCP) specifications. See RFC 2026. Technical Specifications and Applicability Statement materials can even be mixed in the same document and you will find some of that in RFC 5321. However, there is a long history of standard bodies going into the actual compliance (or conformance) test business and it is almost bad. One reason is that, while the tests almost never cover everything, they become the real standard with people paying attention to the tests and what passes them and no to the text of the standard. In some cases, that has led to reduced interoperability because of problems with things the standard specifies but the tests don't cover. In others, it has led to actual damage, sometimes followed by litigation, when a party has specified that products must pass the conformance tests only to discover that products can pass the tests but not actually work in production and under load. =20 If a conformance suite is produced by Fred Example and Company, those issues are rather different: they are that company's opinion about how to test what conforms and their interpretation of the standard(s) and how they fit together. If that company is sensible, they will not make strong claims that their tests accurately cover every significant aspect of the standard, only that they represent their best efforts to do so. If they make a strong claim, that, and the problems (and lawyers) that will likely follow, are on their heads and do not compromise either the standards or the SDOs. =20 One of the examples that has come up actually illustrates this. If I recall, John Levine and I had a minor disagreement about as aspect of one of his tests of SMTPUTF8 implementations. The issue was minor (minor enough that I don't remember what it was). We could agree that it didn't make the tests unsuitable for the purpose for which they were being used; and we could all move forward. But, had the same tests been formally adopted by the IETF as proving or disproving conformance / compliance, it would have been incumbent on us to work out those issues and agree that they were completely consistent with the standards (that is a stronger requirement than merely having consensus that the tests were a good idea). So, please don't even think about IETF-produced or IETF-endorsed compliance/ conformance test suites. john From nobody Sun Jan 3 09:55:52 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC933A107B for ; Sun, 3 Jan 2021 09:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=jbXr4Fj8; dkim=pass (2048-bit key) header.d=taugh.com header.b=dkblHL5g 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 JiLcyM_gz7me for ; Sun, 3 Jan 2021 09:55:48 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 CDDE03A1076 for ; Sun, 3 Jan 2021 09:55:47 -0800 (PST) Received: (qmail 83038 invoked from network); 3 Jan 2021 17:55:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=1445b.5ff20522.k2101; bh=vlS80bmtnw+RNVpCRm8M8P7E971dnwdOMlqIUkkknTU=; b=jbXr4Fj8KIiWxmyeCK5rTWBJVHY7M73OS35Veqbayei2PufJpSpJfY9kt8PsenC1dmC9FEPVCsaNS6kOeLkgPBo3pbnV0WwL0AYWoFGqqBQCQpy83dlsC5QOQwwELerUzV7/cGD0ge5mH585owAZyIkXb0Jr1+tWqw/+t7K06Wa5KiWfESZQF59XNZcBqOKO8kwGpv2okGrw4kEVA/T1OPecMr4etCAS88qLkF7yngjBVUzg8udP2wRA+BYnxr2rztksY8dxKLAu4L6KpYaHi6qnfy/9CjSEWaS7K1y6bDIkSqM4sJTxj2ZyIbYYMv1ySFhGpD7tvJYp8LFA6zL3ig== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=1445b.5ff20522.k2101; bh=vlS80bmtnw+RNVpCRm8M8P7E971dnwdOMlqIUkkknTU=; b=dkblHL5grJvdxHjkL4IfQ0Mf/5TpU7LpJyZIEBoJaSySdTzYskR+DBE73Xe/gan8D5ZKkojI2q4JXfvH/w/B1TJUNB1cxwKlayes2cPSQ51TNxQ3ibAcZccCmrHK8WyZnTt3MXXssohqgwH0Htk68W6KdkJ8ALom/cWxzqplb0PbbXowvfeocVGl7u0CCL5NGbkOuVFjWJtG2ElbQWI4p3b2xfmFEc1KxkehWX5dOoy1DGUdCscbuCdec5VRNHds1E3kHi0fvkj9zTupofx28X+H+rQDVY80JtwBy8+SwTb3xQCDnVdfIDGfJlC66U87SspFwmHJco93p61H5v3c+Q== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 03 Jan 2021 17:55:45 -0000 Received: by ary.qy (Postfix, from userid 501) id 4F9F24EE2FC3; Sun, 3 Jan 2021 12:55:45 -0500 (EST) Date: 3 Jan 2021 12:55:45 -0500 Message-Id: <20210103175545.4F9F24EE2FC3@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: john-ietf@jck.com In-Reply-To: <36863283686B78FFFEA96D00@PSB> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] SMTP compliance suite? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2021 17:55:50 -0000 In article <36863283686B78FFFEA96D00@PSB> you write: >One of the examples that has come up actually illustrates this. >If I recall, John Levine and I had a minor disagreement about as >aspect of one of his tests of SMTPUTF8 implementations. The >issue was minor (minor enough that I don't remember what it >was). .... I don't remember what it was either, but there is at least one test that a package failed, I wrote to its author who disagreed with my interpretation of the standard. While I think my interpretation is right, I am not so confident that I would tell people that the package isn't standards compliant. >So, please don't even think about IETF-produced or IETF-endorsed >compliance/ conformance test suites. I assumed he was asking for advice on how to do his own compliance tests, not to make it an IETF thing. R's, John From nobody Sun Jan 3 10:51:21 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343463A10DF for ; Sun, 3 Jan 2021 10:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 WWKpR59YYQXz for ; Sun, 3 Jan 2021 10:51:18 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4D43A10F0 for ; Sun, 3 Jan 2021 10:51:17 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kw8TE-000Aev-7E; Sun, 03 Jan 2021 13:51:16 -0500 Date: Sun, 03 Jan 2021 13:51:09 -0500 From: John C Klensin To: John Levine , emailcore@ietf.org Message-ID: In-Reply-To: <20210103175545.4F9F24EE2FC3@ary.qy> References: <20210103175545.4F9F24EE2FC3@ary.qy> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] SMTP compliance suite? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2021 18:51:19 -0000 --On Sunday, January 3, 2021 12:55 -0500 John Levine wrote: > In article <36863283686B78FFFEA96D00@PSB> you write: >> One of the examples that has come up actually illustrates >> this. If I recall, John Levine and I had a minor disagreement >> about as aspect of one of his tests of SMTPUTF8 >> implementations. The issue was minor (minor enough that I >> don't remember what it was). .... > > I don't remember what it was either, but there is at least one > test that a package failed, I wrote to its author who > disagreed with my interpretation of the standard. While I > think my interpretation is right, I am not so confident that I > would tell people that the package isn't standards compliant. And that would be exactly the problem with an IETF-sanctioned or published suite. It is also where such things and the robustness principle (and the "Do The Right Thing" one) come in because the only real alternative is to try to specify every detail, preferably in formal language that can be proven complete and correct... and, in practice, that just doesn't work with protocols with lots of cases and a need to adapt to, rather than the ability to completely control, the environment in which they operate. >> So, please don't even think about IETF-produced or >> IETF-endorsed compliance/ conformance test suites. > > I assumed he was asking for advice on how to do his own > compliance tests, not to make it an IETF thing. I couldn't tell from the initial message. But the note to which I replied contained >>> What I'm thinking is, if we could get such an SMTP >>> compliance suite be published as an RFC, it might help >>> formally retiring >> retired experiments, as well as >>> clarifying which ones are still running. And maybe even >>> add in best practices for how people nowadays are >>> expected to implement the quoted RFCs >>> (eg. ... and that seemed to me to be going rather far in the direction of "IETF thing", hence the note/warning. john From nobody Sun Jan 3 15:11:36 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1313A13FC for ; Sun, 3 Jan 2021 15:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=leo.gaspard.io 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 EPn-Y5QnwDOK for ; Sun, 3 Jan 2021 15:11:32 -0800 (PST) Received: from smtp.gaspard.ninja (grym.ekleog.org [94.23.42.210]) (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 17BED3A13FB for ; Sun, 3 Jan 2021 15:11:31 -0800 (PST) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id 195983d2; Sun, 3 Jan 2021 23:11:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=leo.gaspard.io; h= from:to:subject:in-reply-to:references:date:message-id :mime-version:content-type:content-transfer-encoding; s= grym-20170528; bh=D6j8LG6ZN9czVkGS1KJamYVcNOY=; b=iTjaZExsyagrIl sH9pUMTWb8g9pXPcfWUwSPhrFOQGFwEKFQ6R/7zUOPFAFClHoDo/DkCkB9W5hvzR gJ5YD9yxf69s/n7ZyQqX0FHE/bCd3i+uMn0wd1iOTQrK//7GNierk4WZeWZX6w9C l2/eNgjwPvEXP4EtPyau+NgwBn/c0= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPS id c9005e01 (TLSv1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256:NO); Sun, 3 Jan 2021 23:11:25 +0000 (UTC) Received: from localhost (llwynog [local]) by llwynog (OpenSMTPD) with ESMTPA id cd2b3bd3; Sun, 3 Jan 2021 23:11:25 +0000 (UTC) From: Leo Gaspard To: John Levine , emailcore@ietf.org In-Reply-To: <20210102224013.5D1E64A3E709@ary.qy> References: <20210102224013.5D1E64A3E709@ary.qy> Date: Mon, 04 Jan 2021 00:11:25 +0100 Message-ID: <87k0stlioy.fsf@llwynog.ekleog.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] SMTP compliance suite? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2021 23:11:35 -0000 (originally sent this email from a non-subscribed email address, sorry for the duplicate) "John Levine" writes: > https://github.com/jrlevine/eaitesttools > > The MSA and MTA tests sort of by default check the SMTP compliance of > whatever I'm testing. Not surprisingly, SMTP compliance was excellent > in MSA and MTA software not written in Redmond WA, and there the > errors were largely cosmetic, e.g., minor syntax errors in generated > Received headers. > > I would be pretty surprised if any MSA or MTA you ever heard of failed > any test that anyone cared about. Is there anything in particular you > were hoping to find out? Thank you for this link! It looks like a useful test suite. That said, I was more thinking of an =E2=80=9CSMTP compliance suite=E2=80=9D as a compen= dium of good practices and =E2=80=9Cwhat should be done to be a well-behaved citizen of = the SMTP system=E2=80=9D more than as a test suite. This is not to diminish the importance of test suites (it'd be great to have a =E2=80=9CSMTP compliance suite 2020 test suite=E2=80=9D), but on the= other hand it feels to me like there should first be consensus on what such compliance requirements would be. From nobody Sun Jan 3 18:40:33 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2B43A1564 for ; Sun, 3 Jan 2021 18:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 VdIS2bAEgWQm for ; Sun, 3 Jan 2021 18:40:30 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF2323A1563 for ; Sun, 3 Jan 2021 18:40:30 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kwFnI-000CkB-Q7; Sun, 03 Jan 2021 21:40:28 -0500 Date: Sun, 03 Jan 2021 21:40:22 -0500 From: John C Klensin To: =?UTF-8?Q?Julien_=C3=89LIE?= , emailcore@ietf.org Message-ID: <1E9A38A1793DB0130A7E2D0A@PSB> In-Reply-To: <6580dd9f-b566-5c30-e6ed-2ea9121a5ae5@trigofacile.com> References: <59447e97-5446-401b-8b40-e0d09118acb2@www.fastmail.com> <6580dd9f-b566-5c30-e6ed-2ea9121a5ae5@trigofacile.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #28: Erratum 1851: Location of text about TCP connection has closure/reset X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 02:40:32 -0000 --On Sunday, January 3, 2021 18:23 +0100 Julien =C3=89LIE wrote: > Hi Alexey, >=20 >>> o After detecting the need to shut down the SMTP >>> service and returning a 421 reply code. This reply >>> code can be issued after the server receives any >>> command or, if necessary, asynchronously from >>> command receipt (on the assumption that the client >>> will receive it after the next command is issued). >>>=20 >>> I'm wondering whether the part in parenthesis really occurs >>> in practice, notably when the closure is asynchronous from >>> command receipt. Maybe it should be reworded this way: "on >>> the assumption that the client will receive it after the >>> next command is issued or read it before closing the >>> connection at its side"? >>=20 >> I think we should open a separate ticket on this. >=20 > Ticket #46 just opened, thanks. Ok, but please see the last paragraph or two of my note to Alexey in this thread sent December 31, 2020 18:16 -0500. best, john From nobody Sun Jan 3 22:29:42 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01C13A16D8 for ; Sun, 3 Jan 2021 22:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.26 X-Spam-Level: X-Spam-Status: No, score=-0.26 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.262, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 jlctI-P5U0FC for ; Sun, 3 Jan 2021 22:29:38 -0800 (PST) Received: from denver.dinauz.org (denver.dinauz.org [37.59.56.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90AE13A16D7 for ; Sun, 3 Jan 2021 22:29:38 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id 02B8060588 for ; Mon, 4 Jan 2021 07:29:35 +0100 (CET) Received: from denver.dinauz.org ([127.0.0.1]) by localhost (denver.dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0dQCX64_dsg for ; Mon, 4 Jan 2021 07:29:34 +0100 (CET) Received: from macbook-pro-de-julien.home (lfbn-idf3-1-527-171.w86-252.abo.wanadoo.fr [86.252.110.171]) by denver.dinauz.org (Postfix) with ESMTPSA id D1B2F60584 for ; Mon, 4 Jan 2021 07:29:34 +0100 (CET) To: emailcore@ietf.org References: <59447e97-5446-401b-8b40-e0d09118acb2@www.fastmail.com> <6580dd9f-b566-5c30-e6ed-2ea9121a5ae5@trigofacile.com> <1E9A38A1793DB0130A7E2D0A@PSB> From: =?UTF-8?Q?Julien_=c3=89LIE?= Message-ID: Date: Mon, 4 Jan 2021 07:29:34 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <1E9A38A1793DB0130A7E2D0A@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #28: Erratum 1851: Location of text about TCP connection has closure/reset X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 06:29:41 -0000 Hi John, >>>> I'm wondering whether the part in parenthesis really occurs >>>> in practice, notably when the closure is asynchronous from >>>> command receipt. Maybe it should be reworded this way: "on >>>> the assumption that the client will receive it after the >>>> next command is issued or read it before closing the >>>> connection at its side"? >>> >>> I think we should open a separate ticket on this. >> >> Ticket #46 just opened, thanks. > > Ok, but please see the last paragraph or two of my note to > Alexey in this thread sent December 31, 2020 18:16 -0500. Did your note reach this mailing-list? I'm sorry, I do not manage to find it in https://mailarchive.ietf.org/arch/browse/emailcore/ (neither 2020-12-31 23:16 UTC nor on that day) -- Julien ÉLIE « Donner un sens plus pur aux mots de la tribu. » (Stéphane Mallarmé) From nobody Tue Jan 5 11:22:31 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F213A1058 for ; Tue, 5 Jan 2021 11:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 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.262, 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 GURcfheFU5yN for ; Tue, 5 Jan 2021 11:22:27 -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 6E6A73A102B for ; Tue, 5 Jan 2021 11:22:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609874543; bh=uvS9XkqaAKsq0hg+xyS6DHcSjZyA5Xl+ABZ20eKdXEg=; l=2114; h=To:References:From:Date:In-Reply-To; b=CQmO7GdIKD0cSMX8pcLyuG/xEerEoWVu0UBi5mvlkkt2ZWHJtX63O7LX3ikgy1tDi cb1PJftPAy4hzKk/tlG3qDyfLzULDWBOEFVDfHJQAHKUVuk4hzb5lPHpjc3tcbtCaw e/wtXvK0Aw9POVyaWHmzWsD3VGdCk8VfkGAUSKAzqldaO8D7CB6usTN6TjAWg Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC056.000000005FF4BC6F.000058F8; Tue, 05 Jan 2021 20:22:23 +0100 To: John C Klensin , Jeremy Harris , emailcore@ietf.org References: <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> <0ea03115-8730-1759-58ec-a4fbcd8508e6@dcrocker.net> From: Alessandro Vesely Message-ID: <9f27f29f-2b4e-57ad-3d54-c2a5e04d8c62@tana.it> Date: Tue, 5 Jan 2021 20:22:22 +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: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 19:22:29 -0000 On Sun 03/Jan/2021 01:37:48 +0100 John C Klensin wrote: > --On Saturday, January 2, 2021 21:56 +0000 Jeremy Harris wrote: > >>> Should we be defining both, making it clear that they are >>> different, and then making whatever recommendations seem >>> appropriate about which one (or both) should be provided? >> >> I agree that Envelope-To: and Delivered-To: are different. >> >> I'm not convinced that this document is the right place >> for either. I guess there's a benefit in writing down the >> definitions somewhere; the cost is "only" cruft that >> obscures the minimum requirements for implementing an MTA. > > My understand was that we had gotten to "separate document", or > at least "not in 5321bis" some day ago. I hope that is the case > and that the perceived agreement holds. This discussion brought up another defect of RFC 5321, methinks. It does not define a straight line between an MTA and an MDA. Section 4.4 says: When the delivery SMTP server makes the "final delivery" of a message, it inserts a return-path line at the beginning of the mail data. Although the reasons for doing so are well explained, and are part of SMTP because of the reliability implications, inserting Return-Path: really looks like an MDA's job, not MTA's. Perhaps, the text should say something like: When an SMTP server accepts a message for local delivery, it invokes a delivery agent passing to it the content and relevant parts of the envelope. In particular, it MUST pass the , which is used by the delivery agent to insert a return-path line at the beginning of the mail data. In that case, mentioning that an MTA also passes the relevant , would not require to fulfill the steps (i)-(iv) of a previous message[*], because neither the MTA/MDA interface nor (all) the duties of MDAs are part of the specification. Yet, it allows the I-D to mention non-normatively the names of Delivered-To:, Envelope-To:, and X-Original-To:. jm2c Ale -- [*] https://mailarchive.ietf.org/arch/msg/emailcore/Vt1AboaP8j8rxnccedGvaLoPLyU From nobody Tue Jan 5 11:26:40 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7483A109D for ; Tue, 5 Jan 2021 11:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 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.262, 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 jB4kKdbaFkmg for ; Tue, 5 Jan 2021 11:26:37 -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 8218E3A11AF for ; Tue, 5 Jan 2021 11:26:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609874786; bh=UpWlV4e3iLcZMKzvnfkcJb8GYz9xMjU37D57Cslr4ks=; l=712; h=To:References:From:Date:In-Reply-To; b=Cc3U0ZrT8MPuh512C5UHjS8M42lYrnY4gWakyzTHYsMGE2xhQpwJymeyyq/+70qoR e8J5Ui5MwMACDLsx+VrJ6GDwPv7bYxWteyGfflOQWwiIBa6B8WS1hDLIMasocn0ZY3 M5bxYaWlv7kM0RFVDdjaVj6PpduxxhoebARIY9VSTR7vCVTU30NWK5cW/+azd Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC056.000000005FF4BD62.00005977; Tue, 05 Jan 2021 20:26:26 +0100 To: emailcore@ietf.org References: <20210101221723.ED67D45047D9@ary.qy> <4860de0-38f4-3d86-6c55-398f906242e@taugh.com> From: Alessandro Vesely Message-ID: <27ff88ee-13e8-7749-5b46-d17d33ab4423@tana.it> Date: Tue, 5 Jan 2021 20:26:25 +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: <4860de0-38f4-3d86-6c55-398f906242e@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 19:26:39 -0000 On Fri 01/Jan/2021 23:23:41 +0100 John R Levine wrote: > On Fri, 1 Jan 2021, John Levine wrote: >> In article you write: >>>      Should the recipient's MUA have access to the /sequence/ of RCPT TO >>>      addresses used to get to them? >> >> If we're documenting existing practice, which I think would be a good idea, yes. > > Also remember that it's used to detect mail loops, and if you have a loop like > A->B->C->A you need the history to see that you're looping. Another use of Delivered-To:, by MUAs, is to fill the From: field in compose windows with the correct value, for users receiving multiple aliases. Best Ale -- From nobody Tue Jan 5 11:31:05 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9CE3A0F61 for ; Tue, 5 Jan 2021 11:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 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.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 Mk5QIHw0Pnr6 for ; Tue, 5 Jan 2021 11:31:02 -0800 (PST) Received: from bird.elm.relay.mailchannels.net (bird.elm.relay.mailchannels.net [23.83.212.17]) (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 9024F3A0F5E for ; Tue, 5 Jan 2021 11:31:01 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E26EE362CF5; Tue, 5 Jan 2021 19:30:58 +0000 (UTC) Received: from nl-srv-smtpout3.hostinger.io (100-98-64-116.trex.outbound.svc.cluster.local [100.98.64.116]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 4CDF3362E9B; Tue, 5 Jan 2021 19:30:56 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout3.hostinger.io ([UNAVAILABLE]. [145.14.159.243]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Tue, 05 Jan 2021 19:30:58 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Vacuous-Industry: 1a713d032ec3f8af_1609875056968_815090979 X-MC-Loop-Signature: 1609875056968:1200922049 X-MC-Ingress-Time: 1609875056968 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout3.hostinger.io (smtp.hostinger.com) with ESMTPSA id 3E63331C2C4D; Tue, 5 Jan 2021 19:30:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1609875054; bh=ePLM7VTgKzSc+47BqWDTNRNmdDptqxG6/8tUZ6/4x0g=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=sWZ8BM4Ew5nkSGaORRidHRACY7+veivwT22CPsKrg1V90E6Gk1egHOFNAGcNvmwb0 YzSI6RxCbZURLhEMsWzVpycczHNjvz/RHpGoyKWmXf+ejjwq9/CLjNYB0G2NNCfSWY x7RMqDlABZkLm7Vwcv0x7LiNP+J2HJCZp66LlhT/Q9s9MQ13zNmuYM/rNabwGxrw6t l3yhDeRJFF3oCYzB8AojcmiMVHEblKX6y1sVXiYwRQ5MwEPWjV3HoWn62iE6sXjiWQ kUIfQTiIcvUcbrBhFpTjAkmDZ7Cs662qvi+Z37cnWS/yXKbRQ/lOyJWLum+YGjv2kw sHv4FWM7dGfGg== Reply-To: dcrocker@bbiw.net To: Alessandro Vesely , emailcore@ietf.org References: <20210101221723.ED67D45047D9@ary.qy> <4860de0-38f4-3d86-6c55-398f906242e@taugh.com> <27ff88ee-13e8-7749-5b46-d17d33ab4423@tana.it> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <86be74fe-e3fc-9504-a9d0-192372b4bcb5@dcrocker.net> Date: Tue, 5 Jan 2021 11:30:51 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <27ff88ee-13e8-7749-5b46-d17d33ab4423@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 19:31:04 -0000 On 1/5/2021 11:26 AM, Alessandro Vesely wrote: > Another use of Delivered-To:, by MUAs, is to fill the From: field in > compose windows with the correct value, for users receiving multiple > aliases. I assume you mean filling in the rfc 5322.From field of a /reply/ message is the utility you have in mind? And yes, that seems a plausible use, to me. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jan 5 12:56:28 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1C63A1211 for ; Tue, 5 Jan 2021 12:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 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, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=KwYVx3tL; dkim=pass (2048-bit key) header.d=taugh.com header.b=g8BkxMbC 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 j5TjMPDvUbLf for ; Tue, 5 Jan 2021 12:56:25 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 6CC6C3A1213 for ; Tue, 5 Jan 2021 12:56:25 -0800 (PST) Received: (qmail 22353 invoked from network); 5 Jan 2021 20:56:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=574e.5ff4d276.k2101; bh=wcZqkKALycgmZDbO3urbhovxDTWg8vBliVxnw3xmwO0=; b=KwYVx3tL7tmtxvLWBgCQUlv60+gDpJyKiK2Br5CPajUp6QG3AAIui/o3BsAqqE4kIgVrlQ7PC17YATD7eMQnHcWo3zc4Mi60J7sdNEwdQnANTD1Xbg74Qj1mcFiAWvGjRXogXW0/GhPF6WqFtgD5DRzBTEtdUAFGFnhp7GIp5zY/DJ0D6Hz2OC3Kr23GMpFkG+PlQ9Bnn5T1BAGMNx0DXKdeBcwSZG4SHeeDxtlEQPTANttjGaMBZGEwBzDnWoszYrVvNStJbHtKFx29yk9U3zF5K15aNtw59eweOmLKMHpsCzNHVyTwosMUxRsj/xciS1pmgn26GZx5+G++1B43bQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=574e.5ff4d276.k2101; bh=wcZqkKALycgmZDbO3urbhovxDTWg8vBliVxnw3xmwO0=; b=g8BkxMbC6ZxaeJByKpfTfVWkbiOP/XfZI1yuG6ZDwZ7fPAQBpRa0c7Gx4De6GRaMQPZakS9QdIVg2Hp7086rT3MDNAIy54HhqGGq30Lp437xJK7490aC0vE/fP9w6CvuMTk6+A9O8vg8fXGY1b6yjB+VxeS3pdIYkjwsC8H3NHIAmxZn91MpYc4xAJhsrwNFCwXk2fq+jBepJdwvzmGoZvQ1L9oZ8HvIX9Wb9lJwW5w8l5+vTaREvSIF5DK5YrY4rdiChDnCh7ujDcDT6PmPRE6QWuuuIgbAxTi7o7SB2N0KTPw0fBM5tkrPDyV4hcSceYwAup5W0lBXTNCT5EuKuw== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 05 Jan 2021 20:56:22 -0000 Received: by ary.qy (Postfix, from userid 501) id 798525829FC6; Tue, 5 Jan 2021 15:56:20 -0500 (EST) Date: 5 Jan 2021 15:56:20 -0500 Message-Id: <20210105205621.798525829FC6@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: vesely@tana.it In-Reply-To: <9f27f29f-2b4e-57ad-3d54-c2a5e04d8c62@tana.it> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Return-Path and Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 20:56:27 -0000 In article <9f27f29f-2b4e-57ad-3d54-c2a5e04d8c62@tana.it> you write: >Although the reasons for doing so are well explained, and are part of SMTP >because of the reliability implications, inserting Return-Path: really looks >like an MDA's job, not MTA's. ... Having written a lot of code that does this, I can say that it is often, maybe mostly, the MTA that drops the message into the mailbox. Unless someone believes that the current text is confusing people or causing interoperability problems, please leave it alone. We already have plenty to do. From nobody Tue Jan 5 13:20:44 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2548F3A02BB for ; Tue, 5 Jan 2021 13:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 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.262, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 jBBF0Dq7gFjX for ; Tue, 5 Jan 2021 13:20:40 -0800 (PST) Received: from hamster.birch.relay.mailchannels.net (hamster.birch.relay.mailchannels.net [23.83.209.80]) (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 619DD3A0163 for ; Tue, 5 Jan 2021 13:20:39 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 03AD77034A4; Tue, 5 Jan 2021 21:20:39 +0000 (UTC) Received: from nl-srv-smtpout4.hostinger.io (100-96-27-97.trex.outbound.svc.cluster.local [100.96.27.97]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id E38777033B3; Tue, 5 Jan 2021 21:20:36 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout4.hostinger.io ([UNAVAILABLE]. [145.14.159.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Tue, 05 Jan 2021 21:20:38 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Squirrel-Chemical: 234947875efc6264_1609881638615_2379846667 X-MC-Loop-Signature: 1609881638615:2837697307 X-MC-Ingress-Time: 1609881638615 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout4.hostinger.io (smtp.hostinger.com) with ESMTPSA id 9939131A1285; Tue, 5 Jan 2021 21:20:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1609881635; bh=DepXZbLGV9eqqs85GjduHb7KLjRocLx/BuXCFvCjE8E=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=XqDRy/djeKXZ2Lj6UU3kQDQjVL35+LI6V98G88YC785XOtSurVAVMLgfaGSaKppVE oZGl3YbHMjNIt47LC9vjB5CQTajc8WKp8ENnF/M1ithR/v4gZPOXC3upTfjJap9gtx El8xTcNYS122qsKzabEp2SCz0H70sPOT3glAVlLT8BnugNrxs8HHkYqjH9n9dOpFd0 KltSwgEoeujWfdnQpVDzpPQk/YqljN6gx3XE5liAKnvn9yJm9h4bYica1ModCoDDho 2L9yx5WAZxuVZ949vVZ+AZMotz4izLTGepVtPslyt1yru8BzgWXU44LsTc4XS+7BX5 psBMNoQhQ0oSw== Reply-To: dcrocker@bbiw.net To: John Levine , emailcore@ietf.org Cc: vesely@tana.it References: <20210105205621.798525829FC6@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 5 Jan 2021 13:20:30 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20210105205621.798525829FC6@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Return-Path and Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 21:20:42 -0000 On 1/5/2021 12:56 PM, John Levine wrote: > Having written a lot of code that does this, I can say that it is > often, maybe mostly, the MTA that drops the message into the mailbox. > > Unless someone believes that the current text is confusing people or > causing interoperability problems, please leave it alone. We already > have plenty to do. If it 'drops the messag into the mailbox' then i is acting in the role of an MDA. By definition. This exemplifies the different between abstract networking architecture -- which is what the MDA role is -- from specific software implementation. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jan 5 13:53:38 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9B33A08F4 for ; Tue, 5 Jan 2021 13:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=eeRk4HCc; dkim=pass (2048-bit key) header.d=taugh.com header.b=f5UimRqr 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 PtRLLdl6bTGg for ; Tue, 5 Jan 2021 13:53:34 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 A3BA83A0888 for ; Tue, 5 Jan 2021 13:53:34 -0800 (PST) Received: (qmail 36083 invoked from network); 5 Jan 2021 21:53:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=8cf1.5ff4dfdc.k2101; i=johnl-iecc.com@submit.iecc.com; bh=onB8jfJFZzgKC2+yQ2SoGTpA1K5OccOrT5eRdpwAls0=; b=eeRk4HCcgcYlHpSc4TOrx0lafxlDiYfrVyPs6xKExbDdUrXXw1r1CD8wf8MZvW6fO1Plz6nd6jY5crpqszLsTqu5f68WoVUAihzAbWEUgQH14R9uVdhwjclLLGeBbIRJ+Br+zYpz1lJHDzM9Vf+l8uTtAZJ82s2EXDpQqgn5AM0BZSyfq0zZu+oYeMsKsctfE5cAKS1WIFMKzmQjvGQ+I0eZuVTZCH+IT12Xg/9DGRYv4rjQrHvLSk1KXk2aKdfkSJW19I7RIgIu49NVH32HqfuEnGbiTJOQ/cT4S+Q5ybZvlonPNfKB9tiki+v6q7t62yxxA69GvEeIxs+9gIGV4A== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=8cf1.5ff4dfdc.k2101; olt=johnl-iecc.com@submit.iecc.com; bh=onB8jfJFZzgKC2+yQ2SoGTpA1K5OccOrT5eRdpwAls0=; b=f5UimRqr7tMbvJx1ybTKpeWkURQWiuXAiYmtoXDOq230px7egmIAupCzNqA7fbusf6C+bEQI32c5yLOaY5mIYzZKw2xeo34nc7H+NqyuioFoTJd89Vzw9WwvToYSOc+D0tJnaOtby7UQF/sDGIAd+lm8aMsM4sVVnEetDUZ7YlYQZBdG3PAzUHmS7v1Ii1xVMKWZJWEUJGyC2QU9VubmXFmC0KIqun/h2+BgR3fifmfd7jh9YdOL+bJIOgC6Q9a42Y6jZGCHa0WJj5OuTXhavEkiXqIkGjYnfJP2j7WCRmPKz5tN8izcqpM2SzWjdF8pjMMGqpJCkcIRdnPLFegdOQ== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 05 Jan 2021 21:53:31 -0000 Date: 5 Jan 2021 16:53:31 -0500 Message-ID: <2fc78e84-ba85-7fdd-e2f3-8fbb50cdf4f0@taugh.com> From: "John R Levine" To: "Dave Crocker" , emailcore@ietf.org In-Reply-To: References: <20210105205621.798525829FC6@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] Return-Path and Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 21:53:37 -0000 On Tue, 5 Jan 2021, Dave Crocker wrote: > On 1/5/2021 12:56 PM, John Levine wrote: >> Having written a lot of code that does this, I can say that it is >> often, maybe mostly, the MTA that drops the message into the mailbox. > > If it 'drops the messag into the mailbox' then i is acting in the role of an > MDA. By definition. Indeed, but ... >> Unless someone believes that the current text is confusing people or >> causing interoperability problems, please leave it alone. We already >> have plenty to do. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Jan 5 13:59:32 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E084B3A0925 for ; Tue, 5 Jan 2021 13:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 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.262, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 j_R5FyHTFhMz for ; Tue, 5 Jan 2021 13:59:28 -0800 (PST) Received: from aye.elm.relay.mailchannels.net (aye.elm.relay.mailchannels.net [23.83.212.6]) (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 035003A0907 for ; Tue, 5 Jan 2021 13:59:27 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 580627E18EC; Tue, 5 Jan 2021 21:59:26 +0000 (UTC) Received: from nl-srv-smtpout1.hostinger.io (100-96-5-6.trex.outbound.svc.cluster.local [100.96.5.6]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id ABEC57E35D3; Tue, 5 Jan 2021 21:59:24 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout1.hostinger.io ([UNAVAILABLE]. [185.224.136.7]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Tue, 05 Jan 2021 21:59:26 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Whimsical-Tasty: 0b91d36e31e69416_1609883965874_1654382445 X-MC-Loop-Signature: 1609883965874:979881842 X-MC-Ingress-Time: 1609883965874 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout1.hostinger.io (smtp.hostinger.com) with ESMTPSA id 5E9582B78AB8; Tue, 5 Jan 2021 21:59:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1609883963; bh=lPTcnKgOgDmOIHjGs5XmAG+QkBdVycQ7/4CoS3iz/fM=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=geZU8kZ2qcbRl9dm9xmV8WT5Hwft+F+idMnqGEbrx8HfirJlhP1k+uhoQOm6iGk+Z PTvNKIRn8WLpQHuPcA8PctEfvLfewPcnsCptL9Wzb8KCvnODFEqQ9e1PnqwXskRH3B NRp/waB7PZ4XLT7pYQ04vZQnGcYHNFu9KDMc6TNyNB7ijiK7Llof476JhJ0kp6HQje jdralLoeKniUmrN7Tep/sDArYhJR4K83R6fkpJEwVAt368LJJhe5NvGJhr8MzSYfUd unHFZSCeZz12L4OClsABW1IVG3xpHgHVxfiME3+UK8GWquQND8Z18cqzdp/DXpPU9z VHG0Mu1CkXBow== Reply-To: dcrocker@bbiw.net To: John R Levine , Dave Crocker , emailcore@ietf.org References: <20210105205621.798525829FC6@ary.qy> <2fc78e84-ba85-7fdd-e2f3-8fbb50cdf4f0@taugh.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 5 Jan 2021 13:59:18 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <2fc78e84-ba85-7fdd-e2f3-8fbb50cdf4f0@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Return-Path and Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 21:59:30 -0000 On 1/5/2021 1:53 PM, John R Levine wrote: > On Tue, 5 Jan 2021, Dave Crocker wrote: >> On 1/5/2021 12:56 PM, John Levine wrote: >>> Having written a lot of code that does this, I can say that it is >>> often, maybe mostly, the MTA that drops the message into the mailbox. >> >> If it 'drops the messag into the mailbox' then i is acting in the role >> of an MDA.  By definition. > > Indeed, but ... > >>> Unless someone believes that the current text is confusing people or >>> causing interoperability problems, please leave it alone. We already >>> have plenty to do. Your latter point is quite separate from the former. The former should at least moderate how we talk about these issues. Hence my response about saying it is an MTA function. It isn't. Your latter point goes the question of whether to make changes, now, to the specification. This is a highly constrained effort. Your "Unless" is apt, of course. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jan 5 20:53:40 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65ACA3A0FBD for ; Tue, 5 Jan 2021 20:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 JR4W_jZRKxA2 for ; Tue, 5 Jan 2021 20:53:37 -0800 (PST) Received: from kiel.esmtp.org (kiel.esmtp.org [195.244.235.220]) (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 E73F63A0FB3 for ; Tue, 5 Jan 2021 20:53:36 -0800 (PST) Received: from kiel.esmtp.org (localhost. [127.0.0.1]) by kiel.esmtp.org (MeTA1-1.1.Alpha15.2) with ESMTPS (TLS=TLSv1.2, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256, verify=OK) id S000000000004131200; Wed, 6 Jan 2021 05:53:34 +0100 Received: (from ca@localhost) by kiel.esmtp.org (8.16.0.41/8.12.10.Beta0/Submit) id 1064rYlI079817 for emailcore@ietf.org; Wed, 6 Jan 2021 05:53:34 +0100 (CET) Date: Wed, 6 Jan 2021 05:53:34 +0100 From: Claus Assmann To: emailcore@ietf.org Message-ID: <20210106045334.GA13200@kiel.esmtp.org> Reply-To: emailcore@ietf.org Mail-Followup-To: emailcore@ietf.org References: <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> <0ea03115-8730-1759-58ec-a4fbcd8508e6@dcrocker.net> <9f27f29f-2b4e-57ad-3d54-c2a5e04d8c62@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9f27f29f-2b4e-57ad-3d54-c2a5e04d8c62@tana.it> Archived-At: Subject: Re: [Emailcore] Return-Path and Delivered-To issue X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 04:53:38 -0000 On Tue, Jan 05, 2021, Alessandro Vesely wrote: > When the delivery SMTP server makes the "final delivery" of a > message, it inserts a return-path line at the beginning of the mail > data. > Although the reasons for doing so are well explained, and are part of SMTP > because of the reliability implications, inserting Return-Path: really looks > like an MDA's job, not MTA's. Perhaps, the text should say something like: sendmail has an option for this: 5.4. M -- Define Mailer ... P This mailer wants a "Return-Path:" line. i.e., the MTA can provide that line for/to the MDA. Hence: please do not change the text. -- Address is valid for this mailing list only, please do not reply to it direcly, but to the list. From nobody Wed Jan 6 03:23:46 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFD13A1047 for ; Wed, 6 Jan 2021 03:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 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.262, 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 D8MkHIarTs_Z for ; Wed, 6 Jan 2021 03:23:42 -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 7FF073A0AF9 for ; Wed, 6 Jan 2021 03:23:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609932217; bh=l0s/abRWgmMN+Ajiq31GlRz7biptIfdtvjCVJOa8I6M=; l=816; h=To:References:From:Date:In-Reply-To; b=AZKEW7OXHhiOISd4dYrvUqX9f9HZoU2Whyi3HYSsRHROx77t8fVmcSOHOXZ5nzfWx TYmHVmj5ite+iVerI2y1kerAgUIYknV8jlYrzWTo8OLs2YKss2fe9fTvekduc9zYM8 h6bVxQTWR6nGA5POiFk8cfXkr00Nw9GhRJ9pe3INQtlGtf6Upd5fSZaRCvkib Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC056.000000005FF59DB9.00005A60; Wed, 06 Jan 2021 12:23:37 +0100 To: John R Levine , Dave Crocker , emailcore@ietf.org References: <20210105205621.798525829FC6@ary.qy> <2fc78e84-ba85-7fdd-e2f3-8fbb50cdf4f0@taugh.com> From: Alessandro Vesely Message-ID: Date: Wed, 6 Jan 2021 12:23:36 +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: <2fc78e84-ba85-7fdd-e2f3-8fbb50cdf4f0@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Return-Path and Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 11:23:45 -0000 On Tue 05/Jan/2021 22:53:31 +0100 John R Levine wrote: > On Tue, 5 Jan 2021, Dave Crocker wrote: >> On 1/5/2021 12:56 PM, John Levine wrote: >>> Having written a lot of code that does this, I can say that it is >>> often, maybe mostly, the MTA that drops the message into the mailbox. >> >> If it 'drops the message into the mailbox' then it is acting in the role of an >> MDA.  By definition. > > Indeed, but ... > >>> Unless someone believes that the current text is confusing people or >>> causing interoperability problems, please leave it alone. We already >>> have plenty to do. The only confusing point, IMHO, is the sneaky definition of a "delivery SMTP server". That is not an MDA, since it serves SMTP, yet conflicts with Dave's definition, since it does delivery. Best Ale -- From nobody Wed Jan 6 09:07:53 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB613A11B1 for ; Wed, 6 Jan 2021 09:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=FDgQ4IbQ; dkim=pass (2048-bit key) header.d=taugh.com header.b=QO78erMq 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 8hsMR0ZsOPHQ for ; Wed, 6 Jan 2021 09:07:37 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 09DC53A1184 for ; Wed, 6 Jan 2021 09:07:23 -0800 (PST) Received: (qmail 88846 invoked from network); 6 Jan 2021 17:07:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=15b09.5ff5ee47.k2101; bh=njNVtynq8fP6BYsh0k2mnnCZ+NUHwO0Tzv23kMnaMac=; b=FDgQ4IbQZFL3IxJ2EsaKIjhRqDBStmMkzCVXJHuYVByY0fog81T+dPuRM8n8Fl7FzLQVUrkmq2HBk1FqoxIkoEM2iAPkpEAvOTsXWyrjcZ7p37FhVvpgAIqqrp6/SgriDGu8hkrAx6kvi+Vfx0DhljaVtG/bbg1kS78d60pxgh57QjsDxgRu7iC0TBiPUxytwFuo/3wp9JaJwra4e31AjJN12cVsRF+ouOcRyicIsHt3rt4Aco0aBcW5ZKvAWzqTgrOsu4Xe4iZqE+07Lro7M4jabn9vztN/HJ6YIvSNOqTUP4YZyvr3zdEzpKVXHIKj3A+8l3gvfZYtQCXelggIkg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=15b09.5ff5ee47.k2101; bh=njNVtynq8fP6BYsh0k2mnnCZ+NUHwO0Tzv23kMnaMac=; b=QO78erMqshlkhqcXaPRGJdXpBXtDjGT/WUZp77bluI0FmPTUkDxPC6htUoltFk6vyq6kD5To3Glr9bM0Ymr5j5uYmQdHFm7TcQv19cWLlBThozqKzsV4suS19nX5cZL4Zvugaek7ZMslZSkfmCxfJ6tYHgRjlV57QswzSd//XLJnnxhEP8blVmjB4ShhoFohp2DLKheKuIB0Nv9X3/KXSbgS1JKoKZ8KD6pWdMVgF5IBKbcPLks0d5npH8LyjyZfj5VpIeAMXcp4xNHag0vk76tuPkT3SuPxtbWD3PcArdVv25CK6Ilyp/KOEmvxtuFC7pF+Cp5oCJ2PDSjUyXEeAQ== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 06 Jan 2021 17:07:19 -0000 Received: by ary.qy (Postfix, from userid 501) id 9F6335CC249C; Wed, 6 Jan 2021 12:07:17 -0500 (EST) Date: 6 Jan 2021 12:07:17 -0500 Message-Id: <20210106170718.9F6335CC249C@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: vesely@tana.it In-Reply-To: <9f27f29f-2b4e-57ad-3d54-c2a5e04d8c62@tana.it> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 17:07:51 -0000 In article <9f27f29f-2b4e-57ad-3d54-c2a5e04d8c62@tana.it> you write: >This discussion brought up another defect of RFC 5321, methinks. It does not >define a straight line between an MTA and an MDA. ... I think the problem is worse than that. What we're calling an MDA combines two separate things. RFC 5598 calls them the hMDA and rMDA. The hMDA is more or less the thing that takes an incoming message and disposes of it, by storing it in a file or otherwise. Most MTAs have a few simple default hMDA and ways to call out to more complex ones like procmail, maildrop, and Sieve. I don't see any point in trying to rewrite 5321 to try to separate out an hMDA that might be in the MTA and might not. From nobody Thu Jan 7 01:16:24 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01623A0C5D for ; Thu, 7 Jan 2021 01:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 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.262, 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 XtzJBUrs9tLC for ; Thu, 7 Jan 2021 01:16:20 -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 EFEE33A0C55 for ; Thu, 7 Jan 2021 01:16:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1610010976; bh=rz8xsz/1ECkB2PeE343X7D5SOzK1FP2oDV3LYsX8Gew=; l=965; h=To:References:From:Date:In-Reply-To; b=A4u6vAs6AxsFMQJG+YAjBqQzgsjh+XkJGeWpHFEP+38r5WB8qNkrhvRvlyZGvmBwd FDW4QWlDipt22JGRXlAOwIKa7NBWJqrXcCysTPTPKK4AuAgdYfzdAQyB8viCy8kqHY I0iXYRmKui3GOUaEdRil2ytAtIjlgiWZhC19quO6/6S4vzM411xkLBdtCupYV Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC07E.000000005FF6D160.00000F91; Thu, 07 Jan 2021 10:16:16 +0100 To: John Levine , emailcore@ietf.org References: <20210106170718.9F6335CC249C@ary.qy> From: Alessandro Vesely Message-ID: Date: Thu, 7 Jan 2021 10:16:15 +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: <20210106170718.9F6335CC249C@ary.qy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 09:16:22 -0000 On Wed 06/Jan/2021 18:07:17 +0100 John Levine wrote: > In article <9f27f29f-2b4e-57ad-3d54-c2a5e04d8c62@tana.it> you write: >>This discussion brought up another defect of RFC 5321, methinks. It does not >>define a straight line between an MTA and an MDA. ... > > I think the problem is worse than that. What we're calling an MDA > combines two separate things. RFC 5598 calls them the hMDA and rMDA. > > The hMDA is more or less the thing that takes an incoming message and > disposes of it, by storing it in a file or otherwise. Most MTAs have a > few simple default hMDA and ways to call out to more complex ones > like procmail, maildrop, and Sieve. > > I don't see any point in trying to rewrite 5321 to try to separate out > an hMDA that might be in the MTA and might not. Some points can be made without splitting hairs. Defining the concept of MDA only serves to clearly state what is part of SMTP and what is beyond. Best Ale -- From nobody Thu Jan 7 01:25:38 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDAB3A0D04 for ; Thu, 7 Jan 2021 01:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 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.262, 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 YiVIEU8jNWqr for ; Thu, 7 Jan 2021 01:25:36 -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 3B15A3A0CED for ; Thu, 7 Jan 2021 01:25:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1610011534; bh=rGmEt5StlewSV/Qc50hDhR01MoM6iGqv0XjUJpAe0pQ=; l=740; h=To:References:From:Date:In-Reply-To; b=AzW8s0Jllu9IEo2Op/F3dyJ0RHGvvvGFIXiKf7/fUTHx9FNQUtyIqU1sS9mrS0yMv T89WLezUomKp7qYmaMVhqergIEHTZZbW4v4qFEM/5ai0FNpJUfEJcBD09CWAvwrn3s bX4mkeDJg/mkOzdpbDoZF6czXjqgaRaNWKcgBRVYXRC+8MipMSuHFv+BrDR+m Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC07E.000000005FF6D38E.000010AA; Thu, 07 Jan 2021 10:25:34 +0100 To: emailcore@ietf.org References: <8034D30CAC474E52B15C1AC4@PSB> From: Alessandro Vesely Message-ID: <5f8f7894-b736-1f15-2dd4-865f68d6702d@tana.it> Date: Thu, 7 Jan 2021 10:25:32 +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: <8034D30CAC474E52B15C1AC4@PSB> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Navigating 5321bis (and predecessors) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 09:25:38 -0000 On Fri 01/Jan/2021 21:18:28 +0100 John C Klensin wrote: > > Two questions I'd like WG participants to think about: > > (1) How much reorganizing and rewriting do we want to do and what are our > stopping rules? Minimal reorganizing and rewriting, but not less. > (2) Are there ways that we can mitigate the problems with finding things. > [...] Would that be worth doing in terms of finding information or is the > table of contents sufficient? Other ideas? I think an index is useless nowadays, since page numbers are not a univocal reference anymore (they only appear in PDFs and are presumably going to depend on paper formats.) Rather, I'd insert [See also ] notes wherever appropriate. Best Ale -- From nobody Thu Jan 7 08:50:48 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BE13A1287 for ; Thu, 7 Jan 2021 08:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 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.262, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 Sj7Xvk4pEUIs for ; Thu, 7 Jan 2021 08:50:45 -0800 (PST) Received: from quail.birch.relay.mailchannels.net (quail.birch.relay.mailchannels.net [23.83.209.151]) (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 AC2BA3A1387 for ; Thu, 7 Jan 2021 08:50:34 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A6E6F121FCF; Thu, 7 Jan 2021 16:50:33 +0000 (UTC) Received: from nl-srv-smtpout1.hostinger.io (100-96-5-83.trex.outbound.svc.cluster.local [100.96.5.83]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 1397B12289B; Thu, 7 Jan 2021 16:50:31 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout1.hostinger.io ([UNAVAILABLE]. [185.224.136.7]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Thu, 07 Jan 2021 16:50:33 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Snatch-Supply: 678ec7cc3ed65d3d_1610038232781_2425423598 X-MC-Loop-Signature: 1610038232781:4095754755 X-MC-Ingress-Time: 1610038232781 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout1.hostinger.io (smtp.hostinger.com) with ESMTPSA id EAA072B78AA7; Thu, 7 Jan 2021 16:50:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1610038230; bh=lmNGdmS9W6R5B+9fqL5IUUQ+Q5vjoOangBTiLGBBq+A=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=a6+6pYi0mR5YpSRS9NiIWpsqFctqdPn0ZyczfTzeEwxxuqkH+GMywFqxuX24pRfdI NiDOT0+H2cAY7vdVPQWrd0Wa5RVQ95M90jGeqdCJMeLwAwRtnwwl/auC1TUdZCSbMr f16jLCyYSHQyq/bjsPQbCAHElRLnfboVdrChPkbiDYv9bEe07DTni+csYVBcT+aa2F 5GDVcp6M+L3vIALi4GzuNxWtQPQevANH06ErdEeqwGLzMme76y6Y5DHD0Ht4BoSaGK g6zmoQixPFWZDRKCVYajBjazfCRuLex+ZcXExhTW5thacZNP6x8wYy9g8RipEysRF9 2MNkSyUHvM76A== Reply-To: dcrocker@bbiw.net To: John C Klensin Cc: emailcore@ietf.org References: <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> <092D2182F3BEFC786DBAD1CD@PSB> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <6f5950e6-2f38-4982-a87a-36729e7d64da@dcrocker.net> Date: Thu, 7 Jan 2021 08:50:26 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <092D2182F3BEFC786DBAD1CD@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 16:50:46 -0000 On 1/1/2021 2:38 PM, John C Klensin wrote: > That doesn't answer any of your questions above, No, it doesn't. > but it imposes rather severe constraints on the information that > might be available. From your note about Received: header fields, I have no idea what constraints it imposes on Delivered-To. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jan 7 08:56:45 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E603A128A for ; Thu, 7 Jan 2021 08:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 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.262, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 8vHZeqp-T8bD for ; Thu, 7 Jan 2021 08:56:42 -0800 (PST) Received: from cross.elm.relay.mailchannels.net (cross.elm.relay.mailchannels.net [23.83.212.46]) (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 10F2A3A1289 for ; Thu, 7 Jan 2021 08:56:41 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 1F6AB10274B for ; Thu, 7 Jan 2021 16:56:41 +0000 (UTC) Received: from nl-srv-smtpout4.hostinger.io (100-96-27-97.trex.outbound.svc.cluster.local [100.96.27.97]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 8DAC310255E for ; Thu, 7 Jan 2021 16:56:38 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout4.hostinger.io ([UNAVAILABLE]. [145.14.159.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Thu, 07 Jan 2021 16:56:41 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Bottle-Cellar: 680a81405c68a0dd_1610038600985_3094493784 X-MC-Loop-Signature: 1610038600985:3345894047 X-MC-Ingress-Time: 1610038600985 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout4.hostinger.io (smtp.hostinger.com) with ESMTPSA id A558B30AB5FD for ; Thu, 7 Jan 2021 16:56:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1610038597; bh=jf1Lb5w9ubVr/nGzbvH2BynlLxCbyuhdcVcQpftwIuo=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=QPteIH7h6qrfqGXM42wqjKj61sqqiH8XaRIdIaCjFl9QuKO2yPJrQCuOj0r+y64OK r1DAnJosaXFqgfasCbCPLKC/O11bz4Sq2QoZAmsnPhq7ndvfeSgD0XjiPCouFbJUnW uZVCdcc4ZZjPONnybbxhN23ryx1S4HgHSdn1Ig/k8O6gfff4fNK01sorPEQmeYACux TT2R9R1SAdhEF2BQ0DQ+fPud3SKq7Z8it9V5uAJ/rDhY/AkAlDcuCfQ/GIWw0WlVCG VTBJ6Vo0O7dAuoMkqK7E5Jl/zqs1Z8ZLooEzFNYSG1SeSzqkabE4Wf9NrphKnPAJlD 8nW124aCvduaw== Reply-To: dcrocker@bbiw.net To: emailcore@ietf.org References: <20210106170718.9F6335CC249C@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Thu, 7 Jan 2021 08:56:34 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20210106170718.9F6335CC249C@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 16:56:44 -0000 On 1/6/2021 9:07 AM, John Levine wrote: > In article <9f27f29f-2b4e-57ad-3d54-c2a5e04d8c62@tana.it> you write: >> This discussion brought up another defect of RFC 5321, methinks. It does not >> define a straight line between an MTA and an MDA. ... > > I think the problem is worse than that. What we're calling an MDA > combines two separate things. RFC 5598 calls them the hMDA and rMDA. > > The hMDA is more or less the thing that takes an incoming message and > disposes of it, by storing it in a file or otherwise. Most MTAs have a > few simple default hMDA and ways to call out to more complex ones > like procmail, maildrop, and Sieve. > > I don't see any point in trying to rewrite 5321 to try to separate out > an hMDA that might be in the MTA and might not. For the purposes of 5321bis, the hMDA/rMDA distinction is almost certainly overly precise. It distinguishes between two components within a functional unit. What's needed for the bis document is merely to slightly modify the current language to add MDA language and citation, rather than to do any substantial rewriting. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jan 7 13:09:14 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7113A0ED3 for ; Thu, 7 Jan 2021 13:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 qsu0fDAePBe8 for ; Thu, 7 Jan 2021 13:09:12 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A80AF3A0ED2 for ; Thu, 7 Jan 2021 13:09:12 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kxcWt-000JD4-4A; Thu, 07 Jan 2021 16:09:11 -0500 Date: Thu, 07 Jan 2021 16:09:04 -0500 From: John C Klensin To: dcrocker@bbiw.net cc: emailcore@ietf.org Message-ID: In-Reply-To: <6f5950e6-2f38-4982-a87a-36729e7d64da@dcrocker.net> References: <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> <092D2182F3BEFC786DBAD1CD@PSB> <6f5950e6-2f38-4982-a87a-36729e7d64da@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 21:09:14 -0000 --On Thursday, January 7, 2021 08:50 -0800 Dave Crocker wrote: > On 1/1/2021 2:38 PM, John C Klensin wrote: >> That doesn't answer any of your questions above, > > No, it doesn't. > > >> but it imposes rather severe constraints on the information >> that might be available. > > > From your note about Received: header fields, I have no idea > what > constraints it imposes on Delivered-To. Without seeing a more precise description of the actions and semantics proposed for Delivered-To, preferably in the form of an I-D, I don't know if it imposes any constraints or not. More generally, I got involved in this thread for two reasons: (1) It was proposed that Delivered-to: be specified as part of 5321bis, an idea that I think has been rather thoroughly rejected (IIR, thanks, in part, to your input). (2) It was suggested at one point that Delivered-to: and Envelope-to: were synonyms for the same function, field syntax, and semantics. I wanted to clarify whether that was correct; it seems rather clear at this point that it was not. Given those two issues, I question where further discussion of Delivered-to: (or, for that matter, Envelope-to:) are appropriate for this list. Certainly they are out of scope for the WG at present. I assume they might come back into scope if there are one or more published specifications and the WG starts discussing the A/S, but we don't seem to be getting to that point very quickly and I, at least, would like to see discussions on this mailing list focused on 5321bis and 5322bis with a minimum of other distractions. That is, of course, just a personal preference and YMMD. john From nobody Thu Jan 7 13:20:32 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618203A0EFB for ; Thu, 7 Jan 2021 13:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9GZy8wpt_9My for ; Thu, 7 Jan 2021 13:20:30 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EFFB3A0EFA for ; Thu, 7 Jan 2021 13:20:30 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kxchm-000JG9-9I; Thu, 07 Jan 2021 16:20:26 -0500 Date: Thu, 07 Jan 2021 16:20:19 -0500 From: John C Klensin To: Alessandro Vesely , John Levine , emailcore@ietf.org Message-ID: <9AE5B08FCF664B8F9A7721C2@PSB> In-Reply-To: References: <20210106170718.9F6335CC249C@ary.qy> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Emailcore] MDAs (was: Re: Delivered-To issues) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 21:20:31 -0000 (note subject line change and see "p.s." at end) --On Thursday, January 7, 2021 10:16 +0100 Alessandro Vesely wrote: > On Wed 06/Jan/2021 18:07:17 +0100 John Levine wrote: >> In article <9f27f29f-2b4e-57ad-3d54-c2a5e04d8c62@tana.it> you >> write: >>> This discussion brought up another defect of RFC 5321, >>> methinks. It does not define a straight line between an >>> MTA and an MDA. ... >> >> I think the problem is worse than that. What we're calling an >> MDA combines two separate things. RFC 5598 calls them the >> hMDA and rMDA. >> >> The hMDA is more or less the thing that takes an incoming >> message and disposes of it, by storing it in a file or >> otherwise. Most MTAs have a few simple default hMDA and ways >> to call out to more complex ones like procmail, maildrop, and >> Sieve. >> >> I don't see any point in trying to rewrite 5321 to try to >> separate out an hMDA that might be in the MTA and might not. > > > Some points can be made without splitting hairs. Defining the > concept of MDA only serves to clearly state what is part of > SMTP and what is beyond. But, AFAICT, that brings things full circle to John L's point. If there are some flavors of MDA that are really part of the MTA function and some flavors that are not, then a crisp definition of MDA that would fit well into 5321bis may not be possible without splitting exactly those hairs. I'd be happy to be wrong about this. However, the only way I can think of to would figure what can practically be done within the text of 5321bis and constraints on it would be to see proposed text, one that, as needed, references other standards track documents for definitions. I await such text. best, john p.s. I have changed the subject line because this is really about MDAs, their definition, and their relationship to 5321bis. Certainly it would be desirable for a description of Delivered-To: (or Envelope-To:) in some other spec to reference such text if it appeared in 5321bis but, as I suggested in a note posted a few minutes ago, I believe that those (or other) new headers are out of scope for 5321bis and the WG and do not intend to spend more time reading that thread unless the WG Co-chairs direct otherwise. > > > Best > Ale > -- From nobody Thu Jan 7 13:33:42 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E4D3A00C4 for ; Thu, 7 Jan 2021 13:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 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.262, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 FLMIrZzaRZc5 for ; Thu, 7 Jan 2021 13:33:38 -0800 (PST) Received: from camel.birch.relay.mailchannels.net (camel.birch.relay.mailchannels.net [23.83.209.29]) (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 F33743A005D for ; Thu, 7 Jan 2021 13:33:37 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C54E1543B39; Thu, 7 Jan 2021 21:33:36 +0000 (UTC) Received: from nl-srv-smtpout2.hostinger.io (100-96-87-21.trex.outbound.svc.cluster.local [100.96.87.21]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id C46E9542420; Thu, 7 Jan 2021 21:33:30 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout2.hostinger.io ([UNAVAILABLE]. [145.14.159.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Thu, 07 Jan 2021 21:33:36 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Arch-Coil: 338286ba30e373a1_1610055211802_2340869807 X-MC-Loop-Signature: 1610055211802:3210555111 X-MC-Ingress-Time: 1610055211801 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout2.hostinger.io (smtp.hostinger.com) with ESMTPSA id 84F5A3074998; Thu, 7 Jan 2021 21:33:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1610055209; bh=Q9iUMuiIjnfcBvRu+NXWBzHTRgYrFRtJ90mvLDYZvJw=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=qBJUXC3K0amhwQVtPDdH48hcROBDx6EzuoKNf1XEfvjE/nSJmaV1bXT1gUWwtxdV1 2o61iaQulpMJk9tzCjtSawEFqPdaBrTc/+T39KzhwpZD8m1BgwrhFh8nm/IOG1eRYm DTtazIrChJcayvh2TK0YtFgiNMhfRbNLeqq79vKYuNCmUhKKW1PdmPPGnMkplWRaQz l0ac3jBLYysyLPS0dNWQmijHZ1qAWr6UXv3toNQ1wkCI5g2jc8l4/fA6L6La+RJfIA 5Z8kZAY9BeS2BRQP4hM6+a1sqDL1I8LhVGX1Xd/yBqYVvJXOY0BAGi+i8EJ9yPsYM1 iycKylqagP3dw== Reply-To: dcrocker@bbiw.net To: John C Klensin , emailcore@ietf.org References: <20210106170718.9F6335CC249C@ary.qy> <9AE5B08FCF664B8F9A7721C2@PSB> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <16ca8301-2a05-90b3-38e9-82253c70f4e2@dcrocker.net> Date: Thu, 7 Jan 2021 13:33:25 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <9AE5B08FCF664B8F9A7721C2@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] MDAs (was: Re: Delivered-To issues) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 21:33:41 -0000 On 1/7/2021 1:20 PM, John C Klensin wrote: > --On Thursday, January 7, 2021 10:16 +0100 Alessandro Vesely > wrote: >> Some points can be made without splitting hairs. Defining the >> concept of MDA only serves to clearly state what is part of >> SMTP and what is beyond. > > But, AFAICT, that brings things full circle to John L's point. > If there are some flavors of MDA that are really part of the MTA the expresses a conditional that is a non-sequitor. MTAs are not MDAs. MDAs are not MTAs. There are no architectural 'flavors' to this distinction. > function and some flavors that are not, then a crisp definition > of MDA that would fit well into 5321bis may not be possible > without splitting exactly those hairs. Why do you want to create redundant -- or, worse, divergent -- text, given that the IETF spent 5 years formulating an architecture document that already has it: > 4.3.3. Mail Delivery Agent (MDA) > > A transfer of responsibility from the MHS to a Recipient's > environment (mailbox) is called "delivery". In the architecture, as > depicted in Figure 5, delivery takes place within a Mail Delivery > Agent (MDA) and is shown as the (D) transition from the MHS-oriented > MDA component (hMDA) to the Recipient-oriented MDA component (rMDA). ... If you have specific concerns about the consensus-based text in the document, please state them. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jan 7 13:37:26 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BC23A0F0C for ; Thu, 7 Jan 2021 13:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=m3W5HAyE; dkim=pass (2048-bit key) header.d=taugh.com header.b=Yi0SGv6Q 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 tTuyQAwwEGsl for ; Thu, 7 Jan 2021 13:37:22 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 E695F3A0DE2 for ; Thu, 7 Jan 2021 13:36:54 -0800 (PST) Received: (qmail 89645 invoked from network); 7 Jan 2021 21:36:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=15e28.5ff77ef5.k2101; i=johnl-iecc.com@submit.iecc.com; bh=Qadtyf1yEyd+BIwTh2+djWec2aUrCkN09mdA+ckj5Ec=; b=m3W5HAyEsUOeusPU9GL3LV9ActjJmCtO9eRcGT/1dmt0XkXokrutKo+K57FS4T7Mxgm98huWscgtu49UdjWbgriOaEnUhWJ9FaYaoxL1Wkr9q1/8jftjWpv8AetImmvpQ4IsQhtpxt2lsVKs4BW2m4peRldvykjNsEmuCvjdnx+fEmdBRZf1spM/+DBCLoHlYv15/6+3T2qflt+ZE4IPbiFPkT0WlkGYfvwXZL6lppuLFzQxHJ/dK8Tn2qYopoH1tlLfQFJGOWIbtgrCCC0tD28FvK0GWpdErwxHnRuv2kOrfIDBYHHgmPWbAfvg/YYTylxbNyrPRSrmwmTH1UBIlg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=15e28.5ff77ef5.k2101; olt=johnl-iecc.com@submit.iecc.com; bh=Qadtyf1yEyd+BIwTh2+djWec2aUrCkN09mdA+ckj5Ec=; b=Yi0SGv6QptBAOp2w6B1o4cd/FbbnAArsH8Y+a1Dhmm+bLRKcvmT/N96C22juuIUVgsmITZpym20dmib3gT12CDtfoZLHQu6rXS5gKN0FThv8IEGKVHw3QmwK/ShQeyEkSXgmqab0vQT44jbZXIUZgB4GBP6SL5jPx+eW8B/HkP+LZ9PM0nUpT41jLopYG7uaTaass5KQbJinsUJW7ng7YF4VjC+WvIEyw4ojP/X7AUMgjYJL1qBYn6t81iqwt9soG2BLEk05x8eJSYC5RKFLul5Z53Uzey4uorMXY4vWoY/kRnFS+s/O+f7O2RTS6jQPJxxlfH/uR0zrYRYB1CAAfg== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 07 Jan 2021 21:36:53 -0000 Date: 7 Jan 2021 16:36:53 -0500 Message-ID: From: "John R Levine" To: "John C Klensin" , emailcore@ietf.org In-Reply-To: <9AE5B08FCF664B8F9A7721C2@PSB> References: <20210106170718.9F6335CC249C@ary.qy> <9AE5B08FCF664B8F9A7721C2@PSB> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] MDAs (was: Re: Delivered-To issues) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 21:37:25 -0000 On Thu, 7 Jan 2021, John C Klensin wrote: > But, AFAICT, that brings things full circle to John L's point. > If there are some flavors of MDA that are really part of the MTA > function and some flavors that are not, then a crisp definition > of MDA that would fit well into 5321bis may not be possible > without splitting exactly those hairs. I took another look and I don't see anything to to change. It says to add Return-Path at final delivery when "the message has left the SMTP environment." The details of when that happens are quite specific to different implementations. For example, on some systems, when one address is aliased to another it just substitutes the envelope address within the MTA, in others (mine for example) it's delivered to a stub that reinjects the message, adding and then stripping the Return-Path. I am not aware of the current language causing any trouble for implementers so I really think we should leave it alone. > Certainly it would be desirable for a description of > Delivered-To: (or Envelope-To:) in some other spec to reference > such text if it appeared in 5321bis but, ... It is my impression that we agree that if it goes anywhere it'll be a separate draft. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Jan 7 13:53:42 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CEE3A0332 for ; Thu, 7 Jan 2021 13:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 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.262, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 YnOoW4TFLghl for ; Thu, 7 Jan 2021 13:53:39 -0800 (PST) Received: from buffalo.birch.relay.mailchannels.net (buffalo.birch.relay.mailchannels.net [23.83.209.24]) (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 1584E3A033F for ; Thu, 7 Jan 2021 13:53:38 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 15E935413C4; Thu, 7 Jan 2021 21:53:38 +0000 (UTC) Received: from nl-srv-smtpout4.hostinger.io (100-98-64-116.trex.outbound.svc.cluster.local [100.98.64.116]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id DE3515435F9; Thu, 7 Jan 2021 21:53:36 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout4.hostinger.io ([UNAVAILABLE]. [145.14.159.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Thu, 07 Jan 2021 21:53:37 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Coil-Arch: 618392820939fcb8_1610056417591_2941190456 X-MC-Loop-Signature: 1610056417591:3258848432 X-MC-Ingress-Time: 1610056417591 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout4.hostinger.io (smtp.hostinger.com) with ESMTPSA id A1D3930742D6; Thu, 7 Jan 2021 21:53:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1610056415; bh=uEvRVO0MBjxSZM2spj+FPjlSXZ3UGHsjUem39bBO8B0=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=ZVWqzAioW1dTIWL0DDx4EWPLzw6gowzfP7RVpgK0HvlNfcwW3v9/WpJLcQZ5d2j29 V6xEK5GO/Ln3pB4UaioMWOqjDswEPjzF9pve/WGldrpCAra/5Kj6qYLyfjFajfO55F r5GJpRyKY+slbaeNZiVzsTd7yWNY47N1eM99egJk1Yf4UGKsdaZrhhO0dz2b24e9N9 wakBRBQV300RakTzFsX7K+a/V0G8ny4aZ2oMZqCgb7gd9gt5WMkp0RKDlZFL5ivEXk 0K+ugRZUkpbsakvGXDvrCMT67A8//oh6+Ci8xR4a5cog6zwxFtJaaaGCviQUJuGzHE FwFZkwEdFyIwA== Reply-To: dcrocker@bbiw.net To: John R Levine , emailcore@ietf.org References: <20210106170718.9F6335CC249C@ary.qy> <9AE5B08FCF664B8F9A7721C2@PSB> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <0cd40aab-0d6f-a1df-014a-776f15ac8e78@dcrocker.net> Date: Thu, 7 Jan 2021 13:53:30 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] MDAs (was: Re: Delivered-To issues) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 21:53:41 -0000 On 1/7/2021 1:36 PM, John R Levine wrote: > For example, on some systems, when one address is aliased to another it > just substitutes the envelope address within the MTA, Except that that is not 'within' the MTA. It's within the MDA, in architectural terms. Changing a destination address specified by the author takes the message outside of message transport because it is a recipient-based action, not an author-based one. And it isn't merely a 'routing' matter, which is the kind of redirection the the MHS does. The import of treating aliasing as an MTA function is that any MTA can choose to do it. Aliasing is then defined as a standard MTA function. Aliasing is a streamlined version of mailing list behavior. It is commonly implemented in MTA-related code because that's simpler than running a separate mailing list server. That's an implementation point, not an architectural one. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jan 7 14:34:41 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE19A3A0AFA for ; Thu, 7 Jan 2021 14:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 PV8hFpTEM-ov for ; Thu, 7 Jan 2021 14:34:37 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4693A0AE6 for ; Thu, 7 Jan 2021 14:34:37 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kxdrY-000Je6-I4; Thu, 07 Jan 2021 17:34:36 -0500 Date: Thu, 07 Jan 2021 17:34:30 -0500 From: John C Klensin To: John R Levine cc: emailcore@ietf.org Message-ID: <0DDE808B7268DCBB1B12C316@PSB> In-Reply-To: References: <20210106170718.9F6335CC249C@ary.qy> <9AE5B08FCF664B8F9A7721C2@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] MDAs (was: Re: Delivered-To issues) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 22:34:39 -0000 --On Thursday, January 7, 2021 16:36 -0500 John R Levine wrote: > On Thu, 7 Jan 2021, John C Klensin wrote: >> But, AFAICT, that brings things full circle to John L's point. >> If there are some flavors of MDA that are really part of the >> MTA function and some flavors that are not, then a crisp >> definition of MDA that would fit well into 5321bis may not be >> possible without splitting exactly those hairs. > > I took another look and I don't see anything to to change. It > says to add Return-Path at final delivery when "the message > has left the SMTP environment." > > The details of when that happens are quite specific to > different implementations. For example, on some systems, when > one address is aliased to another it just substitutes the > envelope address within the MTA, in others (mine for example) > it's delivered to a stub that reinjects the message, adding > and then stripping the Return-Path. I am not aware of the > current language causing any trouble for implementers so I > really think we should leave it alone. Exactly. john From nobody Thu Jan 7 15:54:29 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4826A3A0E3A for ; Thu, 7 Jan 2021 15:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 S8QHiBjljI1t for ; Thu, 7 Jan 2021 15:54:26 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 2E9173A0E31 for ; Thu, 7 Jan 2021 15:54:26 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RU3P9JUH1S00CYJI@mauve.mrochek.com> for emailcore@ietf.org; Thu, 7 Jan 2021 15:49:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1610063362; bh=ET+PxniB4eVqxkadIdPki+PzY+aGHHxTERtrGv97AQo=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=rGDyWLehk3sxnd8Ae7JSbM9K9WA6YBelggqYjrrqWBN5sXycM+cO/047Mpb7kxUhI RU0XY4+q2lHvDXSBp6slfm3nSDZBQWimBQnkYdzA1FebuDomAtjQ2qrjwL0r0yJ4AR 5g8jGNjxyFVzJIsUHDh/mTvhc/hQM4hfpR9G1v08= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTUUND7D1S004QVR@mauve.mrochek.com>; Thu, 7 Jan 2021 15:49:20 -0800 (PST) Cc: John C Klensin , emailcore@ietf.org Message-id: <01RU3P9I4R8W004QVR@mauve.mrochek.com> Date: Thu, 07 Jan 2021 15:31:28 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 07 Jan 2021 16:36:53 -0500" References: <20210106170718.9F6335CC249C@ary.qy> <9AE5B08FCF664B8F9A7721C2@PSB> To: John R Levine Archived-At: Subject: Re: [Emailcore] MDAs (was: Re: Delivered-To issues) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 23:54:27 -0000 > On Thu, 7 Jan 2021, John C Klensin wrote: > > But, AFAICT, that brings things full circle to John L's point. > > If there are some flavors of MDA that are really part of the MTA > > function and some flavors that are not, then a crisp definition > > of MDA that would fit well into 5321bis may not be possible > > without splitting exactly those hairs. > I took another look and I don't see anything to to change. It says to add > Return-Path at final delivery when "the message has left the SMTP > environment." Sounds correct to me. > The details of when that happens are quite specific to different > implementations. For example, on some systems, when one address is > aliased to another it just substitutes the envelope address within the > MTA, in others (mine for example) it's delivered to a stub that reinjects > the message, adding and then stripping the Return-Path. I am not aware of > the current language causing any trouble for implementers so I really > think we should leave it alone. That may be true for return-path, but what about success DSNs? You may be able to undo the insertion of a return-path, but I doubt very much that anyone implements NOTARY support using a "undo the DSN you just sent" mechanism to do it. There's also the relatied issue that AKAIK aliases operations don't reenter the MTA through a submission operation. And this gets to my issues with intertwining aliasing with delivery, and the suggestion that we can just drop the discussion of aliases versus mailing lists. If we do this then delivery becomes a meaningless abstraction with no substance. And while I agree with Dave that we must not let implementation details define our model, I get very nervous when there's nothing whatsoever in my implementation - or any of several other implementations I'm familiar with - that corresponds to a major delineation in the model. > > Certainly it would be desirable for a description of > > Delivered-To: (or Envelope-To:) in some other spec to reference > > such text if it appeared in 5321bis but, ... > It is my impression that we agree that if it goes anywhere it'll be a > separate draft. Yep. And while I don't really mind discussing it on this list, if it's getting confused with the revision or delaying it the delivered-to discussion needs to be moved elsewhere. Ned From nobody Thu Jan 7 19:01:11 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDBA3A0115 for ; Thu, 7 Jan 2021 19:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 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.262, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 r8NtOv7sCTh5 for ; Thu, 7 Jan 2021 19:01:08 -0800 (PST) Received: from hedgehog.birch.relay.mailchannels.net (hedgehog.birch.relay.mailchannels.net [23.83.209.81]) (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 593D43A0100 for ; Thu, 7 Jan 2021 19:01:07 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 96C20124760; Fri, 8 Jan 2021 03:01:06 +0000 (UTC) Received: from nl-srv-smtpout2.hostinger.io (100-98-64-116.trex.outbound.svc.cluster.local [100.98.64.116]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 67081124076; Fri, 8 Jan 2021 03:01:04 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout2.hostinger.io ([UNAVAILABLE]. [145.14.159.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Fri, 08 Jan 2021 03:01:06 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Shelf-Wide-Eyed: 40c77d3e6ae69586_1610074865689_3329229057 X-MC-Loop-Signature: 1610074865688:2809054771 X-MC-Ingress-Time: 1610074865688 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout2.hostinger.io (smtp.hostinger.com) with ESMTPSA id 4C95F333EFAF; Fri, 8 Jan 2021 03:01:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1610074862; bh=YpM8NdlCfpiaEe32HbQKsKENiMNnsnvshk8EoW0Qspg=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=F+m1Sjq8QMclJXdVMce6o43DucI291OC4Q41etScp9k94GqNHkoE8mC3h9jYDQlzL ELNsZYbJ7gLOxUh3FQ/9cZakuNncHPC0gzAymdkfy9ekd+I//XmhOWl1gO6/UpWxgI TwsSpQtb8/plwHjhOabft2QnjGY0XMqE6ZXKqVUCOC81Ff64LAASAiR87MYLQoBEws JDuv4br76/gDrb978BXJvaaDJfK3a1rLpvCrlGE/JsxhLWBG8NQYGIMsts2f/jUsPg jfqEYdY8PaGUg62CpUTega9r7BoFnJDGXFE9NAXz80n+lYJMh7nv8ZNlVZhm6QB8mu pt3ULJ4bWTipA== Reply-To: dcrocker@bbiw.net To: Ned Freed Cc: emailcore@ietf.org References: <20210106170718.9F6335CC249C@ary.qy> <9AE5B08FCF664B8F9A7721C2@PSB> <01RU3P9I4R8W004QVR@mauve.mrochek.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <44b4b60e-58ce-7ac1-66d3-26c59722722b@dcrocker.net> Date: Thu, 7 Jan 2021 19:00:58 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <01RU3P9I4R8W004QVR@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] MDAs (was: Re: Delivered-To issues) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 03:01:10 -0000 On 1/7/2021 3:31 PM, Ned Freed wrote: > There's also the relatied issue that AKAIK aliases operations don't > reenter the > MTA through a submission operation. > And this gets to my issues with intertwining aliasing with delivery, and > the > suggestion that we can just drop the discussion of aliases versus mailing > lists. > > If we do this then delivery becomes a meaningless abstraction with > no substance. And while I agree with Dave that we must not let > implementation details define our model, I get very nervous when > there's nothing whatsoever in my implementation - or any of several > other implementations I'm familiar with - that corresponds to a major > delineation in the model. Consider: 2.3.11. Mailbox and Address ... standard mailbox naming convention is defined to be "local-part@domain"; contemporary usage permits a much broader set of applications than simple "user names". Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address. Interpretation of Local-part is inappropriate for an MTA. Having the Local-part be globally opaque is an important feature of Internet Mail. (It has enabled quite a bit of easy extensibility of the decades.) That makes interpretation of local-part an MDA function. While, yes, aliasing typically goes through completely different code paths than normal 'delivery' and 'submission', we should focus, instead, on scope and responsibility, rather than code. Either aliasing is in (or after) MDA functionality, or we need to define aliasing as an integrated part of MTA functionality, which means local-part is /not/ opaque. Or we need to define multiple types of MTAs. But I thought that was the point behind defining MSA and MDA architectural components. >> > Certainly it would be desirable for a description of >> > Delivered-To: (or Envelope-To:) in some other spec to reference >> > such text if it appeared in 5321bis but, ... > >> It is my impression that we agree that if it goes anywhere it'll be a >> separate draft. > > Yep. And while I don't really mind discussing it on this list, if > it's getting confused with the revision or delaying it the > delivered-to discussion needs to be moved elsewhere. Where should it be discussed? I understand the charter issue, but really, this is the currently-active venue for email focus in the IETF. (And with my typical naivety, or at least optimism, I'm hoping that dealing with Deliver-To goes quickly. I expect to circulate an I-D next week. Maybe this weekend.) -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jan 8 09:01:01 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E56F3A1153 for ; Fri, 8 Jan 2021 09:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 y4v-I2v2utlR for ; Fri, 8 Jan 2021 09:00:55 -0800 (PST) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 BE99D3A1147 for ; Fri, 8 Jan 2021 09:00:55 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RU4P483EHS00C5KC@mauve.mrochek.com> for emailcore@ietf.org; Fri, 8 Jan 2021 08:55:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1610124952; bh=kSwQBehupqPeNZNKpSPGvaP7cQMx7ybnS14P9PkWy5E=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=mqsQebhD/NvkA/ZchWc5hxBiPIAvkZ9eGMvNfjkks57A0Dm+rWqMk/AjipCdPUomm bFMo97q6N0ivSQoYvfuCKXtsoIXb7cuiO5iHdgRQVJNZizTrJYxaBf3yMuw0ficWZe uKhlltxZOzfFnVWOGLvx6SnMGhGrPsSL4ZE0dtkw= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTUUND7D1S004QVR@mauve.mrochek.com>; Fri, 8 Jan 2021 08:55:49 -0800 (PST) Cc: Ned Freed , emailcore@ietf.org Message-id: <01RU4P45I2YI004QVR@mauve.mrochek.com> Date: Fri, 08 Jan 2021 07:30:35 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 07 Jan 2021 19:00:58 -0800" <44b4b60e-58ce-7ac1-66d3-26c59722722b@dcrocker.net> References: <20210106170718.9F6335CC249C@ary.qy> <9AE5B08FCF664B8F9A7721C2@PSB> <01RU3P9I4R8W004QVR@mauve.mrochek.com> <44b4b60e-58ce-7ac1-66d3-26c59722722b@dcrocker.net> To: Dave Crocker Archived-At: Subject: Re: [Emailcore] MDAs (was: Re: Delivered-To issues) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 17:00:57 -0000 > On 1/7/2021 3:31 PM, Ned Freed wrote: > > There's also the relatied issue that AKAIK aliases operations don't > > reenter the > > MTA through a submission operation. > > And this gets to my issues with intertwining aliasing with delivery, and > > the > > suggestion that we can just drop the discussion of aliases versus mailing > > lists. > > > > If we do this then delivery becomes a meaningless abstraction with > > no substance. And while I agree with Dave that we must not let > > implementation details define our model, I get very nervous when > > there's nothing whatsoever in my implementation - or any of several > > other implementations I'm familiar with - that corresponds to a major > > delineation in the model. > Consider: > 2.3.11. Mailbox and Address > ... > standard mailbox naming convention is defined to be > "local-part@domain"; contemporary usage permits a much broader set of > applications than simple "user names". Consequently, and due to a > long history of problems when intermediate hosts have attempted to > optimize transport by modifying them, the local-part MUST be > interpreted and assigned semantics only by the host specified in the > domain part of the address. There's just one problem with this text: This isn't true. It has never been true, and no amount of repetition, compliance language, or anything else will make it true. The obvious example, which I have pointed out many times, is when mailing lists have to decide whether or not a subscribe/unsubscribe request is a match to an address on the list. This means choosing whether or not other people's local-parts are case-sensitive. (There's also the issue of things like unnecessary quoting, which in the interests of my own sanity I'm going to ignore.) The decision is almost always that they aren't case-sensitive, because if you assume they are, the doofus who keeps losing track of his subscriptions and likes writing his or her name in various combinations of mixed caps starts complaining about getting multiple copies. But either way this is absolutely a case where the list is interpreting the local-part. Similar tests for address equality are made by filtering systems for various reasons. These tests may go so far as to assume specific formats for subaddressing. UTF-8 local-parts make this even messier. Right now I expect that i;ascii-casemap is being used, but if UTF-8 local-parts ever do see significant deployment worldwide, this may change, because I expect that people aren't any more consistent about the case of the accented characters they use than they are with the unaccented ones. Another example: Secondary MXes may use forward-caching schemes. In some cases they make educated guesses about the validity of local-parts of the domains they forward to. Sometimes they do this with knowledge about the actual host. And sometimes they just do it. More generally, delegation of authority to interpret the local-part of address happens pretty regularly. Customer requests to implement partial authority over local-parts bother me, but... the customer is always yada yada yada. And then there's SRS, which if you do the full bit involves interpreting the first four characters of a local-part specially if they happen to be "SRS0" or "SRS1". Of course it's tempting to yell, "Bad Puppy!" and get out the rolled-up newspaper to deal with some of these, but when Office 365 implements SRS... good luck. > Interpretation of Local-part is inappropriate for an MTA. Having the > Local-part be globally opaque is an important feature of Internet Mail. > (It has enabled quite a bit of easy extensibility of the decades.) The actual requirement that has been successful in practice is "interpret only when absolutely necessary, and only with consent". (Joining a mailing list means consenting to that list's rules as to how it interprets your address.) And yes, this has worked very well. But it's not the hard-and-fast rule we've documented. > That makes interpretation of local-part an MDA function. Well, if you want to define the function of an MDA and thus "delivery" as "interpret the local part and nothing else", and leave "final delivery" for adding return-path, generating DSNs, etc., that's close to being workable. You still have the problem that there needs to be a path from the MDA back to the MTA that doesn't involve the MSA or message submission, but that's doable. I don't think that's how most people interpret the word "delivery" though. > While, yes, aliasing typically goes through completely different code > paths than normal 'delivery' and 'submission', we should focus, instead, > on scope and responsibility, rather than code. FWIW it doesn't, at least not in our server. And while it's coding thing, I think some mention needs to be made of milter, if only in passing since I don't think there's anything we can do about it. Most MTAs have a well defined and well structured way of determine address locality, one that matches up to the email architecture. And since this tends to either be fully hardcoded or implemented in a base configuration that's rarely changed, it's a significant contributer to why email hasn't had that many problems with people messing around with addresses when they shouldn't. Milter changes this. Since it operates at the MTA level, and includes add and delete recipient that don't respect address ownership, it lets any yahoo who is capable of filling in the blanks in a generic milter server template do really bad things. Again, I don't think there's anything we can do about it other than to continue to hold the line on not mangling other people's addresses. But whether this and other threats justifies ignoring the complex cases in favor of delivering a simple message (sic) is the part of the decision we need to make here. > Either aliasing is in (or after) MDA functionality, or we need to define > aliasing as an integrated part of MTA functionality, which means > local-part is /not/ opaque. Translucent, maybe? > Or we need to define multiple types of MTAs. But I thought that was the > point behind defining MSA and MDA architectural components. I see the main point behind the MDA and MSA as being the places where final delivery and submission occur. This approach is also far from perfect: Among other things it makes a mess of the placement of sieve, since the sieve specification is clear that sieve can happen anywhere from right after the determination an address is local to long after final delivery. (And subsequent specifications have extended sieve to operate on message motions inside the mesage store, including messages which may never have touched the transport infrastructure, which while useful is something of an architectural disaster.) But we already have to accept that the block diagrams don't align with implementations; we may also have to accept that they oversimplify actual flows between components. (We have multiple customers who use MTAs queues to implement a backup facility for their message store. I wish I was making this up, but I'm not.) Ned From nobody Fri Jan 8 10:21:19 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6081C3A0AB9 for ; Fri, 8 Jan 2021 10:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 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.262, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 0t3UUyRYSz77 for ; Fri, 8 Jan 2021 10:21:15 -0800 (PST) Received: from aye.elm.relay.mailchannels.net (aye.elm.relay.mailchannels.net [23.83.212.6]) (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 4AE053A0943 for ; Fri, 8 Jan 2021 10:21:14 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id AEAEB482D80; Fri, 8 Jan 2021 18:21:13 +0000 (UTC) Received: from nl-srv-smtpout1.hostinger.io (100-100-138-63.trex.outbound.svc.cluster.local [100.100.138.63]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id DDF24482F5C; Fri, 8 Jan 2021 18:21:10 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout1.hostinger.io ([UNAVAILABLE]. [185.224.136.7]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Fri, 08 Jan 2021 18:21:13 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Spicy-Eyes: 2c5d0fb35eafafa5_1610130073499_3995224011 X-MC-Loop-Signature: 1610130073499:2110272407 X-MC-Ingress-Time: 1610130073498 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout1.hostinger.io (smtp.hostinger.com) with ESMTPSA id 073142029812; Fri, 8 Jan 2021 18:21:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1610130069; bh=ybiwJpHTpRUXhSFplLrRdSf7I9oB5AG0vWiwk0jkHE0=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=ADPCrZkwyT+ZgercThw5B3/wI8Pg/U3RU2nCKXmSBzN4Mv+gdLarrq3+k68GHzTVf lbbsjXqT6pxsP/+w5Lr8SRoGF6iu2wc5cN5H19nYraj0kd2R4rAitKT8lHtpI1terS 9GMbibXfaSUnEfb2c2w1pVYPy4ZKggGi8deUzFncSW+fG8hKvhg1w60gGghXJlIizw I3hARSbE89z6Bf3KjsHk6qVap6nkYHTLHNS/Ri1am8/FdGXGg+enTf00T6Riw35gid xHdnAPF1BsQpuo1rxZhBl6IKzPKZVMT3cQzFwU1nlcB3QabAEOLaI4CxzLc9J8A20w wHe/EdGSSjzZg== Reply-To: dcrocker@bbiw.net To: Ned Freed Cc: emailcore@ietf.org References: <20210106170718.9F6335CC249C@ary.qy> <9AE5B08FCF664B8F9A7721C2@PSB> <01RU3P9I4R8W004QVR@mauve.mrochek.com> <44b4b60e-58ce-7ac1-66d3-26c59722722b@dcrocker.net> <01RU4P45I2YI004QVR@mauve.mrochek.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Fri, 8 Jan 2021 10:21:05 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <01RU4P45I2YI004QVR@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] MDAs (was: Re: Delivered-To issues) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 18:21:17 -0000 On 1/8/2021 7:30 AM, Ned Freed wrote: > There's just one problem with this text: This isn't true. It has never been > true, and no amount of repetition, compliance language, or anything else > will > make it true. > > The obvious example, which I have pointed out many times, is when > mailing lists > have to decide whether or not a subscribe/unsubscribe request is a match > to an > address on the list. Except that a mailing list operates /after/ delivery. (And before re-posting.) I specify the address emailcore@ietf.org. My message travels to an ietf.org email server and it resolves emailcore, handing the message over to the mailing list system.(*) The message has been delivered to the address I specified. What the MLM does after that is secondary, for the purposes of this thread. d/ (*) And the 'resolves' and 'handing over' activities are by an MDA. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jan 8 12:20:21 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DD13A1286 for ; Fri, 8 Jan 2021 12:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 QcCxw8xGX234 for ; Fri, 8 Jan 2021 12:20:18 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 041AF3A1285 for ; Fri, 8 Jan 2021 12:20:17 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RU4W3DWT2O00E4ZA@mauve.mrochek.com> for emailcore@ietf.org; Fri, 8 Jan 2021 12:15:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1610136914; bh=4aoP0tcvi2C/5+1cu/B6jPVhzGB2/dWOv6TiG/p+Tu8=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=NAQBTkMPIBf2e3BTxF7AWOoJm6ciby680KyR5qgwxL0qaqm2yjqpdRhHHCvwF3zbj PLRRBUa1jJ8Q+OlRuvgP3Diguwl4NfQM7YLi/CpDHaZ4kDlH1n46ofeywR6ZUUiIbl DxvPQ3rmVCpr76MfewcMQ+AaiFqKn4WupAbsKz2Q= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTUUND7D1S004QVR@mauve.mrochek.com>; Fri, 8 Jan 2021 12:15:11 -0800 (PST) Cc: Ned Freed , emailcore@ietf.org Message-id: <01RU4W3B8POW004QVR@mauve.mrochek.com> Date: Fri, 08 Jan 2021 11:56:16 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 08 Jan 2021 10:21:05 -0800" References: <20210106170718.9F6335CC249C@ary.qy> <9AE5B08FCF664B8F9A7721C2@PSB> <01RU3P9I4R8W004QVR@mauve.mrochek.com> <44b4b60e-58ce-7ac1-66d3-26c59722722b@dcrocker.net> <01RU4P45I2YI004QVR@mauve.mrochek.com> To: Dave Crocker Archived-At: Subject: Re: [Emailcore] MDAs (was: Re: Delivered-To issues) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 20:20:19 -0000 > On 1/8/2021 7:30 AM, Ned Freed wrote: > > There's just one problem with this text: This isn't true. It has never been > > true, and no amount of repetition, compliance language, or anything else > > will > > make it true. > > > > The obvious example, which I have pointed out many times, is when > > mailing lists > > have to decide whether or not a subscribe/unsubscribe request is a match > > to an > > address on the list. > Except that a mailing list operates /after/ delivery. (And before > re-posting.) First of all, I was not talking about the list itself, but rather the tools that maintain it. There's also the case where the list does similar comparisons in order to implement restrictions like "you have to be on the list to post" - and these often implement some understanding of subaddress semantics - and yes, those do operate after delivery, but this is all beside the point. The fact is that mailing lists and mailing list managers routinely violate the rule against interpretation and application of semantics only by "the host specified in the domain part of the address". > I specify the address emailcore@ietf.org. My message travels to an > ietf.org email server and it resolves emailcore, handing the message > over to the mailing list system.(*) > The message has been delivered to the address I specified. > What the MLM does after that is secondary, for the purposes of this thread. That might have been reasonable had you not justified the rule by making the point that "Having the Local-part be globally opaque is an important feature of Internet Mail." But you did. And that is in fact what justifies having the rule, not the far lesser claim that the pure transport infrastructure alone should not interrpet local parts. That rule by itself is almost worthless, since then all I need to do to justify whatever mangling I want to do of other people's address is say, "But I'm an MDA!" Ned From nobody Fri Jan 8 13:12:45 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F0A3A12E5 for ; Fri, 8 Jan 2021 13:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 T9D1n-mKz2CC for ; Fri, 8 Jan 2021 13:12:42 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D13D33A0F3D for ; Fri, 8 Jan 2021 13:12:42 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kxz3p-0002aJ-Gb; Fri, 08 Jan 2021 16:12:41 -0500 Date: Fri, 08 Jan 2021 16:12:35 -0500 From: John C Klensin To: Ned Freed cc: emailcore@ietf.org Message-ID: <401C14171E5834553A054F45@PSB> In-Reply-To: <01RU4P45I2YI004QVR@mauve.mrochek.com> References: <20210106170718.9F6335CC249C@ary.qy> <9AE5B08FCF664B8F9A7721C2@PSB> <01RU3P9I4R8W004QVR@mauve.mrochek.com> <44b4b60e-58ce-7ac1-66d3-26c59722722b@dcrocker.net> <01RU4P45I2YI004QVR@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] MDAs (was: Re: Delivered-To issues) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 21:12:44 -0000 --On Friday, January 8, 2021 07:30 -0800 Ned Freed wrote: >... >> Consider: > >> 2.3.11. Mailbox and Address >> ... >> standard mailbox naming convention is defined to be >> "local-part@domain"; contemporary usage permits a much >> broader set of applications than simple "user names". >> Consequently, and due to a long history of problems when >> intermediate hosts have attempted to optimize transport >> by modifying them, the local-part MUST be interpreted and >> assigned semantics only by the host specified in the >> domain part of the address. > > There's just one problem with this text: This isn't true. It > has never been true, and no amount of repetition, compliance > language, or anything else will make it true. > The obvious example, which I have pointed out many times, is > when mailing lists have to decide whether or not a > subscribe/unsubscribe request is a match to an address on the > list. This means choosing whether or not other people's > local-parts are case-sensitive. (There's also the issue of > things like unnecessary quoting, which in the interests of my > own sanity I'm going to ignore.) >... Ned, this may be another fork in the conversation, but... I agree with you about the "not true and has never been true" part, even though it was in 2821 and I can't remember where it come from before that. I suspect we were trying to make a strong point about relays not fussing with addresses in the hope of improving things because they thought they understood what was going on and getting it wrong. Examples involving "%" or "!" in the local-part come to mind immediately even though they are much less relevant today than they were twenty years ago. And, with the best of intentions, we (or I) didn't get it quite right (or, from the standpoint of this particular discussion, even nearly right). So, speaking both as editor and as an individual participant, I would welcome a proposal as to how to fix it, especially if we are not the only ones who believe that, as written, it isn't true/correct. As far as unnecessary quoting is concerned, see G.9 of draft-ietf-emailcore-rfc5321bis-01, Ticket #21 and maybe #35. I would certainly be happy to clean that up if we can at this stage. If we cannot do the cleanup in 5321bis (and part of it in 5322bis), I'd favor putting "don't do that unless you really need to because bad thing happen" language into the A/S. john From nobody Fri Jan 8 13:26:33 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA593A130B for ; Fri, 8 Jan 2021 13:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 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.262, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 FtVZGnlf0y8b for ; Fri, 8 Jan 2021 13:26:30 -0800 (PST) Received: from hedgehog.birch.relay.mailchannels.net (hedgehog.birch.relay.mailchannels.net [23.83.209.81]) (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 BF7E43A1308 for ; Fri, 8 Jan 2021 13:26:29 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 4FF49322BB6; Fri, 8 Jan 2021 21:26:21 +0000 (UTC) Received: from nl-srv-smtpout2.hostinger.io (100-98-118-97.trex.outbound.svc.cluster.local [100.98.118.97]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 744523222F1; Fri, 8 Jan 2021 21:26:19 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout2.hostinger.io ([UNAVAILABLE]. [145.14.159.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Fri, 08 Jan 2021 21:26:21 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Grain-Absorbed: 2df17ac11738da42_1610141180184_2430542643 X-MC-Loop-Signature: 1610141180184:200493228 X-MC-Ingress-Time: 1610141180184 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout2.hostinger.io (smtp.hostinger.com) with ESMTPSA id DD77A32220B7; Fri, 8 Jan 2021 21:26:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1610141177; bh=7IRdfpKx2PS9cP4NSr5LvAlf88sw8uZKDLR3BB/I1SI=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=YE7nqBMcVN+MmO5iMVItr/EUCTCdL18hOVwtfPZ2qmSwV2iplNuiAILsSPe7Jo0aP TwrF/+w1UpTYAQuKxy3S0gilHNzQDTha0qC7LAN68C4437RNgLRBDIu4x8A5IU2bvP 4sbHB8azwDCGXnox41ITSXZIhW05yjK1psMUpay68ei+pOeBJUe4H4/bbuSCgUt3cd s/zKFFJ4yiXaE4pj4oecBG5yxMsdk9djtapHUX1UwlrRjXOHwlj0ChcOD9mCQ5LqaN wEoJP9/tQmBqkxWI+R64HXY8h4k+IvvST6pOv7oGI9gk37OIBe634rIbva1aXynJrl ONSmczcXwj3Pg== Reply-To: dcrocker@bbiw.net To: John C Klensin Cc: emailcore@ietf.org References: <20210106170718.9F6335CC249C@ary.qy> <9AE5B08FCF664B8F9A7721C2@PSB> <01RU3P9I4R8W004QVR@mauve.mrochek.com> <44b4b60e-58ce-7ac1-66d3-26c59722722b@dcrocker.net> <01RU4P45I2YI004QVR@mauve.mrochek.com> <401C14171E5834553A054F45@PSB> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Fri, 8 Jan 2021 13:26:14 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <401C14171E5834553A054F45@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] MDAs (was: Re: Delivered-To issues) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 21:26:32 -0000 On 1/8/2021 1:12 PM, John C Klensin wrote: > Examples involving "%" or > "!" in the local-part come to mind immediately Addressing conventions like those pertain to other email services, not Internet Mail. Processing those is done by a gateway, not an MTA. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jan 9 14:24:15 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C65E3A044A for ; Sat, 9 Jan 2021 14:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 pUPbXoTJULsf for ; Sat, 9 Jan 2021 14:24:12 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07E13A046B for ; Sat, 9 Jan 2021 14:24:12 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kyMeZ-0009u5-8J; Sat, 09 Jan 2021 17:24:11 -0500 Date: Sat, 09 Jan 2021 17:24:04 -0500 From: John C Klensin To: Alessandro Vesely , emailcore@ietf.org Message-ID: <306A848BA9E6BE7CC38465E3@PSB> In-Reply-To: <5f8f7894-b736-1f15-2dd4-865f68d6702d@tana.it> References: <8034D30CAC474E52B15C1AC4@PSB> <5f8f7894-b736-1f15-2dd4-865f68d6702d@tana.it> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Navigating 5321bis (and predecessors) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2021 22:24:14 -0000 --On Thursday, January 7, 2021 10:25 +0100 Alessandro Vesely wrote: >> (2) Are there ways that we can mitigate the problems with >> finding things. [...] Would that be worth doing in terms of >> finding information or is the table of contents sufficient? >> Other ideas? > > I think an index is useless nowadays, since page numbers are > not a univocal reference anymore (they only appear in PDFs and > are presumably going to depend on paper formats.) I hope it is sorted out quickly --certainly before 5321bis is ready-- but the xml2rfc vocabulary defines index ("") elements which presumably means it is someone's problem (not ours) to implement them in a way that is sensible for all relevant output formats. My personal opinion is that will mean index entries have to end up targeting section numbers, not page numbers, but I wait to see what others come up with. However, unless there is a proposal and community consensus to declare that markup element useless and/or obsolete, I think we get to assume that they will work in some meaningful way. > Rather, I'd insert [See also ] notes wherever > appropriate. As I think I mentioned in an earlier note, that is already underway. I welcome pointers to additional places where such cross-references would be helpful. best, john From nobody Sat Jan 9 14:48:02 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03603A0964 for ; Sat, 9 Jan 2021 14:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 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.262, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 I7VC-S2JQxBa for ; Sat, 9 Jan 2021 14:47:59 -0800 (PST) Received: from bee.birch.relay.mailchannels.net (bee.birch.relay.mailchannels.net [23.83.209.14]) (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 DE3223A095F for ; Sat, 9 Jan 2021 14:47:58 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 8DAC83425D1; Sat, 9 Jan 2021 22:47:57 +0000 (UTC) Received: from nl-srv-smtpout4.hostinger.io (100-96-87-21.trex.outbound.svc.cluster.local [100.96.87.21]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id B89B63425FB; Sat, 9 Jan 2021 22:47:55 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout4.hostinger.io ([UNAVAILABLE]. [145.14.159.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Sat, 09 Jan 2021 22:47:57 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Shade-Rock: 0cbfd4cf62fe0074_1610232476800_881759475 X-MC-Loop-Signature: 1610232476800:1028969185 X-MC-Ingress-Time: 1610232476796 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout4.hostinger.io (smtp.hostinger.com) with ESMTPSA id 7D2C23072E5F; Sat, 9 Jan 2021 22:47:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1610232474; bh=rm8nbzqVw9L1oEpWgrnmvKtohIpVPVlwyxtpFGZDweA=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=PhkkHWBj+lXAyTLVcYbtnXsvprBewDUcarWba5Bdi1EuHkBFrc5rZ4hmVEcEmnTfm U8x4jvLqAMxv9qbiz4Hlllqj/pACBFQdf9ukZyjvQvXKWzWtXc1D6CeqCVZFaaU4b1 GfSAz0unqsbFAwthXxs+EdTX0xKeVCgPlv3CpSsOP/cbTMifweBOL1Z6aAWtjXUjST H0OiM7W8sqIyC+xSkdWS6hXw76vuoqcVLZkGXWx/Gl6bPAQuZxrG0RGV1O5RpBIP5R JnD2rxTwjhDsEol5a/8+zDs0rxAuh3bIRXuP37x9WyR81KVh2D6h7mtndZGPAyHeF9 lsgps1IF3NCTA== Reply-To: dcrocker@bbiw.net To: Ned Freed Cc: emailcore@ietf.org References: <20210106170718.9F6335CC249C@ary.qy> <9AE5B08FCF664B8F9A7721C2@PSB> <01RU3P9I4R8W004QVR@mauve.mrochek.com> <44b4b60e-58ce-7ac1-66d3-26c59722722b@dcrocker.net> <01RU4P45I2YI004QVR@mauve.mrochek.com> <01RU4W3B8POW004QVR@mauve.mrochek.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Sat, 9 Jan 2021 14:47:49 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <01RU4W3B8POW004QVR@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] MDAs (was: Re: Delivered-To issues) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2021 22:48:01 -0000 Ned, On 1/8/2021 11:56 AM, Ned Freed wrote: >> On 1/8/2021 7:30 AM, Ned Freed wrote: >> Except that a mailing list operates /after/ delivery. (And before >> re-posting.) > > First of all, I was not talking about the list itself, but rather the > tools that maintain it. For reference, I still do not see how mailing lists are relevant to a discussion about transport rules. But see my next comment. > There's also the case where the list does similar comparisons in > order to implement restrictions like "you have to be on the list to > post" - and these often implement some understanding of subaddress > semantics - and yes, those do operate after delivery, but this is all > beside the point. The fact is that mailing lists and mailing list > managers routinely violate the rule against interpretation and > application of semantics only by "the host specified in the domain > part of the address". We have a fundamental disconnect, here, which well might mean we do NOT have a fundamental disagreement. (And the end of your note seems to have anticipated or discerned the former, if not the latter.) It might be that I needed to be clearer: My focus, about the opacity of the left-hand side, pertains only to classic, MHS-level -- MTA -- behavior. NOT with possible, idiosyncratic behaviors at the MUA level, which would include MLMs. I can imagine a view that it should also include MUA level, as well as a view that it should not. But I'll suggest that it is an entirely unrelated discussion, which isn't needed for the current work. (Neither 5321bis nor Deliver-To:) >> I specify the address emailcore@ietf.org. My message travels to >> an ietf.org email server and it resolves emailcore, handing the >> message over to the mailing list system.(*) > >> The message has been delivered to the address I specified. > >> What the MLM does after that is secondary, for the purposes of this >> thread. > > That might have been reasonable had you not justified the rule by > making the point that "Having the Local-part be globally opaque is an > important feature of Internet Mail." But you did. Would "opaque to the Mail Handling Service" be acceptable, since that's the scope I'd intended? > And that is in fact what justifies having the rule, not the far > lesser claim that the pure transport infrastructure alone should not > interrpet local parts. That rule by itself is almost worthless, since > then all I need to do to justify whatever mangling I want to do of > other people's address is say, "But I'm an MDA!" I've read the above a few times, and I'm probably missing the point. Saying that the transport service treats the LHS as opaque, until reaching a place under the administrative control for the RHS, doesn't seem worthless to me. Lesser, yes, but far from worthless. As for the local domain's LHS namespace, it doesn't strike me as taking a liberty or all that odd to say it can interpret strings for its own namespace however it wants. As in: of course. As for declaring the MDA role whimsically, it seems to me not a small thing to note that that declaration means the message is no longer in the MHS and has moved into user-space. What am I misunderstanding? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jan 9 19:21:41 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3A83A0AFB for ; Sat, 9 Jan 2021 19:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.452 X-Spam-Level: X-Spam-Status: No, score=-1.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=HSnCgm8A; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=Zi605HGc 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 lYUGRzu0RAOG for ; Sat, 9 Jan 2021 19:21:37 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 182AA3A0AFA for ; Sat, 9 Jan 2021 19:21:36 -0800 (PST) Received: (qmail 33093 invoked by uid 100); 10 Jan 2021 03:21:36 -0000 Date: 10 Jan 2021 03:21:35 -0000 Message-ID: From: "John Levine" To: emailcore@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=813e.5ffa72bf.k2101; i=news@user.iecc.com; bh=Ykpqvnskv7kAP6IWpfmI6JxlQsVkxLTtcq2kjYGHyTA=; b=HSnCgm8Auy/j/1En5+6P2JNR+6y829TZBGfpRtIzxzhtNFyGYwu+m6l21ijl2hVqqCENcsHZI/HEWcH+vaD5yTklhi5tymNjzlwgGuoAGT2v3w72W/4Pr3rgx+QxWK5r5G8GVMVo4RwrVQTZRnkWcbnFyaEy7MTrV2yROY3/nIE37e2jrnXZSmnYBHdfsvTeEHNEeYZDEKxLl0KR4fKjp0Y9Y2RbjlL+i9h0dz7Ok8f/tJfOjX0AkbAqskIPLpBNkpmZVPCSbTy/jzC0LQJLL3Dm/yVezuQ0VzkTcVE4i8B1c0CrQDoN8+yPwGdzaYNzSxhSR0dBEzyFgfXEfTQNUA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=813e.5ffa72bf.k2101; olt=news@user.iecc.com; bh=Ykpqvnskv7kAP6IWpfmI6JxlQsVkxLTtcq2kjYGHyTA=; b=Zi605HGcZZsSolTMNSmGM3Z0PvAAHSLwUYdCb3k4BOh4dUQANMJNhWqPK3d7bc5rs9k0RpOdKi0O1sqkOe8wkowTFeU9necZwaInOv5d6nCraErMdIcMiAegTGjOPQ9zkhcOsG3bY89MRuWOSNQtIqV9uV5SttWn0gU1ATxk/KNidTi6bt5B8X+P8yHxR55u51OP8Xwu4uS4V+Gl6ZVOUNv6wQRzQUSYmv/kV9Lyz/11FD7OYtq/mydW9XUIJWiMWhW6nxKH6FyoAO45GugQS4OElB0oGMIuzjCtiv8Yxxr5veYh8YsCJoY8BhVqPcR1mhQ1TO+afXOBp7BNQ5KR5A== Organization: Taughannock Networks References: <8034D30CAC474E52B15C1AC4@PSB> <5f8f7894-b736-1f15-2dd4-865f68d6702d@tana.it> <306A848BA9E6BE7CC38465E3@PSB> In-Reply-To: <8034D30CAC474E52B15C1AC4@PSB> <5f8f7894-b736-1f15-2dd4-865f68d6702d@tana.it> <306A848BA9E6BE7CC38465E3@PSB> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [Emailcore] Navigating 5321bis (and predecessors) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2021 03:21:38 -0000 In article <306A848BA9E6BE7CC38465E3@PSB>, John C Klensin wrote: >> I think an index is useless nowadays, since page numbers are >> not a univocal reference anymore (they only appear in PDFs and >> are presumably going to depend on paper formats.) Indices don't have to point to oage numbers. They can refer to section numbers or unsing this new-fangled web thing, they can link directly to the relevant sections. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Jan 9 19:41:33 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0E03A0BD7 for ; Sat, 9 Jan 2021 19:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 KgknGnSsFQh5 for ; Sat, 9 Jan 2021 19:41:30 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CF23A0BD5 for ; Sat, 9 Jan 2021 19:41:30 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kyRbc-000BjW-To; Sat, 09 Jan 2021 22:41:28 -0500 Date: Sat, 09 Jan 2021 22:41:22 -0500 From: John C Klensin To: John Levine cc: emailcore@ietf.org Message-ID: <2CA5568312BD9B98191B80FB@PSB> In-Reply-To: References: <8034D30CAC474E52B15C1AC4@PSB> <5f8f7894-b736-1f15-2dd4-865f68d6702d@tana.it> <306A848BA9E6BE7CC38465E3@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Navigating 5321bis (and predecessors) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2021 03:41:32 -0000 --On Sunday, January 10, 2021 03:21 +0000 John Levine wrote: > In article <306A848BA9E6BE7CC38465E3@PSB>, > John C Klensin wrote: >>> I think an index is useless nowadays, since page numbers are >>> not a univocal reference anymore (they only appear in PDFs >>> and are presumably going to depend on paper formats.) > > Indices don't have to point to oage numbers. They can refer to > section numbers or unsing this new-fangled web thing, they can > link directly to the relevant sections. That is more or less what the portion of that note I actually wrote (as distinct from the quote from Alessandro above). Did that not catch up with you and the list? john From nobody Sat Jan 9 22:26:18 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE5D3A0C2E for ; Sat, 9 Jan 2021 22:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 Lc11BduWgDih for ; Sat, 9 Jan 2021 22:26:14 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 2E5903A0C2A for ; Sat, 9 Jan 2021 22:26:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1610259969; bh=4hps6kGcMBhKNhFrZgtyWqNoEBH3X/HoRygnUGXMeQQ=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=iylB5iyGyuUnwVSJwN7NirXQA5dyDljmaN1m8WIB/R41NLVEg1crgSjDTuWIfGKt6 oMrTrV77MUy0Lorc5Vu+3Xb7rF/z16IYJreUQIEe2dImlKL7rRCdoVSRah+vas4bRr dvLyz0ZHljtbPXE0uRw6enGofaD+y2fpyuAn3B7k= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.20] ([91.61.52.81]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MHXFr-1kla1Q1RFh-00DXWp for ; Sun, 10 Jan 2021 07:26:09 +0100 To: emailcore@ietf.org References: <8034D30CAC474E52B15C1AC4@PSB> <5f8f7894-b736-1f15-2dd4-865f68d6702d@tana.it> <306A848BA9E6BE7CC38465E3@PSB> From: Julian Reschke Message-ID: <3bf6f02c-b408-97e2-e1c8-c817637d9123@gmx.de> Date: Sun, 10 Jan 2021 07:26:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <306A848BA9E6BE7CC38465E3@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:/sbe2qN4TQHWbHF5c3UsaUyNkigCFCxz8zupW2CwvYDfdlF2bvK lO4b+6Y4KGGV29J64MHphL8519MdVvTQoCn+7cjkqpg5Tf8TV33osC60UhDbHgGLb5Dsx8R lN1fRoTjT7rKdJwahi6I9lvlkjhH4d/ooSGk2Pk7+GbkxyAXaQpsZIg25lababEpRr3iBm4 PyzGD2U80+gQUKeFiGd+w== X-UI-Out-Filterresults: notjunk:1;V03:K0:11e7gOSz3Zc=:LspWDH9TPukoCkv0AAcL4F L5WBHazOmgpW/RyHtJE3ZIWs67zTD4LLfSTA2brSKkivLjz6eplwjI1gP4MeHg+8D0AHMu7dR pC1HlwBDu0iiT5zbl4h+pZIVJ2zGyj8qTciMdnu6DJKo2FFsJaJXufhpfOKI42ENmGDAJa9ta 2GVd0J5TiI2RJ4+RJ5b0yNgZZbTUXOxEHp94tpXBkByIiyx/85N2akp7PWt22fybj6GmY/A9H sQx6/6iKUTrI5dNKLjkVOi6RcJudeg8gQyXuwkomlOHUydv8oicfbRvhhVLtzyqe7jKq+VozV znsmqHYssxWiZs7T6ZyidSbCQfi7fxgcKQvhCs+6wdaM4tizsa76h8O/bbWOoERDCXhkcpIgz vsxXn5L3MfEAKeZOcN4OJZ7peMT+BhJZSxZO6iMbdlFVmcy0VS5TvCJY0Cw4s+z6Bgiu6u6eq 4tGNc1NCi0iG5NqJBxkDFoUhd86V1MxsFR/gv5KxCGw8EK1T1nfpLPUqrHjrSnOkGIDVhXnpA vo3DOqlRWFaBBFXRtmgNFeZvlzsQiRzN+9Si2caO6164TIuDprPBpFbODl2JazachjB6it8Dw FDCnz6dhJMfMMjcf9nS8TIB2HAmrPySwvzHywzmZk9LfVWXKVMoORX2DzCfRQYvrbZjyOOXRj Bsx8nhOGioqLCuTFL2xjEWKVqSFLLWGgC0hHvRJT5DYzZlBrZ8J9FL5R/hLN+r5v/z194zwxS 6aFqjzpcg389hAnFeaxewkTDAySLpIvuoameOJGiA9OEHCtC4+GB2WpVGmifQgf0otG+Yg1q+ LPUYGckUULEaHX2eXTxbDGZj8S3sdwJ6fu9gWS0/46oAJuuEvkYUDH5V+EbGmkVYvCCBd0vVL bnAMlpgkgTulBVWOF4Aw== Archived-At: Subject: Re: [Emailcore] Navigating 5321bis (and predecessors) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2021 06:26:16 -0000 Am 09.01.2021 um 23:24 schrieb John C Klensin: > > > --On Thursday, January 7, 2021 10:25 +0100 Alessandro Vesely > wrote: > >>> (2) Are there ways that we can mitigate the problems with >>> finding things. [...] Would that be worth doing in terms of >>> finding information or is the table of contents sufficient? >>> Other ideas? >> >> I think an index is useless nowadays, since page numbers are >> not a univocal reference anymore (they only appear in PDFs and >> are presumably going to depend on paper formats.) > > I hope it is sorted out quickly --certainly before 5321bis is > ready-- but the xml2rfc vocabulary defines index ("") > elements which presumably means it is someone's problem (not > ours) to implement them in a way that is sensible for all > relevant output formats. My personal opinion is that will mean > index entries have to end up targeting section numbers, not page > numbers, but I wait to see what others come up with. However, > unless there is a proposal and community consensus to declare > that markup element useless and/or obsolete, I think we get to > assume that they will work in some meaningful way. > ... +1, but note =2D- index generation currently is broken in xml2rfc (in v3 mode). Best regards, Julian From nobody Sat Jan 9 23:04:02 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18BB3A0D2A for ; Sat, 9 Jan 2021 23:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1JGGwRBLPbzr for ; Sat, 9 Jan 2021 23:03:59 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5033A0D13 for ; Sat, 9 Jan 2021 23:03:59 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kyUlZ-000CiY-CT; Sun, 10 Jan 2021 02:03:57 -0500 Date: Sun, 10 Jan 2021 02:03:50 -0500 From: John C Klensin To: Julian Reschke , emailcore@ietf.org Message-ID: In-Reply-To: <3bf6f02c-b408-97e2-e1c8-c817637d9123@gmx.de> References: <8034D30CAC474E52B15C1AC4@PSB> <5f8f7894-b736-1f15-2dd4-865f68d6702d@tana.it> <306A848BA9E6BE7CC38465E3@PSB> <3bf6f02c-b408-97e2-e1c8-c817637d9123@gmx.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Navigating 5321bis (and predecessors) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2021 07:04:01 -0000 --On Sunday, January 10, 2021 07:26 +0100 Julian Reschke wrote: >> I hope it is sorted out quickly --certainly before 5321bis is >> ready-- but the xml2rfc vocabulary defines index ("") >> elements which presumably means it is someone's problem (not >> ours) to implement them in a way that is sensible for all >> relevant output formats. My personal opinion is that will >> mean index entries have to end up targeting section numbers, >> not page numbers, but I wait to see what others come up with. >> However, unless there is a proposal and community consensus >> to declare that markup element useless and/or obsolete, I >> think we get to assume that they will work in some meaningful >> way. >> ... > > +1, but note > > -- index generation currently is broken in xml2rfc (in v3 > mode). That had been called to my attention after I noticed that converting the (v2) xml for draft-ietf-emailcore-rfc5321bis-01 (which carries forward the index from RFC 5321) to v3 produced perfectly good entries but that processing it into either text or PDF produced some rather badly damaged output without any index targets. My perspective as editor is that the index was added to RFC 5321 after IETF Last Call and at the insistence of the IESG. Unless the IESG wants to undo that decision (and undo it RSN rather than during or after IETF LC when the document gets there), I hope the problem is fixed before the WG finishes its work. The fix should ideally reference section numbers, not page numbers, for obvious reasons. Otherwise either the RPC is going to have a really interesting problem on its hands or this WG should stop its work until the tools are ready. So I agree with your end of December priority change from "minor" to "major". john From nobody Sun Jan 10 05:09:50 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D14E3A0CFC for ; Sun, 10 Jan 2021 05:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.88 X-Spam-Level: X-Spam-Status: No, score=-2.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.262, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 QVewdZM0_CUV for ; Sun, 10 Jan 2021 05:09:47 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 A0EE13A0D04 for ; Sun, 10 Jan 2021 05:09:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1610284182; bh=spMTRQDIJqmVscmULaxm2bQDPeYqM4ozTiYvPtMQ75k=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=A6ftNGEVLRdyG//E5pvAWuRz+Hk4YaxvmGQTfo5EShPEvero7MDFKCvHbF6L0YydN XhqFUGAx6RgF3QaZKhIrKK7UI5tTFhOdT66C1sqN3JBlfNP+XlXtnYR4uao28Pivpd oWINrOYyF/AfwVemPZ4PpuLbnRQ2Le5bjbH4z7OE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.20] ([91.61.52.81]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mz9Un-1k2ta12ySh-00wGmN for ; Sun, 10 Jan 2021 14:09:42 +0100 To: emailcore@ietf.org References: <8034D30CAC474E52B15C1AC4@PSB> <5f8f7894-b736-1f15-2dd4-865f68d6702d@tana.it> <306A848BA9E6BE7CC38465E3@PSB> From: Julian Reschke Message-ID: <42fd497c-e107-87a9-dc8c-27459c944afc@gmx.de> Date: Sun, 10 Jan 2021 14:09:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:4CYTlk9DxFyYr/XVSSX8jTZ05UUWhaPU35rkLc7RNtmwTt8JZCL XWXQI3ibWXeL6UZEjp63uMRwL26NALfUF2H1403Lu5LFqHuZ0nq3fk65+XrR1CLKOPwrHJ1 vVkqtWd1JgZYsa3n1hZZOp3CWcTXEQkbFXMHi2/oHDbSFp9ek9NIWne3lpIWqFDDhtdmkfM +U54VHkYyOKQDGSCTxEGg== X-UI-Out-Filterresults: notjunk:1;V03:K0:LwaLPvApAmw=:vZzzWqFwikavQKk6hiS9B0 lPL6GtF4rjpG7mc3z13FcxvwCuKNGLCOxest8sg6oMLR0xwZ8RyUnRvytWTyWiKKW/3xqQWvI kV8RO3g8AxacmE84OvLIx1b29uoVdOtUU+zOYJ7ePtouBky+NE+vJShiNfSGEF8HGWoD66bdO IWP+sf4OBfDhPl0+BsiRA07IBqB0PRslwW8fctJP5/3vNVhpv+34eOY6m39zG7IwLeGEYkEq2 jXM3Tu37uAzQDZrpGJswSHt18sENCCqMl8Xxtl+MicPEMtielN0YXqkwoLOBAzza5NUSxzTLt WUOY0YqCL5n0rPkfLriywexFAL5gTiNxauId9GVGNeTwi5AukoxQEnjThvGS1lF3VJCMs4RWy BbWPg9KhUB6+Jz8rptLPQKm2X2G5R9jmgvL6ESS/KWgozx6NAzlfqGTwCQTRpHHlnGi6upozn HOy3NftDgQ7ao5G8SN8zPVopBUkLp/PpzWWWNYL0Nm/wMybhUkKZjR9xYW/N6dWIlh9jdxaN7 DbaeRJny4VBiMYCoAIZOF8FNrcvefrFBC+2djkj1DOkVBreO2I8B1zCgRjylfo0CyFkX9EUSE O2NRPSXYcX6zVuzXhYxcGz+Hj4uoNfnEOQIOFclEO5XiHT4QH3JeQUTdisdGfzkC4//kSmB7E yHNSr+Q+TLbVTqClutj5VWpDUCjVYM9wLqdbNLy4tRvII2RRIYNOoZCv+Fwq5KKZRpfLWMREw RZdWRwGSpO6lLRroeTYf0AdnmjLV4agxj8BxTxFJq2nL4sEslE1lZbnCq+6SwO5lzBU0Qi+ti 6ZZmm49JaiKc9/Fh6/T6Mxj006QCQ+d5XtrdRk15hOeLn8fy4jUOwTmxyN7v1mhJ8k05rdfRX w3po0bk0kWQ8QV+vAZ4w== Archived-At: Subject: Re: [Emailcore] Navigating 5321bis (and predecessors) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2021 13:09:49 -0000 Am 10.01.2021 um 04:21 schrieb John Levine: > In article <306A848BA9E6BE7CC38465E3@PSB>, > John C Klensin wrote: >>> I think an index is useless nowadays, since page numbers are >>> not a univocal reference anymore (they only appear in PDFs and >>> are presumably going to depend on paper formats.) > > Indices don't have to point to oage numbers. They can refer to > section numbers or unsing this new-fangled web thing, they can > link directly to the relevant sections. Index entries should hyperlink where possible (HTML, PDF). In unpaginated formats, the displayed value for each link can be the section number (and is and has been that way in all processors *except* xml2rfc's v3 mode). In paginated formats (HTML in paged media mode, PDF), the displayed value can be indeed a page number. Best regards, Julian From nobody Sun Jan 10 11:29:11 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3045F3A11EC for ; Sun, 10 Jan 2021 11:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, FREEMAIL_FROM=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 (2048-bit key) header.d=fastmail.fm header.b=eolX0gyB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bBqM/OkJ 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 r8SbTdJ2f4Vo for ; Sun, 10 Jan 2021 11:29:09 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC6C3A11E9 for ; Sun, 10 Jan 2021 11:29:08 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B0C0C5C005D; Sun, 10 Jan 2021 14:29:07 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 10 Jan 2021 14:29:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=u Fo22ECVJb9x8Bvqjq1SbvncVfjr7HO0RkrWcCzyvFo=; b=eolX0gyBWpfzBlhwh 4jn4XEmq593ZfegJqeZmCPSYN+AW22zxWaRvAZNXEd2WRYbI6wuO4YlgFQBqJ1gk B8RQ/hyooRntzX5qXconYJRnKMIprNPpufO/Fvd2Kr9tRSwWcMGIuyl80VMhLzea /acBYgBlXF7My4kBfDQ9GPMyHWo5McJktBCbrpYGMS7Co3NyjIkcfNHhrLU4Nwk8 OKpE0KvAu1XOmCk5rPvLruFgTFhoheDJNJohXDC3fhPRhDBFB5HJZ8sKQJOpSyNa WngBpedy3n6OquqmkdbUuUbFdTtKvDsBLJUcjfcWMUOKi2Z2b4PIsp9LoDH7HP8L pv7MQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=uFo22ECVJb9x8Bvqjq1SbvncVfjr7HO0RkrWcCzyv Fo=; b=bBqM/OkJQEj05/A4pSdKeSXsfelBxWBmbE7cZokVlGHWbrP6P7mjdYxl4 opnplstafn1GtcHUrWjGM8ZjJUIzwl1EAPUV2H7DAQIW2l8ZKEU8uBzmIsRSo4zY nYK6pC9KPznu8EotqCk61qyzO4CwMt8uUyXGedD0avMhZE8O8ywLXJE4HuQsTH/1 XgOGUaeFIBaFlcP6U6djDCKe7PqVLJic9d9BLqi1kJ7y/pNxTao/VFCXCjZwTRtY pJDguAxvCTJGRqhlSRWOTnz9NYJpsWnyAQfTdjwYC2qAHM5D2E8LA7tbvI2b6D/Q uVY21lmMVrkLl137NbhrTuyirc1yA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegledguddviecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhffojgffgffkfhfvsehtqhhmtdhhtdejnecuhfhrohhmpeetlhgv gigvhicuofgvlhhnihhkohhvuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucggtffrrghtthgvrhhnpeekhfetleeludduhfefueeiffdvffdtgefhfeeuleet gfejhedujeevueegieeuheenucfkphepjeekrddutdehrdduvddvrdduleefnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhk ohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: from [192.168.0.2] (4e697ac1.skybroadband.com [78.105.122.193]) by mail.messagingengine.com (Postfix) with ESMTPA id D14D11080059; Sun, 10 Jan 2021 14:29:06 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (16G102) In-Reply-To: <401C14171E5834553A054F45@PSB> Date: Sun, 10 Jan 2021 19:29:06 +0000 Cc: emailcore@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <321E669E-C87F-4F06-BA37-40677A2A91EB@fastmail.fm> References: <20210106170718.9F6335CC249C@ary.qy> <9AE5B08FCF664B8F9A7721C2@PSB> <01RU3P9I4R8W004QVR@mauve.mrochek.com> <44b4b60e-58ce-7ac1-66d3-26c59722722b@dcrocker.net> <01RU4P45I2YI004QVR@mauve.mrochek.com> <401C14171E5834553A054F45@PSB> To: John C Klensin , Ned Freed Archived-At: Subject: Re: [Emailcore] MDAs (was: Re: Delivered-To issues) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2021 19:29:10 -0000 Hi all, > On 8 Jan 2021, at 21:12, John C Klensin wrote: >=20 > --On Friday, January 8, 2021 07:30 -0800 Ned Freed > wrote: >=20 >> ... >>> Consider: >>=20 >>> 2.3.11. Mailbox and Address >>> ... >>> standard mailbox naming convention is defined to be >>> "local-part@domain"; contemporary usage permits a much >>> broader set of applications than simple "user names". >>> Consequently, and due to a long history of problems when >>> intermediate hosts have attempted to optimize transport >>> by modifying them, the local-part MUST be interpreted and >>> assigned semantics only by the host specified in the >>> domain part of the address. >>=20 >> There's just one problem with this text: This isn't true. It >> has never been true, and no amount of repetition, compliance >> language, or anything else will make it true. >=20 >> The obvious example, which I have pointed out many times, is >> when mailing lists have to decide whether or not a >> subscribe/unsubscribe request is a match to an address on the >> list. This means choosing whether or not other people's >> local-parts are case-sensitive. (There's also the issue of >> things like unnecessary quoting, which in the interests of my >> own sanity I'm going to ignore.) >> ... >=20 > Ned, this may be another fork in the conversation, but... Yes, please. Let=E2=80=99s change subject and create a new ticket, if needed= . Best Regards, Alexey, as co-chair From nobody Tue Jan 12 12:18:22 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B3A3A116F for ; Tue, 12 Jan 2021 12:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.971 X-Spam-Level: X-Spam-Status: No, score=-17.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 vNmaP_GLVw0P for ; Tue, 12 Jan 2021 12:18:18 -0800 (PST) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0F673A116A for ; Tue, 12 Jan 2021 12:18:18 -0800 (PST) Received: by mail-ua1-x930.google.com with SMTP id 73so1234713uac.8 for ; Tue, 12 Jan 2021 12:18:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=arlS85mAccU6d7STrD2r+NNWNznmphIth1Dk3JHPHoQ=; b=CByUvFbPJ+ufLaekmdXEBFrxL8T3GCcK0/60ldxEC9BruSdF78dnt6K0SsVKsm43qM lQN8jMe4cYw9ILkHjJ2kitvy1FoILyi+u/QzG7H7UyJQa25BU3qZaL3PwA64sHokat4H axN+nQ5wTCRtPDwFIBHxqQvWFANqxoA3M5jIr8Pm9kD0bW4L7LUQfTprJ75sYLYzQJfT Va2C0BKJJD5hv1NXluUDJyGINElP20ZlCxTAUuPyD+St3seYtnW4kk/D8wkJBT7jhAye HkEDVmPOAwAbuB3d+SOlNaiTXDZ6KwE83D3wDXgoDt4AzsHpnbw7dKdwDbRL+LqaTWDY w0VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=arlS85mAccU6d7STrD2r+NNWNznmphIth1Dk3JHPHoQ=; b=n3SM9hoTd+Ntq050QRivzDfp/S4plqahmX9yFK931LIScVBDALUEbiXm40zh4TqO16 FZmc6HOCgd/SXymoM+mvom6YcsaXggwTMLrOcnrDqnwhoT3cg/YOisLPKD1Il0gPnnXQ FiFW6NSDQTKjgFanjKNG9BwFrHqq5w6OU846qja3Nj2pomt5lGiccT4XmuTVMdlOLQy7 dO5auBfsFPjgmBhBna6vCWekYjaCvwpSaDHu/2boEH6K/rUj3vUoV8eLnQMiVZ1yoIGl lrk2MTSFzQ8D+bXpMivwmMjQiKnITUXOoZ5B446W8e0ZxpgBTj/rWWbnuLjJhgUssv6I 9yoA== X-Gm-Message-State: AOAM533iqiHCDiZeCXvAXbezo04C+u3ujIs3LRE6M3En9A5hxNF4t4eJ pdcOH0/SO84Ea0Uy47Pmc4rcgEW8M+GblNTLwdI3r5CaWA== X-Google-Smtp-Source: ABdhPJxFHESL6nXwTCIWJBoOvy4tF2U3Z2z012LoeXQr78BIQp4mcYBad93xYbh68ai/TaS72n7Yl6lB/04aqogu9LE= X-Received: by 2002:a9f:2356:: with SMTP id 80mr1199849uae.92.1610482697111; Tue, 12 Jan 2021 12:18:17 -0800 (PST) MIME-Version: 1.0 References: <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> <0ea03115-8730-1759-58ec-a4fbcd8508e6@dcrocker.net> In-Reply-To: <0ea03115-8730-1759-58ec-a4fbcd8508e6@dcrocker.net> From: Brandon Long Date: Tue, 12 Jan 2021 12:18:03 -0800 Message-ID: To: Dave Crocker Cc: emailcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000147a8205b8b9b9d2" Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 20:18:21 -0000 --000000000000147a8205b8b9b9d2 Content-Type: text/plain; charset="UTF-8" On Sat, Jan 2, 2021 at 5:48 AM Dave Crocker wrote: > On 1/1/2021 8:24 AM, Dave Crocker wrote: > > > > Should the recipient's MUA have access to the /sequence/ of RCPT TO > > addresses used to get to them? > > > If the recipient MUA is to have access to the sequence of RCPT TO > addresses, there are two ways to record this: > > 1) A single Deliver-To: header field, showing the (full) sequence > > 2) A sequence of Deliver-To: header fields, with each one showing > one RCPT TO address. > > The second would echo the approach taken for Received: header fields, of > course. It seems the easier choice. > > Any site performing the delivery transition of responsibility, from the > MHS to the addressee's control, slaps a Deliver-To: header field, with > that one address on it. > > The MUA can construct the sequence by scanning for these header fields, > from botton to top of the header. > > Thoughts? > > Also, I think I've seen some expression of concern about *privacy* > sensitivities, in showing previous Delive-To addresses. I'm not finding > myself understanding that well enough to write anything about it. Can > we get some discussion of it? > We previously had some multiple recipients listed in headers, and removed that for privacy reasons. Having multiple Delivered-To indicating multiple RCPT TO in the same transaction will share to each recipient the other recipients that got it, which is a violation of say the BCC expectations at the least. Our use case was attempting multiple recipients in the Received FOR clause, but the issue is the same regardless of whether it is the client or server in the MTA transaction. Having multiple Delivered-To because the message is forwarded is not the same type of privacy violation, as it is sequential, it's how the message reached them. Some examples were given in the similar usage of our per-recipient BCC header, where if you BCC " list_of_annoying_customers@foo.com" is then exposed to the recipients on that list. Overall, we didn't think that was a likely violation, especially since the potential for leaking by the list expansion itself was likely high. >From the rest of this discussion, it seems this is likely more an issue with Envelope-To than with Delivered-To, as "delivery" would imply a single destination. For that, I would recommend being similar to the discussion of BCC header where you can bifurcate the messages per-recipient so each recipient only sees their path. Brandon > > > d/ > > ps. There often is confusion about what 'delivery' means. This was a > point of very focused discussion, during the development of RFC 5598, > with a few folk driving home the rather unusual realization that it does > not take place during a communication exchange, but takes place /within/ > the MDA: > > > 4.3.3. Mail Delivery Agent (MDA) > > > > A transfer of responsibility from the MHS to a Recipient's > > environment (mailbox) is called "delivery". In the architecture, as > > depicted in Figure 5, delivery takes place within a Mail Delivery > > Agent (MDA) and is shown as the (D) transition from the MHS-oriented > > MDA component (hMDA) to the Recipient-oriented MDA component (rMDA). > > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > -- > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore > --000000000000147a8205b8b9b9d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jan 2, 2021 at 5:48 AM Dave C= rocker <dhc@dcrocker.net> wro= te:
On 1/1/2021 = 8:24 AM, Dave Crocker wrote:
>
>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 Should the recipient's MUA have acc= ess to the /sequence/ of RCPT TO
>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 addresses used to get to them?


If the recipient MUA is to have access to the sequence of RCPT TO
addresses, there are two ways to record this:

=C2=A0 =C2=A0 1) A single Deliver-To: header field, showing the (full) sequ= ence

=C2=A0 =C2=A0 2) A sequence of Deliver-To: header fields, with each one sho= wing
one RCPT TO address.

The second would echo the approach taken for Received: header fields, of course.=C2=A0 It seems the easier choice.

Any site performing the delivery transition of responsibility, from the MHS to the addressee's control, slaps a Deliver-To: header field, with =
that one address on it.

The MUA can construct the sequence by scanning for these header fields, from botton to top of the header.

Thoughts?

Also, I think I've seen some expression of concern about *privacy*
sensitivities, in showing previous Delive-To addresses.=C2=A0 I'm not f= inding
myself understanding that well enough to write anything about it.=C2=A0 Can=
we get some discussion of it?

We previo= usly had some multiple recipients listed in headers, and removed that for
privacy reasons.

Having multiple Delivere= d-To indicating multiple RCPT TO in the same transaction will
sha= re to each recipient the other recipients that got it, which is a violation= of say the BCC
expectations at the least.=C2=A0 Our use case was= attempting multiple recipients in the Received
FOR clause, but t= he issue is the same regardless of whether it is the client or server in th= e
MTA transaction.

Having multiple Deliv= ered-To because the message is forwarded is not the same type of privacy
violation, as it is sequential, it's how the message reached th= em.=C2=A0 Some examples were given in
the similar usage of our pe= r-recipient BCC header, where if you BCC "list_of_annoying_customers@foo.com"
is then exposed to the recipients on that list.=C2=A0 Overall, we did= n't think that was a likely violation, especially since
the p= otential for leaking by the list expansion itself was likely high.

From the rest of this discussion, it seems this is likely = more an issue with Envelope-To than with Delivered-To, as
"d= elivery" would imply a single destination.=C2=A0 For that, I would rec= ommend being similar to the discussion of BCC header
where you ca= n bifurcate the messages per-recipient so each recipient only sees their pa= th.

Brandon
=C2=A0


d/

ps. There often is confusion about what 'delivery' means.=C2=A0 Thi= s was a
point of very focused discussion, during the development of RFC 5598,
with a few folk driving home the rather unusual realization that it does not take place during a communication exchange, but takes place /within/ the MDA:

> 4.3.3.=C2=A0 Mail Delivery Agent (MDA)
>
>=C2=A0 =C2=A0 A transfer of responsibility from the MHS to a Recipient&= #39;s
>=C2=A0 =C2=A0 environment (mailbox) is called "delivery".=C2= =A0 In the architecture, as
>=C2=A0 =C2=A0 depicted in Figure 5, delivery takes place within a Mail = Delivery
>=C2=A0 =C2=A0 Agent (MDA) and is shown as the (D) transition from the M= HS-oriented
>=C2=A0 =C2=A0 MDA component (hMDA) to the Recipient-oriented MDA compon= ent (rMDA).



--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

--
Emailcore mailing list
Emailcore@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/emailcore
--000000000000147a8205b8b9b9d2-- From nobody Tue Jan 19 06:48:33 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6153A1566 for ; Tue, 19 Jan 2021 06:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 VNsLxGdOedvd for ; Tue, 19 Jan 2021 06:48:29 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 55B383A1564 for ; Tue, 19 Jan 2021 06:48:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1611067707; d=isode.com; s=june2016; i=@isode.com; bh=/sWLNYolcyHhhnW1O6Zlt4pJZvJPCwr0KDqR+Tgyrmw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=EBOeeqgjuFEbAn2ejJI4K7ZzOnQMbnW2tlkzSdTc8N7YoAYdNID1tlLxkTw7FCgYLSE18g mMUFIT1E4HHEk8IZhTcviMAHCOQQWRi2krqQgmcqAjwBBmFn7EWH7R0oiUHKQYsbAWTDvE aVNhRGGCHy+CBvIGgzruoYooCtjYt50=; Received: from [172.27.250.167] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 19 Jan 2021 14:48:26 +0000 To: emailcore@ietf.org From: Alexey Melnikov Message-ID: <42419b06-ae5a-48e0-6f95-ab3cec66b13a@isode.com> Date: Tue, 19 Jan 2021 14:48:26 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [Emailcore] CALL FOR FEEDBACK: Ticket #18: G.7.11. Should 1yz Be Revisited? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 14:48:31 -0000 Dear EMAILCORE participants, I would like to start 4 weeks feedback period (ending on February 16th=20 2021) on the following issue (*): =C2=A0 RFC 5321 depreciated the "positive preliminary reply" response code =C2=A0 category with first digit "1", so that the first digit of valid SMTP =C2=A0 response codes must be 2, 3, 4, or 5. It has been suggested (see =C2=A0 mail from Hector Santos with Subject "SMTP Reply code 1yz Positive =C2=A0 Preliminary reply", March 5, 2020 12:56 -0500, on the SMTP list) tha= t =C2=A0 these codes should be reinstated to deal with some situations that =C2=A0 became more plausible after 5321 was published. Do we need to take =C2=A0 this back up? Unless there is credible proposal in the form of a draft within 4 weeks,=20 I propose this issue is to be resolved as "no change required". If you=20 have feedback one way or another, please send this in this thread. Best Regards, Alexey, as a co-chair (*) I would usually ask for 2 weeks, but this issue might possibly=20 requires writing a draft, so giving it a bit more time. From nobody Tue Jan 19 07:23:35 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DE23A15A2 for ; Tue, 19 Jan 2021 07:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=-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 (2048-bit key) header.d=fastmail.fm header.b=wVwVbjxP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AyLVRicL 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 nrF_ftDbJpxW for ; Tue, 19 Jan 2021 07:23:32 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6137B3A15A3 for ; Tue, 19 Jan 2021 07:23:32 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id BD42E1C7; Tue, 19 Jan 2021 10:23:30 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Tue, 19 Jan 2021 10:23:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=8/A3ACH23CgcPKSn/sXXiOsx7qsk8o9 0V8XQOKabWKk=; b=wVwVbjxP85NGAaP43gxIXrMPfwPn4lUeBI1xSHJe59kn3SR lzt83B4oVq6B8pqT5SCNmHBuye98TGVxi6ikiYU9PjEswMlIhTaPIISuwYL095/3 jk2fNE5pi7q4det1SIT8GLPUowxYI4B9TFutlOogw4yHgOJ/thKdrPHv1isY+DRP OWdAvVO5Q97C79pFjtLxU1TEE+MUBNbMD1HYiAamCL7O07Iqev5CKP4hCpPLC+cw PG2mF10Sb5rC867pCiX61jqTpKPYwCk32B2s7M9SAJiOnOsD/uWVuRt/kMSQTy0V prwK5IJgIYBVtjdEXNH5rbnt2eLemaqBizaTKIg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=8/A3AC H23CgcPKSn/sXXiOsx7qsk8o90V8XQOKabWKk=; b=AyLVRicL+d9mE5PFbCPauN AGhagndC0VmqkJ12hlxHbemaKuPw8DEXbplKs+UlL/NPnmFq5tCVbglZzlkvXYgk fwEws+vZ0ACdsZYk/Am8rK8svL2ZO8B4lMQrPH8uBboaE1DCQmIwmnbotLfz8Q6i f4uARlO1QiOaMoCv5Dg/0G83iExctacN2yJr+nPNdl1bqTkXpf1cKYyaQmfgtm/p UGnblO9CfHsMknzT9FDGygKdjvQQqQ0Y+mbV+EjDNhUY3n9XxAkc1mWoNXr8Hvud DI4pBp2M10V+3AivPWt8AGjP8ARPCn2nLOf9zdn06Lyhpfyo1T8gIWjvJPwAHnlA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddtgdejiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucggtffrrghtthgvrhhnpeeitdeuhedthfevvdethfegledufeeugfdvjedvheeh feevuedtgedufeegudfhtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A2CB36F60065; Tue, 19 Jan 2021 10:23:29 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-45-g4839256-fm-20210104.001-g48392560 Mime-Version: 1.0 Message-Id: In-Reply-To: <47407afa-6e6a-d0d2-a829-67d68fd0ee90@tana.it> References: <20201217034150.AA9142AC1E50@ary.qy> <76CF0B1097EB28A5BDE902EE@PSB> <47407afa-6e6a-d0d2-a829-67d68fd0ee90@tana.it> Date: Tue, 19 Jan 2021 15:23:09 +0000 From: "Alexey Melnikov" To: "Alessandro Vesely" , "John C Klensin" Cc: emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: [Emailcore] =?utf-8?b?VGlja2V0ICMxMzogRy43LjcuIERvZXMgdGhlICdm?= =?utf-8?q?irst_digit_only=27_and/or_non-listed_reply_code_text_need_clari?= =?utf-8?q?fication=3F?= X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 15:23:34 -0000 Hi, I've changed the subject to reflect the correct ticket number. Commenting on the substance below. On Thu, Dec 17, 2020, at 1:54 PM, Alessandro Vesely wrote: > On Thu 17/Dec/2020 05:46:29 +0100 John C Klensin wrote: > > --On Wednesday, December 16, 2020 22:41 -0500 John Levine wrote: > >> In article <6A1255A557C666DF96E19DB9@PSB> you write: > >>> "It should use information in the other digits of the > >>> code and any supplemental codes or information (see RFC > >>> 3463) only if it recognizes them and to provide > >>> additional information as needed but should rely on that > >>> first digit if the additional information is not > >>> recognized." > >> > >> That seems utterly obvious, which I suppose means we should be > >> sure to include it. > > > > The discussion did come up on the mailing list and it is > > possible --although I admit it is a stretch-- to read "Whenever > > possible, a sender-SMTP SHOULD test the first digit (severity > > indication) of a reply code it receives" as meaning "sometimes > > it should not test even that" or leaving questions about what to > > do with the test open. > > > Yeah, especially when comparing that SHOULD with the fact that the first digit > MUST be checked if the response code is not recognized. As if it were more > difficult to check the first digit than the whole response code. Perhaps, > reading is easier if "Whenever possible" is replaced by something like "If the > sender-SMTP does not know how to deal with a specific response code". > > Actually, only some response codes are better understood in their entirety, > e.g. 421. The rest are for logging and offline pondering. I tend to agree. How about the following strawman proposal: OLD: Whenever possible, a sender-SMTP SHOULD test the first digit (severity indication) of a reply code it receives. NEW: Sender-SMTP tests the whole 3 digit reply code it receives and any supplemental codes or information (see RFC 3463 and RFC 5248) if it recognizes them. Sender-SMTP MUST use the first digit (severity indication) of a reply code it receives if the full reply code or additional information is not recognized. ? (Can additionally change "Sender-SMTP tests" to "Sender-SMTP SHOULD test" in the first replacement sentence) Best Regards, Alexey From nobody Tue Jan 19 07:32:19 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC953A15B5 for ; Tue, 19 Jan 2021 07:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 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.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 qxSTPekvHSGB for ; Tue, 19 Jan 2021 07:32:16 -0800 (PST) Received: from coral.ash.relay.mailchannels.net (coral.ash.relay.mailchannels.net [23.83.222.39]) (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 A50263A08D6 for ; Tue, 19 Jan 2021 07:32:14 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 560CF23029; Tue, 19 Jan 2021 15:32:11 +0000 (UTC) Received: from nl-srv-smtpout1.hostinger.io (100-96-87-139.trex.outbound.svc.cluster.local [100.96.87.139]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 298B7204EC; Tue, 19 Jan 2021 15:31:59 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout1.hostinger.io ([UNAVAILABLE]. [185.224.136.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/6.0.1); Tue, 19 Jan 2021 15:32:11 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Cellar-Well-Made: 65c34e946322678a_1611070321016_1556498924 X-MC-Loop-Signature: 1611070321016:3026152204 X-MC-Ingress-Time: 1611070321015 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout1.hostinger.io (smtp.hostinger.com) with ESMTPSA id A149F20297F3; Tue, 19 Jan 2021 15:31:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1611070317; bh=QsJwj19ADRT2psTGx2fPeIP/nodu8wAcqtiQHhIu2bk=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=XnuWjgSEwtbm3Dr+JqtRHbo1ta86gapv8+r/GPLWPV90ubvNcr/dI14ofYehEE7yx a6eP1r97JAJxScfgI1o3Hdnwoz1N11qKMGy8s50jsv0s8AJBCQo4H/wn5X+MvyKeVb huUw8GhZ990xXdklfTyul+ZGT5O2p98FUTEumC9S4Prjr3K8RtDs89sonLldqcn4Sd YgJk1QmawqKsCbArqXwJx7oZZ0EWp6UIBJTynvreNDShKB6TxYmeZsCpBO4GqUyoHk DkEBaZhWAupQI6DNr3u8TQhkIHd4zmudGjqWBC7dyrdj2oY1WvUmBUXQf1qsxPXYLx eWyoXFyejr/7A== Reply-To: dcrocker@bbiw.net To: Alexey Melnikov , Alessandro Vesely , John C Klensin Cc: emailcore@ietf.org References: <20201217034150.AA9142AC1E50@ary.qy> <76CF0B1097EB28A5BDE902EE@PSB> <47407afa-6e6a-d0d2-a829-67d68fd0ee90@tana.it> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <8a9a363a-68dd-80ed-2ff2-b4d19fb74359@dcrocker.net> Date: Tue, 19 Jan 2021 07:31:50 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #13: G.7.7. Does the 'first digit only' and/or non-listed reply code text need clarification? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 15:32:18 -0000 On 1/19/2021 7:23 AM, Alexey Melnikov wrote: > NEW: Sender-SMTP tests the whole 3 digit reply code it receives and > any supplemental codes or information (see RFC 3463 and RFC 5248) if > it recognizes them. Sender-SMTP MUST use the first digit (severity > indication) of a reply code it receives if the full reply code or > additional information is not recognized. Given the normative term in the second sentence it seems odd -- and possibly problematic -- to have no normative term in the first sentence. I assume the intention here is: Sender-SMTP MUST first test the whole 3 digit reply code it receives, as well as any accompanying supplemental codes or information (see RFC 3463 and RFC 5248). If the full reply code or additional information is not recognized, Sender-SMTP MUST use the first digit (severity indication) of a reply code it receives d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jan 19 07:41:44 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D157C3A15BE for ; Tue, 19 Jan 2021 07:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=-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 (2048-bit key) header.d=fastmail.fm header.b=YhgnmhMk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=L1bhucXL 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 jAHpCOkh-22k for ; Tue, 19 Jan 2021 07:41:41 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6553A15BD for ; Tue, 19 Jan 2021 07:41:41 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id A2A31AB0 for ; Tue, 19 Jan 2021 10:41:39 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Tue, 19 Jan 2021 10:41:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=tH7GE xZpdgD8rdycL14jUexc7Poxj0dXSOMUNPFhUHI=; b=YhgnmhMk3uq4et+TMz9I4 tuINWzSNsTkPMXmH3Zm4cPZaTSbyRZEJf3DjxBjPfAVUS0Uh/QNP7XvV9X362rdU rUTZMEMsn/ieL24AD3TPDJY+8gWDiNQhPVKGfQo7SF7LsfAvHpb47LlHGoJIiD8v J1a15sq1FOaoH++RUAUndfwGoyIFkdqqlyZI5tzPPd+Apn4/a1NMlHccVGU+fLHa U1Wt6W/jbRIgX8NZbXGjK9EhQ5aLLyqgIx/cyKEf5ayrmlaonE57X6xSWmpjMqB/ tzfoHBafE+fu3FC7w6HKEaeFV92WAtbmZmReaNeA7Y6WcQFOFa5aZpWTHfiF4AB9 g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=tH7GExZpdgD8rdycL14jUexc7Poxj0dXSOMUNPFhU HI=; b=L1bhucXLqtoB1MCVJ9XZ14pgPDPq7a1o+d/DWtKzaxugNYqvXmrUvt5YL 21rgmz9nPf0YshejVZu8u91d/8SvVlj9VqsSLeYfb29BeG1a8tDw9AbO3EyVQCfO mPdsqs+gcT8+FWFjou3MseUoPlFbS5IlVPxOFPwiLSe/mnChm31SmZxatq3aEHkd E9O3bIDxGmxTC0sjGX2aExC4veEGBYUHT+xxJGLzrPdoEZkUGAsQgPKWHpHGofvf AqvMn0l2Tx4gNwTN0LR6Dx07oRWIZOcNQXK4WLMXD+bGBBXR5AfidTK74jeMHtns NTd7IxFN5GF1TQQz9cyx72XU4uCPQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddtgdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedftehlvgigvgihucfovghlnhhikhhovhdfuceorggrmhgv lhhnihhkohhvsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtthgvrhhnpeelieffle euueefkeeljeefieehgeejtddvtdduffeufeevveeftdefkeeuudevffenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovh esfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BDDB06F60066; Tue, 19 Jan 2021 10:41:38 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-45-g4839256-fm-20210104.001-g48392560 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <9ABCA62E3E54C4356D09E1EE@PSB> <20201217205413.D68C32AC973F@ary.qy> <01RTABPBJB7C004QVR@mauve.mrochek.com> <43b5a838-c94b-7690-c62f-8ef69aeb338@taugh.com> <7d8d3332-209e-85d9-957c-dec9c0e4c830@tana.it> Date: Tue, 19 Jan 2021 15:41:17 +0000 From: "Alexey Melnikov" To: emailcore@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Emailcore] RESOLVED: Ticket #43: G.13. Deprecating HELO X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 15:41:43 -0000 Hi all, [Top post] I changed the subject for ease of searching. As per discussion, I propose to resolve this ticket as "no change". Best Regards, Alexey On Fri, Dec 18, 2020, at 8:24 PM, John C Klensin wrote: >=20 >=20 > --On Friday, December 18, 2020 17:47 +0000 Alexey Melnikov > wrote: >=20 > > On Fri, Dec 18, 2020, at 5:23 PM, Alessandro Vesely wrote: > >> On Fri 18/Dec/2020 02:24:26 +0100 John R Levine wrote: > >> > On Thu, 17 Dec 2020, Ned Freed wrote: > >> >> There's still quite a few HELO's being sent by IOT stuff > >> >> that supports email. And I can understand why - when every > >> >> byte counts, code to fall back from EHLO to HELO isn't > >> >> going to be written. > >> >=20 > >> > Is that SMTP or submission?=C2=A0 I think we will continue to > >> > tolerate a lot more sloppiness in submission than in SMTP > >> > relay. > >>=20 > >>=20 > >> What is going to be gained by not tolerating HELO on port 25 > >> any more? The server code is not going to shrink > >> considerably, especially if the same code also supports port > >> 587. > >>=20 > >> Sometimes I use HELO for a quick test with telnet[*] if for > >> some reason I don't want the terminal window to scroll by > >> the amount of lines that EHLO responses imply. > >=20 > > [As a participant] > >=20 > > For reasons stated by Alessandro and Ned I have a weak > > preference to leave HELO as is in rfc5321bis. >=20 > (As a participant and for the same reasons) > I share that preference >=20 > (And, as author) > I recommend that the bar for making substantive changes, even > to drop things previously required or allowed, should be fairly > high. My inclusion of that item was because I found it in my > notes from prior suggestions and comments; it was not a > recommendation for any particular action. >=20 > john From nobody Tue Jan 19 07:56:58 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463B93A15D3 for ; Tue, 19 Jan 2021 07:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=-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 (2048-bit key) header.d=fastmail.fm header.b=GAso98dv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LPOG9CNs 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 HVTlCC133AEY for ; Tue, 19 Jan 2021 07:56:55 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3C73A1338 for ; Tue, 19 Jan 2021 07:56:55 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id DF963CC1; Tue, 19 Jan 2021 10:56:53 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Tue, 19 Jan 2021 10:56:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=1BFuRlyFmV84NOpYc2hKv/NLzAfGqjd 0kiKoNz93o0c=; b=GAso98dvC4yunr843b2GznPRqRi7axD86dbURGsxtYfvZ0/ NRDVZd4qOVkjusN1fb0hEYMIDbnyzl4u38djG6li5vvw8CPhF5Pl0sXEkH17uN34 tI/wZo4mTWLibJw21TbhohMGGBvHz0sYwYKOWhCJsrgqvTkjEtp6Wj9QS0MJuWgR QZAyDvFeKfIfYhWHENZi/1dI6Xnp+BFt4dM0KaEdqJ0ZI2fQPBUdH7LF57440oIG KsEfxlWsF9jVsgvBVDyz/J86RhsZvd5Na0tUhveMD6q4bTzslGBSh6VMI81T72BN mH1aipKDjYWbfgqY7I5LJjhDQ15fsZHI2OGvydw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=1BFuRl yFmV84NOpYc2hKv/NLzAfGqjd0kiKoNz93o0c=; b=LPOG9CNsohvixDNL47/FYI D7hf+fZJD9+uYbYjkzDcVLZEf/MFWBPa0nvwe2Ok1RcAUddyr1ap2+eB/FpNdv3S 1h+/rc8U4msBcG2WRvkQ9bOdcMJk5io/flZGKOAT1y9aKR4o9SZ3K98MexepUlno BZnQVZO1T0dKLEhZZXNm6zIWt0VxIAcdQT6qu2UgvPbGKhRhKKb9qpt+Ya54Zjl1 PN1t51u4gKMwrcDE7Hd0YYfOFxBXgObdW/mbsu+ryYZtCEAoEL9mfmNcfGi64yFh ZnQLWmIgrfjffDQBjPwbh3lwcApqScjUF8BKxgT5qI8+8hnzSqshfmEL+eVfFatQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddtgdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucggtffrrghtthgvrhhnpeeitdeuhedthfevvdethfegledufeeugfdvjedvheeh feevuedtgedufeegudfhtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DF8E16F60060; Tue, 19 Jan 2021 10:56:52 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-45-g4839256-fm-20210104.001-g48392560 Mime-Version: 1.0 Message-Id: <919ecdc5-1934-4a1b-8a1a-bbe0bb79c95d@www.fastmail.com> In-Reply-To: <8a9a363a-68dd-80ed-2ff2-b4d19fb74359@dcrocker.net> References: <20201217034150.AA9142AC1E50@ary.qy> <76CF0B1097EB28A5BDE902EE@PSB> <47407afa-6e6a-d0d2-a829-67d68fd0ee90@tana.it> <8a9a363a-68dd-80ed-2ff2-b4d19fb74359@dcrocker.net> Date: Tue, 19 Jan 2021 15:56:32 +0000 From: "Alexey Melnikov" To: "Dave Crocker" , "Alessandro Vesely" , "John C Klensin" Cc: emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] =?utf-8?b?VGlja2V0ICMxMzogRy43LjcuIERvZXMgdGhlICdm?= =?utf-8?q?irst_digit_only=27_and/or_non-listed_reply_code_text_need_clari?= =?utf-8?q?fication=3F?= X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 15:56:56 -0000 On Tue, Jan 19, 2021, at 3:31 PM, Dave Crocker wrote: > On 1/19/2021 7:23 AM, Alexey Melnikov wrote: > > NEW: Sender-SMTP tests the whole 3 digit reply code it receives and > > any supplemental codes or information (see RFC 3463 and RFC 5248) if > > it recognizes them. Sender-SMTP MUST use the first digit (severity > > indication) of a reply code it receives if the full reply code or > > additional information is not recognized. > > > Given the normative term in the second sentence it seems odd -- and > possibly problematic -- to have no normative term in the first sentence. > > > I assume the intention here is: > > Sender-SMTP MUST first test the whole 3 digit reply code it > receives, as well as any accompanying supplemental codes or information > (see RFC 3463 and RFC 5248). If the full reply code or additional > information is not recognized, Sender-SMTP MUST use the first digit > (severity indication) of a reply code it receives. Your proposed version is better, thank you. From nobody Tue Jan 19 08:11:51 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838A73A15EA for ; Tue, 19 Jan 2021 08:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 MpYEg8bxDuF3 for ; Tue, 19 Jan 2021 08:11:48 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 137373A15E7 for ; Tue, 19 Jan 2021 08:11:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1611072707; d=isode.com; s=june2016; i=@isode.com; bh=2izWLe2FMEhlLAGKAHBHiZ9fObK2y8JePLH4t8pEMu4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=WcPXzKg0RysfC+qV8vOPl6g+iZnmr1gh/fLQxZibH7f3d6NJOAf0ve598CQ+5ujku+AyK4 IfiY3x//s3DIzJIMUvuYxWLbtms3X/fJMXaxjaJjSHk8J+eYC3qpzoy0bGSklNcFeil0IS sU7G9uSKKoN2a1IuiGcorNyCB7OKUIU=; Received: from [172.27.250.167] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 19 Jan 2021 16:11:46 +0000 To: emailcore@ietf.org, Arnt Gulbrandsen From: Alexey Melnikov Message-ID: Date: Tue, 19 Jan 2021 16:11:45 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [Emailcore] Ticket #15: G.7.9. Discussion of 'blind' copies and RCPT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 16:11:50 -0000 Dear collegues, The 1st pagaraph of Section 7.2 ("Blind" Copies) currently says: =C2=A0 Addresses that do not appear in the message header section may appea= r =C2=A0 in the RCPT commands to an SMTP server for a number of reasons. The =C2=A0 two most common involve the use of a mailing address as a "list =C2=A0 exploder" (a single address that resolves into multiple addresses) =C2=A0 and the appearance of "blind copies". Especially when more than one =C2=A0 RCPT command is present, and in order to avoid defeating some of the =C2=A0 purpose of these mechanisms, SMTP clients and servers SHOULD NOT cop= y =C2=A0 the full set of RCPT command arguments into the header section, =C2=A0 either as part of trace header fields or as informational or private= - =C2=A0 extension header fields. Suggested replacement for the last sentence quoted above (as per=20 feedback from Arnt Gulbrandsen): =C2=A0 When more than one =C2=A0 RCPT command is present, and in order to avoid defeating some of the =C2=A0 purpose of these mechanisms, SMTP clients and servers SHOULD NOT cop= y =C2=A0 any of RCPT command arguments into the header section, =C2=A0 either as part of trace header fields or as informational or private= - =C2=A0 extension header fields. (This removes "especially" and replaces "the full set of" with "any" --=20 copying the first one can be as harmful as copying all of them, at least=20 without verifying that the addresses do appear in the headers.) Please provide feedback on this proposal within 2 weeks. Best Regards, Alexey From nobody Tue Jan 19 08:14:12 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5016E3A15EA for ; Tue, 19 Jan 2021 08:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 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.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 jIOXd5j6mcyG for ; Tue, 19 Jan 2021 08:14:07 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id B904D3A15E7 for ; Tue, 19 Jan 2021 08:14:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1611072847; d=isode.com; s=june2016; i=@isode.com; bh=/mB1/81wIvpFLPlzzphMboBJ1yTg+vaR4XpcBXEXAmk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=E2Mndi5Pa+fqJkHzHV3S57GruRxDS2zf1UgOT29yyiTndmysQQNjTWRNbWKlyaXI+7T7VP 2WL2lAh3LQtsvU1FC5xjuOICdfSJcYjDpxZus2p4FAVecHGv1ppoTO4Pi2X/07HPDe4hzI 69htLtl+k6C+mC9kQB4u2oPAp48fAck=; Received: from [172.27.250.167] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 19 Jan 2021 16:14:06 +0000 From: Alexey Melnikov To: emailcore@ietf.org References: Message-ID: <5739eec7-ce97-fb3e-5f43-ca282c129238@isode.com> Date: Tue, 19 Jan 2021 16:14:05 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Ticket #15: G.7.9. Discussion of 'blind' copies and RCPT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 16:14:09 -0000 Hi again, Also, John Klensin asked: May also need to discuss whether that=20 terminology is politically incorrect and suggest a replacement. My reply as a participant: =C2=A0I think CC and BCC are well established terms, so changing it now is= =20 going to cause more harm then good. Besides I don't have any better=20 proposal. Best Regards, Alexey From nobody Tue Jan 19 08:25:01 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE4C3A15F0 for ; Tue, 19 Jan 2021 08:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 giWosM_57le0 for ; Tue, 19 Jan 2021 08:24:58 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id EADF33A15EB for ; Tue, 19 Jan 2021 08:24:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1611073497; d=isode.com; s=june2016; i=@isode.com; bh=B9oiQr1byktSrFu2z/HjdrrzAV4zaVBAM3Nv7z8mZ84=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=p4LKnTM2ZohhFyoRKHVaDaK/FId+/jIXiqn7NB0PyDSCg8KVBxrJf1ArmFdRkYzfm/zPPU Ov1qa7mF5pegCiDAXyqRuMJ3X/aHnDarha+Bzhzzqi/6EPxf4w/k2UVV4NAYwoTmTBfdLU 1EkBoSImqibwT26Rzhw5iVucOkw+wMU=; Received: from [172.27.250.167] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 19 Jan 2021 16:24:56 +0000 To: emailcore@ietf.org From: Alexey Melnikov Message-ID: Date: Tue, 19 Jan 2021 16:24:55 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 16:24:59 -0000 Hi all, The first pagaraph of Section 4.5.3.1.10 (Too Many Recipients Code)=20 currently says: =C2=A0=C2=A0 RFC 821 [3] incorrectly listed the error where an SMTP server =C2=A0=C2=A0 exhausts its implementation limit on the number of RCPT comman= ds =C2=A0=C2=A0 ("too many recipients") as having reply code 552.=C2=A0 The co= rrect reply =C2=A0=C2=A0 code for this condition is 452.=C2=A0 Clients SHOULD treat a 5= 52 code in =C2=A0=C2=A0 this case as a temporary, rather than permanent, failure so th= e logic =C2=A0=C2=A0 below works. John noted that this suggestion may have outlived its usefulness and/or be inconsistent with current practice. Should it be removed and/or explicitly deprecated? Best Regards, Alexey From nobody Tue Jan 19 09:07:35 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052683A1639 for ; Tue, 19 Jan 2021 09:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 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.262, 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 Z72LDlWhL6ol for ; Tue, 19 Jan 2021 09:07:32 -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 9C4033A15DC for ; Tue, 19 Jan 2021 09:07:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1611076049; bh=9BmMMPh56C1+2nRI+Kdg6XrspU1HymGr005uvx6pzDU=; l=1911; h=To:References:From:Date:In-Reply-To; b=BgFnesIjgTsXe0uRjo7rw0aGlAGcmdXu2INtgAGvWutrOxJKtpY1F93nupOCLBlot Mu4YGqJxUKeckyZlTAr+SK4VyzUlDOe4osvx8QcF62SCSctg8SPsCOGYOta8oWtKJC HHefOEjHg6IbXXY1qgbCeCBsGtETkCxzSfxQgZyK5JpiIE7BIG2RPPKXbXKUZ Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC053.00000000600711D1.00004B10; Tue, 19 Jan 2021 18:07:29 +0100 To: emailcore@ietf.org References: From: Alessandro Vesely Message-ID: Date: Tue, 19 Jan 2021 18:07:28 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #15: G.7.9. Discussion of 'blind' copies and RCPT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 17:07:34 -0000 On Tue 19/Jan/2021 17:11:45 +0100 Alexey Melnikov wrote: > Dear collegues, > > The 1st pagaraph of Section 7.2 ("Blind" Copies) currently says: > >   Addresses that do not appear in the message header section may appear >   in the RCPT commands to an SMTP server for a number of reasons. The >   two most common involve the use of a mailing address as a "list >   exploder" (a single address that resolves into multiple addresses) >   and the appearance of "blind copies". Especially when more than one >   RCPT command is present, and in order to avoid defeating some of the >   purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy >   the full set of RCPT command arguments into the header section, >   either as part of trace header fields or as informational or private- >   extension header fields. > > Suggested replacement for the last sentence quoted above (as per feedback from > Arnt Gulbrandsen): > >   When more than one >   RCPT command is present, and in order to avoid defeating some of the >   purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy >   any of RCPT command arguments into the header section, >   either as part of trace header fields or as informational or private- >   extension header fields. > > (This removes "especially" and replaces "the full set of" with "any" -- copying > the first one can be as harmful as copying all of them, at least without > verifying that the addresses do appear in the headers.) > > Please provide feedback on this proposal within 2 weeks. Having removed "especially", we could raise to MUST NOT. Were there other circumstances that would allow violating the SHOULD NOT? Anyway, this Section deserves a comefrom Section 4.4. That is, for example: For = CFWS "FOR" FWS ( Path / Mailbox ) ; Not if multiple recipients, see Section 7.2 Best Ale -- From nobody Tue Jan 19 09:44:34 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6353A1672 for ; Tue, 19 Jan 2021 09:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=CoaNuRWR; dkim=pass (2048-bit key) header.d=wizmail.org header.b=h7UH75Ba 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 nPrWviMSkVoJ for ; Tue, 19 Jan 2021 09:44:30 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 59FBD3A1671 for ; Tue, 19 Jan 2021 09:44:29 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Subject:From:References:To:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=IOWw2B0Kio2Vm6v3ndUUKszHk9nTD8U2PHBG7iLaw1E=; b=CoaNuRWRfcFzMfGm7jMIu7klhv XxcdwFQTc3Y2DMLQMvkLHWmuHKxRGdNNVcDAkV+nydA912d2RmuQYjSa5pCw==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Subject:From:References:To:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=IOWw2B0Kio2Vm6v3ndUUKszHk9nTD8U2PHBG7iLaw1E=; b=h7UH75BanYBeJffgC5KiNFOYOd v5ep5OJ8mEJhiLdp9nayCUe3BHXwOjfoHvLtO+6eBzxtrq0B32vhlOQ+3JxLWs1L/vRPvzsS0PnVZ 7N4FRCUQCfttsCohy/xd8Hl3l6737MSdOl6+5R3u+951igbl91w8L+Jk5BM03MfGIATfVjl/81asj 5bmCspeYg5c/3vNPsYKezSZMo5A7p4gS1+ONldtoX5qRoP8vLXeIDVU9k9e2FhDtvzxsTm0AEUXL6 jFcIbZu2x/E+0wa1Ep+to5gCrmpAi9ZRuV1C7XjVZfj8H0cmH6L1GpXo6BC5gELrPbatRLCRke7xs s3PxRkLQ==; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.94.111) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1l1v3J-003yku-09 for emailcore@ietf.org (return-path ); Tue, 19 Jan 2021 17:44:25 +0000 To: emailcore@ietf.org References: From: Jeremy Harris Message-ID: <0ca0c0c6-632d-62bb-ed98-361ae4424fa7@wizmail.org> Date: Tue, 19 Jan 2021 17:44:22 +0000 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: [Emailcore] Received: header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 17:44:33 -0000 On 19/01/2021 17:07, Alessandro Vesely wrote: > Anyway, this Section deserves a comefrom Section 4.4.  That is, for example: > >    For            = CFWS "FOR" FWS ( Path / Mailbox ) >                   ; Not if multiple recipients, see Section 7.2 Diverging topic, sorry. Is it strictly needed to shout "FOR" here? I notice that Exim currently, in its default, uses lower-case "for"; and similar "by", "id" and "with". This code dates from 1996. -- Cheers, Jeremy From nobody Tue Jan 19 09:47:24 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8A63A1672 for ; Tue, 19 Jan 2021 09:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 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.262, 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 iHmv0C_PFkVk for ; Tue, 19 Jan 2021 09:47:21 -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 084943A175A for ; Tue, 19 Jan 2021 09:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1611078420; bh=SQCeWrzNzopJcHvr5oqvWYGMlB9IPdkvhEtKUM9X1HM=; l=2872; h=To:References:From:Date:In-Reply-To; b=BEkWUC5ebJiBGbY7z+hWSziUBl1LiMqQuLL7PVij08KxRo0CEamrpFItzJHpAxsh3 7qRNtUiajorU/C9TeDVa40keFMBXtB+x3+IkiSanSZ9kuLzpBKTEhPj98xcfZtWxkW XQNZtJ+3I3BsPxCXV1Yn7+VtUYhZEGZbddwX/wlPDRDg11ax3KJ9CFqFx9FHr Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC0C3.0000000060071B14.00005069; Tue, 19 Jan 2021 18:47:00 +0100 To: emailcore@ietf.org References: From: Alessandro Vesely Message-ID: Date: Tue, 19 Jan 2021 18:46:59 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 17:47:23 -0000 On Tue 19/Jan/2021 17:24:55 +0100 Alexey Melnikov wrote: > > The first pagaraph of Section 4.5.3.1.10 (Too Many Recipients Code) currently > says: > >    RFC 821 [3] incorrectly listed the error where an SMTP server >    exhausts its implementation limit on the number of RCPT commands >    ("too many recipients") as having reply code 552.  The correct reply >    code for this condition is 452.  Clients SHOULD treat a 552 code in >    this case as a temporary, rather than permanent, failure so the logic >    below works. > > John noted that this suggestion may have outlived its usefulness > and/or be inconsistent with current practice. Should it be removed > and/or explicitly deprecated? Yes, at least the last sentence (Clients... works.) should go away. In that case, the parenthesized snippets two paragraphs below should be removed to. The end of that section is not clear to me. AIUI, I'd change it like so: OLD: If an SMTP server has an implementation limit on the number of RCPT commands and this limit is exhausted, it MUST use a response code of 452 (but the client SHOULD also be prepared for a 552, as noted above). If the server has a configured site-policy limitation on the number of RCPT commands, it MAY instead use a 5yz response code. In particular, if the intent is to prohibit messages with more than a site-specified number of recipients, rather than merely limit the number of recipients in a given mail transaction, it would be reasonable to return a 503 response to any DATA command received subsequent to the 452 (or 552) code or to simply return the 503 after DATA without returning any previous negative response. NEW: If an SMTP server has an implementation limit on the number of RCPT commands and this limit is exhausted, it MUST use a response code of 452. If the server has a configured site-policy limitation on the number of RCPT commands, it MAY instead use a 5yz response code. In particular, if the intent is to prohibit messages with more than a site-specified number of recipients, rather than merely limit the number of recipients in a given mail transaction, it would be reasonable to return a 503 response to any DATA command received subsequent to the 552 code. I omitted "or to simply return the 503 after DATA without returning any previous negative response." 503 is "Bad sequence of commands". The omitted phrase says it makes sense to issue 503 after a sequence of positive RCPTs, and I cannot see anything wrong in that sequence. 552 makes sense if, in response to the nth RCPT command, the server got a memory fault. For example, it called realloc() with a size argument of 0 due to overflow, realloc() returned NULL, so the server lost the whole buffer and replied 552. It could not accept DATA. Best Ale -- From nobody Tue Jan 19 09:48:29 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB863A0C01 for ; Tue, 19 Jan 2021 09:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 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.262, 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 1F4Lqvvmd6d4 for ; Tue, 19 Jan 2021 09:48:26 -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 9FCD63A0B2F for ; Tue, 19 Jan 2021 09:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1611078505; bh=WdxiofN7WY7wl0kRdOrr/PlrDQd5iJN5sM1xpzn8A34=; l=138; h=To:References:From:Date:In-Reply-To; b=BJxRIYOYAwgNnrBpIkqVjTurTj4ikWfGavjzi+BmMnjfuUipTDrWB8B2Sh5/o0WR2 aRK/8nSSNhFrGxPREZThlfGI56woYgVEgpx5S4NxvxOssaBnOR3zzyfYUWZIGyIWiW L6Zk6oTeDJjWBVvRoRPd3GIS7aW/PjVJ4CJwl6ht+FWG0nvAeVI9wjR/B/SLj Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely 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 00000000005DC0CE.0000000060071B68.000050C6; Tue, 19 Jan 2021 18:48:24 +0100 To: emailcore@ietf.org References: <9ABCA62E3E54C4356D09E1EE@PSB> <20201217205413.D68C32AC973F@ary.qy> <01RTABPBJB7C004QVR@mauve.mrochek.com> <43b5a838-c94b-7690-c62f-8ef69aeb338@taugh.com> <7d8d3332-209e-85d9-957c-dec9c0e4c830@tana.it> From: Alessandro Vesely Message-ID: <81c7b093-268a-3ee1-d2bc-9f5a25fef7fe@tana.it> Date: Tue, 19 Jan 2021 18:48:23 +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: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] RESOLVED: Ticket #43: G.13. Deprecating HELO X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 17:48:28 -0000 On Tue 19/Jan/2021 16:41:17 +0100 Alexey Melnikov wrote: > > As per discussion, I propose to resolve this ticket as "no change". +1 From nobody Tue Jan 19 18:37:17 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5B23A0C60 for ; Tue, 19 Jan 2021 18:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 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, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=AvKNDqIT; dkim=pass (2048-bit key) header.d=taugh.com header.b=PPLVbEbW 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 6vqIkdsBjUcX for ; Tue, 19 Jan 2021 18:37:15 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 15FD53A0BF9 for ; Tue, 19 Jan 2021 18:36:29 -0800 (PST) Received: (qmail 22415 invoked from network); 20 Jan 2021 02:36:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=578d.6007972c.k2101; bh=Z55sh8C2wdBmQ/dWf1HNSYZyPpUmeCy9Rj1Tt8/jqkU=; b=AvKNDqITm5kKrHFvjwUC0bE1rcijAVpI0OT7g2AAarVIq5n8ExotuZRQVjnXE6GNLzthGrgfsy4tvworZ2IoGZOOu7kq6p3S19aPmXvRbBR8uqdnVMT2QaoNukla1pScn9amNnnze8STMYuH44HsPOtF9j+i5yLCSYyvj7JBwChdrAxZlqDzvWY9xIP9FGwF2YAJrHCcdtbG5V7FH3DqeUueMHVh7RmBJ3V75xdM/Wng20lG9KZ6D0rO4b/EfE3LrIifLJmLPwGNUmU62jvoNO1Tk3xZ7BSRbdt33mmxzI9OdAq2N6TbYKvHrNPxSnkofBVaFxrc5urO+KU1ucSc9A== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=578d.6007972c.k2101; bh=Z55sh8C2wdBmQ/dWf1HNSYZyPpUmeCy9Rj1Tt8/jqkU=; b=PPLVbEbWttn8/dg2F+eFwUa47h92oJEZET7ELMpY4DWUfNyuhhU/ZSwhCY25O6LVEUvBWCrF2wAc0w32FNMFtbkrEPBLCBDP1+I7PJL6sPpUmeaKXciDgIQJQvtR82R+PK1vHQ1WgPSo/qCln1hzPVYRJx8Gr2dvfjOGJaitzLKlvKjGhLri8NAaix4vk5uHcejPpBMdBiHBIx45I+jqbACodPfmhyZ7BvniiZ0KWa/puiXECbxY3KuhsjIeiM0DN80Mrc/I8MgT3Y/LheX4DJj3wbti/pOjtWVyoVtealMqO5r42zVP6rHYeo8jEpU9EXaw8Q9SFRH2hh2yrtTdZg== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 20 Jan 2021 02:36:28 -0000 Received: by ary.qy (Postfix, from userid 501) id F38826B7C8B3; Tue, 19 Jan 2021 21:36:27 -0500 (EST) Date: 19 Jan 2021 21:36:27 -0500 Message-Id: <20210120023627.F38826B7C8B3@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: jgh@wizmail.org In-Reply-To: <0ca0c0c6-632d-62bb-ed98-361ae4424fa7@wizmail.org> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Received: header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2021 02:37:16 -0000 In article <0ca0c0c6-632d-62bb-ed98-361ae4424fa7@wizmail.org> you write: >On 19/01/2021 17:07, Alessandro Vesely wrote: >> Anyway, this Section deserves a comefrom Section 4.4.  That is, for example: >> >>    For            = CFWS "FOR" FWS ( Path / Mailbox ) >>                   ; Not if multiple recipients, see Section 7.2 > >Diverging topic, sorry. Is it strictly needed to shout "FOR" here? In ABNF, upper and lower case ASCII have always been equivalent. There is a recent tweak in RFC 7405 to let you make strings case sensitive, but that of course doesn't apply to anything in 5321 or 5322. From nobody Mon Jan 25 15:29:22 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAD53A19FE for ; Mon, 25 Jan 2021 15:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 51xjdI_I5y0p for ; Mon, 25 Jan 2021 15:29:19 -0800 (PST) Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9410D3A19CC for ; Mon, 25 Jan 2021 15:29:19 -0800 (PST) Received: by mail-lj1-f169.google.com with SMTP id i17so17480689ljn.1 for ; Mon, 25 Jan 2021 15:29:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/KrsK6Ytep2lhNK+vioXxkxNSpijsJx/cX1kxPPcQSw=; b=AxLKzLoGDbTerkDweGkNxdTo/Jls5wId58zOALEHKi87rIjpt/b4y6AQDC+9z6tDX0 eSRmpzVc186QSat8G69jlW9TcN4adC+1sZp6UrwBXoJJiUS5UwdCin38mJIKeSDGAja4 AX9q2gXIrN3WMXCw1nz8vUpmQbJ+DQsydZCKghj/pnfikmG9w+v7xcUIpRccdSRAcbUT fEF2Of/xBA5BAjiqvbsYtrmKYUZL1B51JG5nnC+Sa9IIt6vofVvXOTDG5j9NdANJAXr6 5ElhO2FvxZsdbPQ44xIMZFmyolPipTA2Ft90LmUYvz2CdqLSZEdYDQWJwzC6liugOjDK PRMA== X-Gm-Message-State: AOAM5324f8qYTc1tq+kb4zNM626QJwp3wKp0Vh8h9pVGZmiDcjerDHPX tT+lq1rlPFhNDzvG/BJRltGhx2kNIPDl5wv2sQY5mwPI X-Google-Smtp-Source: ABdhPJzTfn54s2jgXucWPgoXrXtE/TbIqJJCFhlGQmY+wiWg6KhN4eHK35kE1ztV4jSAycP6UCc4fJzFdwocTBkIUTw= X-Received: by 2002:a2e:9049:: with SMTP id n9mr1353084ljg.473.1611617357179; Mon, 25 Jan 2021 15:29:17 -0800 (PST) MIME-Version: 1.0 From: Barry Leiba Date: Mon, 25 Jan 2021 18:29:06 -0500 Message-ID: To: "emailcore@ietf.org" Content-Type: multipart/alternative; boundary="00000000000016ad7b05b9c1e838" Archived-At: Subject: [Emailcore] Chair change for emailcore X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 23:29:21 -0000 --00000000000016ad7b05b9c1e838 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Emailcore folks, Seth Blank has asked to step down as chair: increased day-job responsibilities require him to cut back a little on IETF stuff. I have talked with Todd Herr, and am happy to bring him in as a new chair.[1] Thanks, Todd, for being ready and willing to step into the position. And thanks, Seth, for the work you=E2=80=99ve done until now. I=E2=80=99ll be = making the chnage in the datatracker soon. Barry, ART AD [1] Lest anyone wonder, the fact that Todd works for the same company as Seth is coincidental. I didn=E2=80=99t think about that when I considered = Todd... I only considered how good a job I think he=E2=80=99ll do. --00000000000016ad7b05b9c1e838 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Emailcore folks,

Seth Blank ha= s asked to step down as chair: increased day-job responsibilities require h= im to cut back a little on IETF stuff.

I have talked with Todd Herr, and am happy to bring him in a= s a new chair.[1]

Thanks= , Todd, for being ready and willing to step into the position.=C2=A0 And th= anks, Seth, for the work you=E2=80=99ve done until now.=C2=A0 I=E2=80=99ll = be making the chnage in the datatracker soon.

Barry, ART AD

[1] =C2=A0Lest anyone wonder, the fact that Todd works for the = same company as Seth is coincidental.=C2=A0 I didn=E2=80=99t think about th= at when I considered Todd... I only considered how good a job I think he=E2= =80=99ll do.
--00000000000016ad7b05b9c1e838-- From nobody Fri Jan 29 09:12:53 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597C93A1190 for ; Fri, 29 Jan 2021 09:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, FREEMAIL_FROM=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 (2048-bit key) header.d=fastmail.fm header.b=D3e6pw5c; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NOPhZ8op 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 iw1ZTol9urb5 for ; Fri, 29 Jan 2021 09:12:50 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11DBE3A118F for ; Fri, 29 Jan 2021 09:12:50 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 332E75C0067; Fri, 29 Jan 2021 12:12:49 -0500 (EST) Received: from imap37 ([10.202.2.87]) by compute1.internal (MEProxy); Fri, 29 Jan 2021 12:12:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm2; bh=jyqYi y4xADo+a89U04QLCa421dLcquCXHJrkS+afqLs=; b=D3e6pw5c0rRYsOulFVlq6 Uzqd/CX0pyc5qXKcVQpQpXAMGogAnTnstzRho/ZgB39QU3KByNK7Q7VJVyrv1wJF wTAlmV1k4VHgMVqRCEqYbjsfYEkahCxL7HB1cm/sVI5gQocsYbyy6g4KDhSPWOTW Zy0GV0KCx8MAvEmtRTydGu+VTlV45S6vy5/EGwVhvc7YCnpB3qeossFpFdooWZk+ U01JlduRjirJspZ04o31UEDCtQGc0Mvu5+TPP+twvMgtHjHbaXJY7Q6DO3BKrRbu iuCooBbI9OpsIihd6HzpAkLnW9rhM4Bg/VFCOTTjYkRn8wlsacDcb9Mw4BgL/jWQ w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=jyqYiy4xADo+a89U04QLCa421dLcquCXHJrkS+afq Ls=; b=NOPhZ8op46CNaLQVaBpBNV1WakMlxMpzt0Cl3dqEEr4N/K366XLYiCT7e 1WEYeASW5zerWxHwye+sRwmYqiqy36vPCRlTsjyCVLsURiFLKRP5MAT4Bwyccbqq Q5xGIWgV4R42SWCpWoqthn401TAwQdRX7k6pXlCJC374KqAVevPq5WoARmXySCuM zPVAI3Qs7+CeLdxaS5hWPbsjHyBG22st4OjUmgNB9KqJ/HfIhHwe6HpBoQY4+F9y sE57/m3TWvETKxe4gFVCU2AmBDkyXVp6uIHhhr/ykRAsOctEZn+oKxRb5nOkc9ng RTWb59dabcR8udiNtWayYVPKtVTog== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedvgdelkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuggftrfgrthhtvghrnhepleeiffelueeufeekleejfeeiheegjedtvddtudff ueefveevfedtfeekueduveffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DE14A6B4005F; Fri, 29 Jan 2021 12:12:47 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-84-gfc141fe8b8-fm-20210125.001-gfc141fe8 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 29 Jan 2021 17:12:09 +0000 From: "Alexey Melnikov" To: "Alessandro Vesely" , emailcore@ietf.org Cc: "Arnt Gulbrandsen" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] =?utf-8?q?Ticket_=2315=3A_G=2E7=2E9=2E_Discussion_of?= =?utf-8?q?_=27blind=27_copies_and_RCPT?= X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 17:12:51 -0000 Hi Alessandro, On Tue, Jan 19, 2021, at 5:07 PM, Alessandro Vesely wrote: > On Tue 19/Jan/2021 17:11:45 +0100 Alexey Melnikov wrote: > > Dear collegues, > >=20 > > The 1st pagaraph of Section 7.2 ("Blind" Copies) currently says: > >=20 > > =C2=A0 Addresses that do not appear in the message header section m= ay appear > > =C2=A0 in the RCPT commands to an SMTP server for a number of reaso= ns. The > > =C2=A0 two most common involve the use of a mailing address as a "l= ist > > =C2=A0 exploder" (a single address that resolves into multiple addr= esses) > > =C2=A0 and the appearance of "blind copies". Especially when more t= han one > > =C2=A0 RCPT command is present, and in order to avoid defeating som= e of the > > =C2=A0 purpose of these mechanisms, SMTP clients and servers SHOULD= NOT copy > > =C2=A0 the full set of RCPT command arguments into the header secti= on, > > =C2=A0 either as part of trace header fields or as informational or= private- > > =C2=A0 extension header fields. > >=20 > > Suggested replacement for the last sentence quoted above (as per fee= dback from=20 > > Arnt Gulbrandsen): > >=20 > > =C2=A0 When more than one > > =C2=A0 RCPT command is present, and in order to avoid defeating som= e of the > > =C2=A0 purpose of these mechanisms, SMTP clients and servers SHOULD= NOT copy > > =C2=A0 any of RCPT command arguments into the header section, > > =C2=A0 either as part of trace header fields or as informational or= private- > > =C2=A0 extension header fields. > >=20 > > (This removes "especially" and replaces "the full set of" with "any"= -- copying=20 > > the first one can be as harmful as copying all of them, at least wit= hout=20 > > verifying that the addresses do appear in the headers.) > >=20 > > Please provide feedback on this proposal within 2 weeks. >=20 >=20 > Having removed "especially", we could raise to MUST NOT.=20 Good point. > Were there other=20 > circumstances that would allow violating the SHOULD NOT? Personally, I can't think of any. I would be fine with MUST NOT. My question is: would MUST NOT break existing implementations and, if it= does, do we (as the WG) care? > Anyway, this Section deserves a comefrom Section 4.4. That is, for ex= ample: >=20 > For =3D CFWS "FOR" FWS ( Path / Mailbox ) > ; Not if multiple recipients, see Section 7.2 Sorry, I think I am missing your point here. I don't think the quoted AB= NF need to change? Best Regards, Alexey From nobody Fri Jan 29 09:29:20 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73273A11AD for ; Fri, 29 Jan 2021 09:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 rP4FpqmwLva0 for ; Fri, 29 Jan 2021 09:29:16 -0800 (PST) Received: from fossa.birch.relay.mailchannels.net (fossa.birch.relay.mailchannels.net [23.83.209.62]) (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 3D49C3A11A9 for ; Fri, 29 Jan 2021 09:29:15 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 24E367826F7; Fri, 29 Jan 2021 17:29:15 +0000 (UTC) Received: from nl-srv-smtpout2.hostinger.io (100-96-16-13.trex.outbound.svc.cluster.local [100.96.16.13]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id D367F7826BC; Fri, 29 Jan 2021 17:29:13 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout2.hostinger.io ([UNAVAILABLE]. [145.14.159.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.16.13 (trex/6.0.2); Fri, 29 Jan 2021 17:29:15 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Celery-Tank: 2c60c201590b8707_1611941354839_2494350654 X-MC-Loop-Signature: 1611941354839:986146968 X-MC-Ingress-Time: 1611941354838 Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout2.hostinger.io (smtp.hostinger.com) with ESMTPSA id 5A856333EFB7; Fri, 29 Jan 2021 17:29:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1611941352; bh=SaiUk8iEQUQlS+x3NI+7n5BPADoLRVd4EYibRprtpDs=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=DOCE5gikQG9hZkkmzqmn8vroXmMN3/vRRhXrRyYpexJ5qbPy8O5srg2XElg6YEEGq 6rLmUsvhge+n5sGmrpzjEO0GqxU2FWkI3nz+OZ0z87j6hqfkjn81pJ1lXr6Z2vWhwm bk8aSXd3Y8/4yVch5MFThMgb3DwRAJyr8x9wzVd/jMZQ10X6govxkbMGTqvwdFBcK8 SZowwS8Q4Blz6JcfbQhFgH6rfKtQ5+lrowgZ/+GBWAzUPPHos5VYy8mRYqagox3ffi KKT9Jyz6/ZPCTdsYxmoASX3y62/uCufzgYA7flaZOf9fchSjRi43yf/2TvxkKdI1Bb gq4hqGvrRKcaw== Reply-To: dcrocker@bbiw.net To: Alexey Melnikov , Alessandro Vesely , emailcore@ietf.org Cc: Arnt Gulbrandsen References: From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <2b567896-890a-d2df-f219-1fa3f1e04e11@dcrocker.net> Date: Fri, 29 Jan 2021 09:29:06 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #15: G.7.9. Discussion of 'blind' copies and RCPT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 17:29:18 -0000 On 1/29/2021 9:12 AM, Alexey Melnikov wrote: > Suggested replacement for the last sentence quoted above (as per feedback from > Arnt Gulbrandsen): > >   When more than one >   RCPT command is present, and in order to avoid defeating some of the >   purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy >   any of RCPT command arguments into the header section, >   either as part of trace header fields or as informational or private- >   extension header fields. > > (This removes "especially" and replaces "the full set of" with "any" -- copying > the first one can be as harmful as copying all of them, at least without > verifying that the addresses do appear in the headers.) > > Please provide feedback on this proposal within 2 weeks. The suggested wording is functionally problematic. The goal is to prohibit divulging addresses other than the one used to delivery to the recipient getting this copy of the mail. The wording should reflect that, rather than making a blanket prohibition of showing any address. Perhaps: An address that does not appear in the message content header section might appear in a RCPT command to the receiving SMTP server for a number of reasons. The two most common involve the use of a mailing list address -- a single address that produces automated re-distribution to multiple addresses -- and the use of a "blind copies" address. In order to avoid address disclosures that are problematic, in terms of privacy, any copying of a RCPT command argument into the message header section MUST be restricted to only the one used for delivery to the recipient getting the specific version of the message that discloses that address. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jan 29 10:23:28 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6423A11F5 for ; Fri, 29 Jan 2021 10:23:26 -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 Xn22UXdXBcmI for ; Fri, 29 Jan 2021 10:23:25 -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 8B4FF3A11F4 for ; Fri, 29 Jan 2021 10:23:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1611944602; bh=u3l5yqVDFdSJbKm2Z17WSe+3VKo4wA69DIxEnsQZ6vU=; l=562; h=To:Cc:References:From:Date:In-Reply-To; b=DOpxN/CzXI50g66pUXI5OEo8SdbFrAof8lwYRkV0QDd920XiXErwmZRMXO4pj0Di6 L0WlQwto6hccDbfnbtBIeOHqoBasMnrqQSipJeI8yqWpAY48EGiFU9gTEJPC1dPksj rs4tg190yNP8LeEopXteuWCbZKnVQtnc3ibT6PU7tEulvyZXS/hDRy4IFb7bW Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Original-Cc: Arnt Gulbrandsen 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 00000000005DC053.000000006014529A.00006F08; Fri, 29 Jan 2021 19:23:22 +0100 To: Alexey Melnikov , emailcore@ietf.org Cc: Arnt Gulbrandsen References: From: Alessandro Vesely Message-ID: <1b52ddce-bc90-9dc7-faa7-995aa0ebca12@tana.it> Date: Fri, 29 Jan 2021 19:23:21 +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: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #15: G.7.9. Discussion of 'blind' copies and RCPT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 18:23:27 -0000 On Fri 29/Jan/2021 18:12:09 +0100 Alexey Melnikov wrote: > On Tue, Jan 19, 2021, at 5:07 PM, Alessandro Vesely wrote: > >> Anyway, this Section deserves a comefrom Section 4.4. That is, for example: >> >> For = CFWS "FOR" FWS ( Path / Mailbox ) >> ; Not if multiple recipients, see Section 7.2 > > Sorry, I think I am missing your point here. I don't think the quoted ABNF need to change? Just the "see Section 7.2" part of the comment. Best Ale -- The comefrom statement was an ironic proposal after Dijkstra's goto considered harmful. From nobody Fri Jan 29 10:29:50 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C19A3A1204 for ; Fri, 29 Jan 2021 10:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no 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 4O6s1KU3Ji83 for ; Fri, 29 Jan 2021 10:29:47 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [144.76.73.169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3DB3A1201 for ; Fri, 29 Jan 2021 10:29:46 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 302F8C0060; Fri, 29 Jan 2021 18:36:33 +0000 (GMT) Authentication-Results: stabil.gulbrandsen.priv.no; dmarc=none (p=none dis=none) header.from=gulbrandsen.priv.no Authentication-Results: stabil.gulbrandsen.priv.no; spf=none smtp.mailfrom=arnt@gulbrandsen.priv.no DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1611945393; bh=cO8/V+a0WwaczvfizyqjjrJZuUpUUbLiPAcBK8HZnu0=; h=From:To:Subject:Date:References:From; b=j3YleWhBDmbYmmLEeUIa6PHHwWklxhklfGio6ohYdMhwjCltqHmJQAzZQLrm7tb02 GG2lqotlGiawE11QbuUqNTem9xkgwegEwg7fX57aB7AWyMgbTgNkE2pRYhicaKz02y S34gzwR2/KjPP1TeScwf9AHi1IRvpaMu125/eKOQ= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1611945392-21413-21411/9/40; Fri, 29 Jan 2021 18:36:32 +0000 From: Arnt Gulbrandsen To: dcrocker@bbiw.net, Alexey Melnikov , emailcore@ietf.org, Alessandro Vesely Date: Fri, 29 Jan 2021 18:36:32 +0000 Message-Id: References: <2b567896-890a-d2df-f219-1fa3f1e04e11@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Emailcore] Ticket #15: G.7.9. Discussion of 'blind' copies and RCPT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 18:29:48 -0000 I am happy with either wording. My suggestion might be said to reveal/indicate that the message has several recipients at that point, whether that is a bug or a feature is a matter of view. Arnt From nobody Fri Jan 29 13:17:37 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9563A12E4 for ; Fri, 29 Jan 2021 13:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 00KmPVDHWp8B for ; Fri, 29 Jan 2021 13:17:35 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B0383A128C for ; Fri, 29 Jan 2021 13:17:35 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1l5b90-000O0I-To; Fri, 29 Jan 2021 16:17:30 -0500 Date: Fri, 29 Jan 2021 16:17:25 -0500 From: John C Klensin To: dcrocker@bbiw.net, Alexey Melnikov , Alessandro Vesely , emailcore@ietf.org cc: Arnt Gulbrandsen Message-ID: <125686AE3FA072642DA76FAD@PSB> In-Reply-To: <2b567896-890a-d2df-f219-1fa3f1e04e11@dcrocker.net> References: <2b567896-890a-d2df-f219-1fa3f1e04e11@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #15: G.7.9. Discussion of 'blind' copies and RCPT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 21:17:37 -0000 A radical alternative/suggestion at the end (skip there if you like)... --On Friday, January 29, 2021 09:29 -0800 Dave Crocker wrote: > On 1/29/2021 9:12 AM, Alexey Melnikov wrote: >> Suggested replacement for the last sentence quoted above (as >> per feedback from Arnt Gulbrandsen): >>=20 >> =C2=A0 When more than one >> =C2=A0 RCPT command is present, and in order to avoid = defeating >> some of the =C2=A0 purpose of these mechanisms, SMTP = clients >> and servers SHOULD NOT copy =C2=A0 any of RCPT command >> arguments into the header section, =C2=A0 either as part of >> trace header fields or as informational or private- =C2=A0 >> extension header fields. >>=20 >> (This removes "especially" and replaces "the full set of" >> with "any" -- copying the first one can be as harmful as >> copying all of them, at least without verifying that the >> addresses do appear in the headers.) >>=20 >> Please provide feedback on this proposal within 2 weeks. >=20 >=20 > The suggested wording is functionally problematic. >=20 > The goal is to prohibit divulging addresses other than the one > used to delivery to the recipient getting this copy of the > mail. The wording should reflect that, rather than making a > blanket prohibition of showing any address. >=20 > Perhaps: >=20 > An address that does not appear in the message content > header section might appear in a RCPT command to the receiving > SMTP server for a number of reasons. The two most common > involve the use of a mailing list address -- a single address > that produces automated re-distribution to multiple addresses > -- and the use of a "blind copies" address. In order to avoid > address disclosures that are problematic, in terms of privacy, > any copying of a RCPT command argument into the message header > section MUST be restricted to only the one used for delivery > to the recipient getting the specific version of the message > that discloses that address. Dave and others, With the understanding that, as editor, I'm quite agnostic about this and willing to make any changes the WG decides on, so the following is personal opinion... =20 I think your suggestion above is problematic too (and the last paragraph of Alexey's even more so), partially for reasons you have identified earlier. First, since at least RFC 821 and some of the discussions leading to RFC 1123, we have carefully avoided imposing any requirement that an MTA (or SMTP sender or receiver) inspect and evaluate, or even know how to parse, message headers. The language about adding trace fields has always been written to just insert them at the beginning/top of the message content, message content that (especially before RFC 2821) might well not contain 822-derived header fields at all. I am not sure whether your proposed text requires changing that principle; Alexey's "at least without verifying" certainly does. If whatever we decide to do does make that change, we should all understand that is a big step. And, if it doesn't, I think text that is extremely clear about that would be helpful. Second, while we use terms like "final delivery system" (or "server") frequently, including in the text of 5321, we need to keep in mind that there are a collection of cases (and implementation designs for conforming SMTP servers) for which that is ultimately handwaving. In some cases, unless special efforts have been made to preserve all (or all relevant) RCPT information, by the time the system knows what should go into "FOR" under the above description (or either of the prior ones) is long gone. That definition is, of course, further complicated when the SMTP server turns out to be a gateway or is handing the message off (possibly still with multiple recipients on the same host) to some sort of mail store manager. We should also remember that the main purpose of carrying trace information forward at all has historically been to facilitate understanding of what went wrong, caused delays, etc. (And, in the nastier world we face today relative to 1986, to allow some crude post-delivery judgments of likely authenticity.) From that standpoint, in the overwhelming number of cases the final recipient won't need the FOR clause to tell her who she is: she probably already knows that and all three of these suggestions seem intended to assure that nothing else ends up in that field. Worth noting too that, if I pass an address of "bozo@example.com" or just "bozo" off to a Submission server and it transforms it into "cleverperson@example.com" but puts "bozo" into a FOR clause before sending the message along with that single RCPT field, another type of privacy problem has occurred. And, especially in practice, that is not the only place one-one substitutions can occur. So, that radical suggestion,... Given that sloppy use of "FOR" can disclose information that might be private, that the syntax and applicability for FOR has never been defined when multiple RCPT commands are present, and that any steps we might take to improve privacy in conjunction with that clause reduce its utility, why not just deprecate the use of the thing? Saying "SHOULD NOT put these things in but MUST NOT choke if one is encountered" is entirely consistent with the rules for going to full standard if a feature has turned out to be bad news. Maybe an exception is needed and would be helpful for Submission Servers or first-hop SMTP processors but they presumably are able to know what is actually intended. Or not. That would not necessarily eliminate the need for some version of Arnt's text via-a-vis private or additional information header fields. I am _not_ completely convinced that deprecating FOR is a good idea, only that it would considerably simplify this discussion and the specification if we decided it was wise and hence that the question should be asked. best, john From nobody Fri Jan 29 13:19:39 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA8A3A130B for ; Fri, 29 Jan 2021 13:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 AMBWOR3n3yFC for ; Fri, 29 Jan 2021 13:19:36 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5A323A1307 for ; Fri, 29 Jan 2021 13:19:36 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1l5bB1-000O0y-50; Fri, 29 Jan 2021 16:19:35 -0500 Date: Fri, 29 Jan 2021 16:19:29 -0500 From: John C Klensin To: Alexey Melnikov , emailcore@ietf.org Message-ID: <9A0D1059B7C8EB9557F98238@PSB> In-Reply-To: <5739eec7-ce97-fb3e-5f43-ca282c129238@isode.com> References: <5739eec7-ce97-fb3e-5f43-ca282c129238@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #15: G.7.9. Discussion of 'blind' copies and RCPT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 21:19:38 -0000 --On Tuesday, January 19, 2021 16:14 +0000 Alexey Melnikov wrote: > Hi again, >=20 > Also, John Klensin asked: May also need to discuss whether > that terminology is politically incorrect and suggest a > replacement. >=20 > My reply as a participant: >=20 > =C2=A0I think CC and BCC are well established terms, so = changing > it now is going to cause more harm then good. Besides I don't > have any better proposal. Agreed. Just felt obligated to raise the issue so that, in particular, if someone else raises it on Last Call or later, you and Todd could truthfully say that the WG had examined the question. john From nobody Fri Jan 29 14:03:29 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3203A118E for ; Fri, 29 Jan 2021 14:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 8QecIF_5r1XK for ; Fri, 29 Jan 2021 14:03:26 -0800 (PST) Received: from dragonfly.birch.relay.mailchannels.net (dragonfly.birch.relay.mailchannels.net [23.83.209.51]) (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 F07513A10F0 for ; Fri, 29 Jan 2021 14:03:25 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 926A7124272 for ; Fri, 29 Jan 2021 22:03:24 +0000 (UTC) Received: from nl-srv-smtpout3.hostinger.io (100-96-18-11.trex.outbound.svc.cluster.local [100.96.18.11]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id BFBFD123127 for ; Fri, 29 Jan 2021 22:03:23 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout3.hostinger.io ([UNAVAILABLE]. [145.14.159.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.18.11 (trex/6.0.2); Fri, 29 Jan 2021 22:03:24 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Celery-Cooing: 662e7fc3123fba38_1611957804296_477685854 X-MC-Loop-Signature: 1611957804296:1128148066 X-MC-Ingress-Time: 1611957804296 Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout3.hostinger.io (smtp.hostinger.com) with ESMTPSA id D08CD31C2C5E for ; Fri, 29 Jan 2021 22:03:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1611957802; bh=jwtbIaooFtAJzF5O2d/Ha2cQ1TF3pgtOGTGp9OVpX98=; h=Reply-To:To:From:Subject:Date; b=sDXOZngfOz/Cg5bZR2EEgUITPoD5gDfgmbZFiG9PnbFZ6+Ct4Rac20TIqdbGdM1Sb G3VpcJ2iLlbXd/NNVzgtrn5xF1UKmiEFoSJUl04WxNFoeAC7+j5A4z6l74aD1pn5+z ++8KEc8BoXtmgbgzXVHTqgxjpiY/tD+IX4VhgRcdKUTIYboHnGr1Ak+JqPSNg7Kf4a cuwCz9/q2gELwiH2/EDLRrE1Qd0uWwfKmxXGdgK/4gRutDMg+tkKY5egWpOwYJoZtx 53awJsx+/niNxAVOeGXBUpBgk5VY/87umCSAXDvBZmxuiYYLa2DMB5gcMQIao4Ieji 3m+Clf/tRpH5Q== Reply-To: dcrocker@bbiw.net To: emailcore@ietf.org From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <7cb6514c-61c0-d8d0-0644-fcb6b8a825ac@dcrocker.net> Date: Fri, 29 Jan 2021 14:03:19 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] Full Standard with incomplete and/or inaccurate text? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 22:03:27 -0000 Folks, Given that the goal of the current emailcore effort is to make the minimal changes necessary to promote specifications to full standard, my question is: Should the resulting documents provide incomplete and/or inaccurate information? I'd assume not, but some of the comments imply otherwise. If text is incomplete or inaccurate AND we do not know of its use being critical to current operations, then why exactly should it be retained? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jan 29 17:09:33 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBED3A1449 for ; Fri, 29 Jan 2021 17:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 wO_UcjikOqNd for ; Fri, 29 Jan 2021 17:09:29 -0800 (PST) Received: from antelope.elm.relay.mailchannels.net (antelope.elm.relay.mailchannels.net [23.83.212.4]) (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 695403A1447 for ; Fri, 29 Jan 2021 17:09:29 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D62EE183FF1; Sat, 30 Jan 2021 01:09:27 +0000 (UTC) Received: from nl-srv-smtpout1.hostinger.io (100-96-13-5.trex.outbound.svc.cluster.local [100.96.13.5]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id C078A183FC4; Sat, 30 Jan 2021 01:09:25 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout1.hostinger.io ([UNAVAILABLE]. [185.224.136.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.13.5 (trex/6.0.2); Sat, 30 Jan 2021 01:09:27 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Illegal-Tangy: 70e078143e25fba8_1611968967569_3861130386 X-MC-Loop-Signature: 1611968967569:274537925 X-MC-Ingress-Time: 1611968967569 Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout1.hostinger.io (smtp.hostinger.com) with ESMTPSA id 5926622661CD; Sat, 30 Jan 2021 01:09:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1611968964; bh=A0Le85mFFVNnLVeMix38crRw3tqtfUxTZbnEdVEQuPo=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=G4/mjlAGAJjm2V5GK36JQSnNNB2+ul3QLDKOIsuipbnYTfOk/yQRxUEuShFqE+s6O H/OXbtX0Vb2BZShaW2sTDb3UoPH50IVJ9A7FW+OBld8j+C8iWNa2jTb1lNmasafiSK jAPj4/lhB7qVxC6pVn8oE7zleB0MHRXV7besgtbQFF8cbV59L153pg7GkTsx2SDxqA IwNfQIUII343iBm0Ok+5N7vTbVAQXC0iyjBFBjlcjVq8FQnRLY9vU/rRVUUwJyrNJB G3hUsa7QKhMcTe+mXm5Vqm9B/jnz2cEZnvcQimMr7J4uBvtNSY6TO3Fm7GdcG2huVp m6eEFvmUjgYEA== Reply-To: dcrocker@bbiw.net To: John C Klensin , dcrocker@bbiw.net, Alexey Melnikov , Alessandro Vesely , emailcore@ietf.org Cc: Arnt Gulbrandsen References: <2b567896-890a-d2df-f219-1fa3f1e04e11@dcrocker.net> <125686AE3FA072642DA76FAD@PSB> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <7e284ff0-2dc1-eaf8-bcbf-f84951025428@dcrocker.net> Date: Fri, 29 Jan 2021 17:09:15 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <125686AE3FA072642DA76FAD@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #15: G.7.9. Discussion of 'blind' copies and RCPT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2021 01:09:31 -0000 On 1/29/2021 1:17 PM, John C Klensin wrote: > > First, since at least RFC 821 and some of the discussions > leading to RFC 1123, we have carefully avoided imposing any > requirement that an MTA (or SMTP sender or receiver) inspect and > evaluate, or even know how to parse, message headers. The The issue, here, is not about parsing header fields. It is about generating them. And RFC 821 specifies creation of some header fields. This also is about delivery, which is when FOR get created. But since you raised it... Actually, this highlights why the SMTP specification should not deal with delivery issues, per se, and should leave that to an MDA specification. The SMTP specification gets a lot simpler if it stops trying to cover the entire range of end-to-end handling issues and just sticks to what it is actually used for. Delivery has gotten far more complex than this specification does or can deal with. > language about adding trace fields has always been written to > just insert them at the beginning/top of the message content, > message content that (especially before RFC 2821) might well not > contain 822-derived header fields at all. I am not sure whether > your proposed text requires changing that principle; Alexey's > "at least without verifying" certainly does. If whatever we > decide to do does make that change, we should all understand > that is a big step. And, if it doesn't, I think text that is > extremely clear about that would be helpful. The 'FOR' clause gets into the delivery assessment issue. Since it's part of the Received specification, which does apply to normal relaying, perhaps just say that there must be no more than one For clause and it contains only one address. The physics of that will adequately constrain its use. > Second, while we use terms like "final delivery system" (or > "server") frequently, including in the text of 5321, we need to > keep in mind that there are a collection of cases (and > implementation designs for conforming SMTP servers) for which > that is ultimately handwaving. Indeed it is. In some cases, unless special > efforts have been made to preserve all (or all relevant) RCPT > information, by the time the system knows what should go into > "FOR" under the above description (or either of the prior ones) > is long gone. That definition is, of course, further > complicated when the SMTP server turns out to be a gateway or is > handing the message off (possibly still with multiple recipients > on the same host) to some sort of mail store manager. SMTP has nothing at all to do with gateway functionality. Zero. Trying to touch that topic, in a mail relaying protocol specification, is a problematic distraction. Especially given how irrelevant and incomplete the text is to actual gatewaying behavior. > We should also remember that the main purpose of carrying trace > information forward at all has historically been to facilitate > understanding of what went wrong, caused delays, etc. (And, in > the nastier world we face today relative to 1986, to allow some > crude post-delivery judgments of likely authenticity.) From > that standpoint, in the overwhelming number of cases the final > recipient won't need the FOR clause to tell her who she is: she I suspect it's not because of my gender, but I frequently look for the FOR clause. I get mail under a variety of different addresses. As do many others. So excluding that utility is problematic. > Worth noting too that, if I pass an address of > "bozo@example.com" or just "bozo" off to a Submission server and > it transforms it into "cleverperson@example.com" but puts "bozo" > into a FOR clause before sending the message along with that > single RCPT field, another type of privacy problem has occurred. > And, especially in practice, that is not the only place one-one > substitutions can occur. I don't understand how the above paragraph is relevant to the SMTP specification. Mixing submission with discussion of the FOR clause makes no sense to me. In any event, I also don't understand what privacy problem is being claimed. > > So, that radical suggestion,... > > Given that sloppy use of "FOR" can disclose information that The 'given' has not been clearly established here. So the premise needs some work. > might be private, that the syntax and applicability for FOR has > never been defined when multiple RCPT commands are present, and > that any steps we might take to improve privacy in conjunction > with that clause reduce its utility, why not just deprecate the > use of the thing? Because it is used and it is useful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jan 31 04:41:04 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34D53A0CE1 for ; Sun, 31 Jan 2021 04:41:02 -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 0McCL-ep67Xh for ; Sun, 31 Jan 2021 04:41:01 -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 C28AF3A0CDF for ; Sun, 31 Jan 2021 04:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1612096856; bh=1bFMmlpl+yTV05BbAhRULra0K5Fl3e1u6HdCWul2jqk=; l=4539; h=To:Cc:References:From:Date:In-Reply-To; b=ConHJTOqMhkNPeaSnzatKPi3pVU2dRnobIgPH04zEclQXYl+nwvWnH0lmEPYMN64p YDNyC4BX9QxvaAutdXGD+/egshikq7QeAekdWkj8SQudzkl6ZwKKnRDr9h27I6ro50 shBerCFagvFDE885+UFi5TTqrRM3KFPGQ22Ji4uzh3nue28OyOMJMRtUWYI8q Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Original-Cc: Arnt Gulbrandsen 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 00000000005DC053.000000006016A558.00005C85; Sun, 31 Jan 2021 13:40:56 +0100 To: dcrocker@bbiw.net, John C Klensin , Alexey Melnikov , emailcore@ietf.org Cc: Arnt Gulbrandsen References: <2b567896-890a-d2df-f219-1fa3f1e04e11@dcrocker.net> <125686AE3FA072642DA76FAD@PSB> <7e284ff0-2dc1-eaf8-bcbf-f84951025428@dcrocker.net> From: Alessandro Vesely Message-ID: Date: Sun, 31 Jan 2021 13:40:55 +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: <7e284ff0-2dc1-eaf8-bcbf-f84951025428@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #15: G.7.9. Discussion of 'blind' copies and RCPT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 12:41:03 -0000 On Sat 30/Jan/2021 02:09:15 +0100 Dave Crocker wrote: > On 1/29/2021 1:17 PM, John C Klensin wrote: >> >> language about adding trace fields has always been written to >> just insert them at the beginning/top of the message content, >> message content that (especially before RFC 2821) might well not >> contain 822-derived header fields at all.  I am not sure whether >> your proposed text requires changing that principle; Alexey's >> "at least without verifying" certainly does. That was descriptive text for the list, not proposed text for the I-D. The proposed text was: When more than one RCPT command is present, and in order to avoid defeating some of the purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy any of RCPT command arguments into the header section, either as part of trace header fields or as informational or private- extension header fields. It seems precise enough. Deriving that there might be "informational or private-extension" fields which are not trace fields is not fully correct, since the "or" can be inclusive. IMHO, that SHOULD NOT can be promoted to MUST NOT. >> If whatever we decide to do does make that change, we should all >> understand that is a big step. And, if it doesn't, I think text that is >> extremely clear about that would be helpful. > > The 'FOR' clause gets into the delivery assessment issue. > > Since it's part of the Received specification, which does apply to normal > relaying, perhaps just say that there must be no more than one For clause and > it contains only one address.  The physics of that will adequately constrain > its use. I disagree. Uniqueness of FOR doesn't imply uniqueness of RCPT. The original alternative text had the same problem: any copying of a RCPT command argument into the message header section MUST be restricted to only the one used for delivery to the recipient getting the specific version of the message that discloses that address. It requires too much salt to derive that "to only the one" means that a single RCPT command is present in the envelope. >> In some cases, unless special efforts have been made to preserve all (or >> all relevant) RCPT information, by the time the system knows what should >> go into "FOR" under the above description (or either of the prior ones) is >> long gone. I don't get this. The trace header is written during the SMTP transaction, isn't it? >> [...] >> We should also remember that the main purpose of carrying trace >> information forward at all has historically been to facilitate >> understanding of what went wrong, caused delays, etc.   (And, in >> the nastier world we face today relative to 1986, to allow some >> crude post-delivery judgments of likely authenticity.)  From >> that standpoint, in the overwhelming number of cases the final >> recipient won't need the FOR clause to tell her who she is: she > > I suspect it's not because of my gender, but I frequently look for the FOR > clause.  I get mail under a variety of different addresses.  As do many > others.  So excluding that utility is problematic. +1, although Delivered-To: is better at recovering the original target. >> Worth noting too that, if I pass an address of "bozo@example.com" or just >> "bozo" off to a Submission server and it transforms it into >> "cleverperson@example.com" but puts "bozo" into a FOR clause before >> sending the message along with that single RCPT field, another type of >> privacy problem has occurred. And, especially in practice, that is not the >> only place one-one substitutions can occur. Aliases at the MSA are quite rare. That kind of mechanism is more often used (for lists of recipients) at the MUA. Since SMTP does not specify that, we can ignore its possible nasty effects. >> So, that radical suggestion,... >> >> Given that sloppy use of "FOR" can disclose information that > > The 'given' has not been clearly established here.  So the premise needs some > work. > > >> might be private, that the syntax and applicability for FOR has >> never been defined when multiple RCPT commands are present, and >> that any steps we might take to improve privacy in conjunction >> with that clause reduce its utility, why not just deprecate the >> use of the thing? > > Because it is used and it is useful. Agreed. Clarifying that it is only allowed in the presence of a single RCPT command is enough. Best Ale --