From nobody Sat Mar 5 06:09:03 2022 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 ACE943A09CC for ; Sat, 5 Mar 2022 06:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=tana.it header.b=zM7FjweG; dkim=pass (1152-bit key) header.d=tana.it header.b=Bx5x8W0q 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 V5OEKIwDng7l for ; Sat, 5 Mar 2022 06:08:54 -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 836933A171D for ; Sat, 5 Mar 2022 06:08:52 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1646489326; bh=3gGSrhS/8elcXtITK0eIIMBWEIvbz9lqusMeiNpB08U=; h=Date:To:From:Subject; b=zM7FjweGSBYJGnm7lj/NMMjYsBYJvSZBciqV+MkJkDCAC8FBXk47m6QA4Y1yWafLt tNp7GpM4arHRYE4ZVM8Bg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1646489326; bh=3gGSrhS/8elcXtITK0eIIMBWEIvbz9lqusMeiNpB08U=; h=Date:To:From; b=Bx5x8W0qKibIHVO9ohN/gitWIJES7oee9KXaaFI6+68IF3GCEidsaVax/UaFJryAZ 516rznUG/P7fDQ9pkeIcOVxsMcFZts4+kZ0389hY2WOQJTsL0wL+L3jJqVw/uV7BDJ TUhhaLBggYu/YXqCAJJHHJqJqrtibkEhggxlIk+gDsRP7FsW+G9UNat3L96bN Author: 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 00000000005DC026.0000000062236EEE.00005562; Sat, 05 Mar 2022 15:08:46 +0100 Message-ID: Date: Sat, 5 Mar 2022 15:08:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Content-Language: en-US To: emailcore@ietf.org Authentication-Results: tana.it; auth=pass (details omitted) From: Alessandro Vesely Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] Should rfc5322bis register an Email Authentication Method to report overall format conformance? 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, 05 Mar 2022 14:09:02 -0000 Hi all, perhaps I should have questioned ietf-822 about this idea. However, since the standard is now being revised, perhaps it makes more sense to ask here directly. As is well known, RFC 8601 provides ways to describe the level of trust that a message is considered to deserve, according to a variety of methods, in an Authentication-Results: (A-R) header field. Deep down, all methods rely on the mail format. However, the format itself is not reported directly. For example, a popular DKIM filter has an option to refuse processing of a message if the header field count does not conform to RFC5322 Section 3.6. That stems from inconsistencies among different software about how to treat anomalies such as multiple From: fields, which can result in authenticating a field which is not the one displayed.[*] What to do in such cases? The old message just exemplified[*] had a cryptographically correct A-R: Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@isdg.net Since then, some mail sites adopted signatures where both From: fields are signed, the rightful one and the illicit, currently empty one. That way, adding a non-empty From: breaks the signature. A clever trick which works but is not informative. Perhaps, an A-R for that case could be conceived like so: Authentication-Results: server.example.com; mail=fail multiple.from; dkim=policy (invalid message) header.i=@whatever.example That would indicate the failure point correctly. At the same time, a mail= method would indicate that the mail format was checked. IMHO, that would contribute to mail format compliance significantly, especially when MUAs display the result. The standard could even provide for mail=obs. Not banning but tagging. jm2c Ale -- [*] https://mailarchive.ietf.org/arch/msg/ietf-dkim/KEUcXBTzh_hvNrQns1nDJoqF2FY/ From nobody Sat Mar 5 18:20:16 2022 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 84DF43A0899 for ; Sat, 5 Mar 2022 18:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 B7nnv1g_Hli3 for ; Sat, 5 Mar 2022 18:20:09 -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 A53153A0897 for ; Sat, 5 Mar 2022 18:20:09 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nQgVA-000Jmi-38; Sat, 05 Mar 2022 21:20:04 -0500 Date: Sat, 05 Mar 2022 21:19:58 -0500 From: John C Klensin To: John Levine , Sabahattin Gucukoglu , emailcore@ietf.org Message-ID: In-Reply-To: <20220221191046.970B137BA5CA@ary.qy> References: <20220221191046.970B137BA5CA@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] 5321bis-09: Thinking About Interaction of Code 556 with 'postmaster' 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, 06 Mar 2022 02:20:15 -0000 --On Monday, February 21, 2022 14:10 -0500 John Levine wrote: > It appears that Sabahattin Gucukoglu said: >> If I'm honest, I'm just not a fan of code 556. If >> somebody finds it useful, fair enough, but it seems to me to >> require a special-case treatment of a non-existent domain, >> which must be configured to be useful. > > No, 556 doesn't need any special cases. The likely scenario is > that you have a submission server, someone sends > > RCPT TO: > > and the submission server sees that example.wtf has a null mx > so it knows there's no point to accepting the mail. It doesn't > need to look at the mailbox. I suppose it would also be > appropriate if the domain does not exist at all, again > unrelated to the mailbox. > > There's also 521 and 554 which say "I am not a mail server." I > don't think that we can realistically change that to "I am not > a mail server except that I can send postmaster mail > somewhere." Speaking personally, not as editor: John's "not a mail server except that I accept mail for an address or two" would lead us into all sorts of silly cases... and break the way things have been specified since RFC 821. Recent off-list correspondence leads me to believe that I see more cases than John Levine did at the time I wrote him, but, AFAICT, I can't see any special cases here. If the SMTP server knows that no mail is accepted but an attempt to open a mail transaction is received anyway, 556 might reasonably be returned at connection time. As I read Section 4.2.4.2 of rfc5321bis-09 (and -10 -- any changes are not going to make it into that version), 521 would be preferred if the SMTP server doesn't figure out the it isn't accepting mail for that particular domain until it gets a RCPT command, but 556 would be more emphatic if the server were aware that there was a null MX record for that domain and, speaking personally, I don't see much value in trying to absolutely prohibit it for that case. These things can get a tad more complicated if there is a configuration inconsistency or misunderstand between the SMTP server and the relevant authoritative DNS server/zone, but I think the current text is robust against such problems. Now, as editor, three requests/suggestions, the first for Sabahattin and the other two for everyone: (1) If, with John Levine's explanation and mine, you still don't understand that this is not about special cases, please explain what those cases are in a bit more detail. (2) Please read Section 4.2.4.2, which is intended to cover all of this, carefully. If it still leaves loose ends or introduces problems, please identify those as explicitly as possible and, if possible suggest text or at least particular sentences that need fixing. (3) John Levine has pointed out that rfc5321bis-09 covers substantially everything that is in RFC 7505 except the enhanced status codes. Especially given that we propose to obsolete 7505, should some words be added to that section to point to the IANA registry with those codes in it? thanks, john From nobody Sat Mar 5 18:20:46 2022 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 60A623A089B for ; Sat, 5 Mar 2022 18:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 rFB6dtolxvqX for ; Sat, 5 Mar 2022 18:20:40 -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 B36083A0899 for ; Sat, 5 Mar 2022 18:20:40 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nQgVh-000Jmw-7U; Sat, 05 Mar 2022 21:20:37 -0500 Date: Sat, 05 Mar 2022 21:20:31 -0500 From: John C Klensin To: Alexey Melnikov , John R Levine , emailcore@ietf.org Message-ID: <1F0956DF9B26AAD73B20287F@PSB> In-Reply-To: <66bead97-dff3-4968-b4eb-473d4ec6e65b@www.fastmail.com> References: <20220122042951.379BB355E84F@ary.qy> <66bead97-dff3-4968-b4eb-473d4ec6e65b@www.fastmail.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] Post-Interim question about Section 3.4.2 of draft-ietf-emailcore-rfc5321bis-08 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, 06 Mar 2022 02:20:46 -0000 --On Thursday, February 17, 2022 14:25 +0000 Alexey Melnikov wrote: > Hi John/John, > > On Sat, Jan 22, 2022, at 5:47 AM, John C Klensin wrote: >> --On Friday, January 21, 2022 23:29 -0500 John Levine >> wrote: >> >>> It appears that John C Klensin said: >>>> Hi. >>>> >>>> During Friday's interim meeting, a decision was made >>>> (associated with Ticket #4) to drop the last sentence of the >>>> first paragraph of Section 3.4.2, which reads (in -08): >>>> >>>> 'However, in this case, the message header section (RFC >>>> 5322 [12]) MUST be left unchanged; in particular, the >>>> "From" field of the header section is unaffected.' >>>> >>>> Checking back over my notes, that sentence appeared in RFC >>>> 2821. Checking further, the decision in DRUMS to put it in >>>> was apparently based on real-world confusion as to whether a >>>> change in the reverse-path was required to be reflected in >>>> the mail headers. >>> >>> If people still think that the bounce address has to match >>> the From header, we've got worse problems than this sentence. >> >> Agreed. But I think we have worse problems than that sentence >> even without that condition, so I am trying to be careful and >> ask. >> >>> For the list-id issue, I suppose we could say that existing >>> message headers are left unchanged, implying that if you want >>> to add new ones, you can. >> >> That was the case I was concerned about and (as an >> individual) I like your suggestion for how to handle it. >> >> Others? > > I still think that the replacement text proposed at the > interim is better than taking this sentence out, but I am > happy with either: > > This change to MAIL FROM doesn't affect the header section > of the message. It seems to me that, after the interim and the subsequent discussion, we have multiple options. In no particular order: (1) Leave the RFC 5321 text (in Section 3.9 there and Section 3.4.2 of 5321bis-10 (forthcoming) unchanged. In the latter, that sentence reads: However, in this case, the message header section (RFC 5322 [12]) MUST be left unchanged; in particular, the "From" field of the header section is unaffected. (2) Remove that sentence and replace it with nothing. (3) Replace that sentence with This change to MAIL FROM doesn't affect the header section of the message. (4) Replace the sentence with something like This change to MAIL FROM does not affect any header that is already present in the message. For the last two options, I'm not sure whether we are agreed on the descriptive "does not" or if we intend a normative MUST or SHOULD. I've added a note to the working copy of -10 flagging this. Alexey, please see my separate comments about untangling the tickets that interact with that Section. best, john From nobody Sun Mar 6 11:42:14 2022 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 C5B583A0A3C for ; Sun, 6 Mar 2022 11:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=me.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 f5ElA0W_w46K for ; Sun, 6 Mar 2022 11:42:04 -0800 (PST) Received: from mr85p00im-zteg06011501.me.com (mr85p00im-zteg06011501.me.com [17.58.23.182]) (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 83F4A3A0A27 for ; Sun, 6 Mar 2022 11:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1646595724; bh=is/vXturi+6/lPoniN6TkrsUbCN5fD9woWSc2RKgPbc=; h=From:Content-Type:Mime-Version:Subject:Date:To:Message-Id; b=oP3ei/0zhKWglIGUsG7JSodfQPEoqxo8cIQn8inRSLT7TX+YS2YjoTvouBVASF7jy sdFJT7lLLr3RforuDJsG5gtVFJPU5E9XzGSiVOSLdo0NUijqmSgcUSLa3VjIG/Ango luVOVukKEhhQOTXff29UND+HBt/iX+ToC1ddNnqPiGM1XWdWlFmNAxgu27QJVnsvza oiDRVqXEMvdCItqCzO48lhNrqp4pEVTzGf3gai4Lj860fh4yTIJ8JtXqJClJyWVmFs VNLxPImjRdsgRJiXsFALRqMQWIlNrD5vgiBRd1oBEkOKBweU3RrCx4PrfVIfMwAlVX DrO6vXQpp93pQ== Received: from smtpclient.apple (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18]) by mr85p00im-zteg06011501.me.com (Postfix) with ESMTPSA id 5503F48063D for ; Sun, 6 Mar 2022 19:42:03 +0000 (UTC) From: Sabahattin Gucukoglu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Date: Sun, 6 Mar 2022 19:41:43 +0000 References: <20220221191046.970B137BA5CA@ary.qy> To: emailcore@ietf.org In-Reply-To: Message-Id: <422F8BBA-A274-45F6-A8AE-7F2A0C631451@me.com> X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.138,18.0.572,17.0.605.474.0000000_definitions?= =?UTF-8?Q?=3D2020-02-14=5F11:2020-02-14=5F02,2020-02-14=5F11,2020-01-23?= =?UTF-8?Q?=5F02_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 adultscore=0 suspectscore=0 mlxlogscore=999 spamscore=0 phishscore=0 malwarescore=0 bulkscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2203060135 Archived-At: Subject: Re: [Emailcore] 5321bis-09: Thinking About Interaction of Code 556 with 'postmaster' 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, 06 Mar 2022 19:42:11 -0000 On 6 Mar 2022, at 02:19, John C Klensin wrote: > --On Monday, February 21, 2022 14:10 -0500 John Levine > wrote: >> It appears that Sabahattin Gucukoglu said: >>> If I'm honest, I'm just not a fan of code 556. If >>> somebody finds it useful, fair enough, but it seems to me to >>> require a special-case treatment of a non-existent domain, >>> which must be configured to be useful. >>=20 >> No, 556 doesn't need any special cases. The likely scenario is >> that you have a submission server, someone sends=20 >>=20 >> RCPT TO:=20 >>=20 >> and the submission server sees that example.wtf has a null mx >> so it knows there's no point to accepting the mail. It doesn't >> need to look at the mailbox. I suppose it would also be >> appropriate if the domain does not exist at all, again >> unrelated to the mailbox. >>=20 >> There's also 521 and 554 which say "I am not a mail server." I >> don't think that we can realistically change that to "I am not >> a mail server except that I can send postmaster mail >> somewhere." >=20 > Speaking personally, not as editor: John's "not a mail server > except that I accept mail for an address or two" would lead us > into all sorts of silly cases... and break the way things have > been specified since RFC 821. Accepted, absolutely. I do not propose to make the cost of refusing all = mail prohibitive and it would be burdensome and unnecessary to require a = server intended to refuse all mail to accept mail just for postmaster. And yes, if a non-public intermediate or submission server performs = checks in real time on mail being submitted against destination MXs or = mailboxes then it can obviously be expected to informatively explain to = the client that the destination domain is unreachable and no further = configuration is necessary to achieve that effect. (I expect that many = submission servers will refuse to do this for policy reasons, though, or = to support submission clients or users that react poorly to failed = submissions.) > Recent off-list correspondence leads me to believe that I see > more cases than John Levine did at the time I wrote him, but, > AFAICT, I can't see any special cases here. If the SMTP server > knows that no mail is accepted but an attempt to open a mail > transaction is received anyway, 556 might reasonably be returned > at connection time. As I read Section 4.2.4.2 of rfc5321bis-09 > (and -10 -- any changes are not going to make it into that > version), 521 would be preferred if the SMTP server doesn't > figure out the it isn't accepting mail for that particular > domain until it gets a RCPT command, but 556 would be more > emphatic if the server were aware that there was a null MX > record for that domain and, speaking personally, I don't see > much value in trying to absolutely prohibit it for that case. OK, I re-read section 4.2.4.2 and RFCs 7504-5 and think I see what=E2=80=99= s happened. If it is intended that 556 is used at connection-opening = time on a public host then, firstly, I think section 4.2.4.2 needs a bit = of work because the juxtaposition of the discussion of code 521 at = connection-opening time (first paragraph) and the discussion of code 556 = in intermediate system, submission and =E2=80=9Cthe server domain=E2=80=9D= as well (second paragraph) makes it all but inevitable that people like = me will erroneously think the latter paragraph is only concerning a = post-RCPT response by implication (which, incidentally, is not indicated = in section 4.3.2 where as its use in connection establishment was and I = clearly missed it) and, secondly, I would agree that no harm was done in = that case. Now, if after this explanation of my error in comprehension, there is = still any relevance to public non-submission SMTP hosts (which might = include intermediate systems that permit relay to certain destinations, = but which are always configured as an MX target for domains for which = they are responsible), I believe what we are left with is the question = of whether it is proper to refuse mail at RCPT time with code 556. I = would, I think, remain against =E2=80=94 it seems to me that any MTA = capable of, in theory, receiving any mail for local mailbox storage or = onward transmission to a mailbox store elsewhere ought in principle to = receive postmaster mail for any of its domains, whether MX targets or = A/AAAA implicit-MX targets or address-literal targets. To refuse mail = with code 556 at RCPT time would require the public MX to know about a = domain for which it did not receive mail, including postmaster mail, and = would in effect be a special case for the refusal of mail for = postmaster. Code 556 in response to RCPT should therefore only ever be = used on submission servers or intermediate servers used internally for = onward transmission for a restricted set of clients, i.e. which are not = public servers that restrict mail acceptance to a fixed set of = configured destinations and which could therefore be expected to perform = MX lookups for unknown destination domains and react to NULL MX records, = IMO. But, if that is thought overly disciplinarian, I am quite happy to = see the consensus go the other way =E2=80=94 though I do think it would = undermine the case for =E2=80=98postmaster=E2=80=99. My reading of RFCs = 7504-5 do not leave me with any doubt that code 556 is not relevant on a = public MX post-RCPT, and the error in interpreting 5321bis is all mine = in that regard. If so, then a little clarity to that effect in section = 4.2.4.2 is all that=E2=80=99s required. > These things can get a tad more complicated if there is a > configuration inconsistency or misunderstand between the SMTP > server and the relevant authoritative DNS server/zone, but I > think the current text is robust against such problems. Agreed completely. > Now, as editor, three requests/suggestions, the first for > Sabahattin and the other two for everyone: >=20 > (1) If, with John Levine's explanation and mine, you still don't > understand that this is not about special cases, please explain > what those cases are in a bit more detail. If code 556 is relevant post-RCPT on a public MX host, it must be = configured to refuse mail destined for an =E2=80=9Cunserviced=E2=80=9D = domain, as above, otherwise it would normally just refuse to relay mail = for policy reasons for domains it didn=E2=80=99t know about, or refuse = mail for unknown mailboxes for domains it did. > (2) Please read Section 4.2.4.2, which is intended to cover all > of this, carefully. If it still leaves loose ends or introduces > problems, please identify those as explicitly as possible and, > if possible suggest text or at least particular sentences that > need fixing. Code 556 should be explicitly called out as being valid at = connection-opening in section 4.2.4.2; it shouldn=E2=80=99t be left to = the command-reply sequences list. I think 5321bis is relevant to code = 556 post-RCPT and this needs to be clarified; even though 5321bis = doesn=E2=80=99t pertain to submission, it does concern intermediate = systems, which include SMTP relays used in a trusted environment, = therefore the command-reply sequence list needs to acknowledge 556 as a = possible reply to RCPT. Finally, we need a discussion of whether code = 556 post-RCPT on a public MX is appropriate at all, and to add text = accordingly. I hope this clarifies my thinking. Cheers, Sabahattin From nobody Sun Mar 6 18:59:46 2022 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 E87D83A0AFA for ; Sun, 6 Mar 2022 18:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.861 X-Spam-Level: X-Spam-Status: No, score=-1.861 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, T_SCC_BODY_TEXT_LINE=-0.01, 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=UyZgrnG3; dkim=pass (2048-bit key) header.d=taugh.com header.b=YbmwCQji 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 NH8L4su5PFHH for ; Sun, 6 Mar 2022 18:59:38 -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 3DDEF3A0896 for ; Sun, 6 Mar 2022 18:59:38 -0800 (PST) Received: (qmail 15493 invoked from network); 7 Mar 2022 02:59:36 -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=3c83.62257518.k2203; bh=PQtWUIdWfEdlO4nWeIB9eMmijSCk6oRGuM19gVthRwQ=; b=UyZgrnG35tFQ/p2IYB9tbwADWITHaS0EJXsNa1u706Q2WkvpE/k/P3E/bycbn91ZrhnhNgI0h/IIBYiTss96kV0xiTxuKHt/Lz9lJuhbj5Wx0jwLpCvCCdEQAsNXYC4DsvO+1tqh3Nzn3HXpZwZZLbIAjlnGWsYJlQPO8VV0wCPZLYq59HDns4Ca5jd3TyluuG1fspjZ9nfAhLmizHN3eAiSqB1CIApHXizyqkhkhi+dats/OGjfyEqISb9poUspK4VnGLJoYQ53XEGtSz65GPV/H95p1xLH3o/dOiXuy/ZRoUq0W1J/GuSh0ANXFo+zx5G3keLkjTOzWr9+I6Up9Q== 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=3c83.62257518.k2203; bh=PQtWUIdWfEdlO4nWeIB9eMmijSCk6oRGuM19gVthRwQ=; b=YbmwCQjiRLlFhMRvbs6VwOHfetcAHWBg7FVA6VdXJ4MPTtZ9QYkXKxESrhJuVrcpY8eKhbG7iGBKRz3hHtC0uI/vait9nBS3oQT5Q/t2i+4mda8x8Hxhit2mdOLxfvZLoNp0XJ/61ZRyohwfRKHnK5eQJGqvL8beSICuAGsCvxN0ZfpaPWDoN+MVToxCJpRfYAure3ESwz/XR9prfOiafl/ID53QiECx0xj66ej141BkQStyPBlwc9WRoZ7kp9kxWfHhzvLUxxTwzDVBYxDh0fGq4xJXiSIG91rv68LgKw0+IVULCo+4HRHxwE04le84Gx1tl3VbgVNeH097dmvOLQ== 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; 07 Mar 2022 02:59:35 -0000 Received: by ary.qy (Postfix, from userid 501) id E3B0738948C9; Sun, 6 Mar 2022 21:59:34 -0500 (EST) Date: 6 Mar 2022 21:59:34 -0500 Message-Id: <20220307025934.E3B0738948C9@ary.qy> From: "John Levine" To: emailcore@ietf.org In-Reply-To: <422F8BBA-A274-45F6-A8AE-7F2A0C631451@me.com> 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] 5321bis-09: Thinking About Interaction of Code 556 with 'postmaster' 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, 07 Mar 2022 02:59:44 -0000 It appears that Sabahattin Gucukoglu said: >And yes, if a non-public intermediate or submission server performs checks in real time on mail being submitted >against destination MXs or mailboxes then it can obviously be expected to informatively explain to the client that the >destination domain is unreachable and no further configuration is necessary to achieve that effect. (I expect that >many submission servers will refuse to do this for policy reasons, though, or to support submission clients or users >that react poorly to failed submissions.) Given a choice between rejecting at submission time and a bounce later, I'll take the reject. In my experience MUAs don't do a fabulous job of explaining the failure, but it's better than trying to figure out a bounce. This is the most likely scenario for 556. >If code 556 is relevant post-RCPT on a public MX host, it must be configured to refuse mail destined for an >“unserviced” domain, as above, otherwise it would normally just refuse to relay mail for policy reasons for >domains it didn’t know about, or refuse mail for unknown mailboxes for domains it did. I'm with you. An MTA is either configured to accept mail for a domain or it isn't, and it's not likely to provide helpful opinions about the ones it's not configured for. I can imagine some arcane edge cases like an MTA set up as a secondary for a null MX, but now we're into "don't do that" territory. blah.wtf. MX 0 . MX 10 secondary.wtf. <-- that one might give a 556, maybe R's, John From nobody Mon Mar 7 02:39:57 2022 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 95FCE3A0EED for ; Mon, 7 Mar 2022 02:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=me.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 yb-5JlR32b9G for ; Mon, 7 Mar 2022 02:39:35 -0800 (PST) Received: from mr85p00im-zteg06021901.me.com (mr85p00im-zteg06021901.me.com [17.58.23.194]) (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 CCCFE3A0EE2 for ; Mon, 7 Mar 2022 02:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1646649575; bh=KNt7Cfu3VXdDSQinMNRff2kEyd5Ar518ciYqLzOdDCA=; h=From:Content-Type:Mime-Version:Subject:Date:To:Message-Id; b=zfdjlESnDOOcYspQJSW95aD95FAwHFQYHjz0KxkCF+O5HKma6A9lbgePk3nAA8SS3 9dHBQ9HNd64nywVXXcp5j9BqIfw+HNTcLyKvnWggh1o/RDvxLnyhi7Ivi3vm6KC+rM hHOgVMkomBKrarwrMJTdje2ZfHh5UzEluSmQwA9MP4e/hxVwNU093stGKU8OEtUmsw xxrM+EupEq32dWvvrI4DTKeG9ZBZlN1JRDReaSPfMr+DOTaKgs4tWOWkak9usnbIQP 3f+OQSVHVvfaKTFzqrDKA/98rZicFYXr3TH3tgDxuAI+YL9ASwU9cd058sjR7uBpId g3bkHZ08qHOaA== Received: from smtpclient.apple (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18]) by mr85p00im-zteg06021901.me.com (Postfix) with ESMTPSA id 241407408A8 for ; Mon, 7 Mar 2022 10:39:29 +0000 (UTC) From: Sabahattin Gucukoglu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Date: Mon, 7 Mar 2022 10:39:08 +0000 References: <20220307025934.E3B0738948C9@ary.qy> To: emailcore@ietf.org In-Reply-To: <20220307025934.E3B0738948C9@ary.qy> Message-Id: X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.425,18.0.816,17.11.62.513.0000000_definitions?= =?UTF-8?Q?=3D2022-01-18=5F01:2022-01-14=5F01,2022-01-18=5F01,2021-12-02?= =?UTF-8?Q?=5F01_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 suspectscore=0 bulkscore=0 mlxlogscore=928 phishscore=0 mlxscore=0 clxscore=1015 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2203070061 Archived-At: Subject: Re: [Emailcore] 5321bis-09: Thinking About Interaction of Code 556 with 'postmaster' 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, 07 Mar 2022 10:39:48 -0000 On 7 Mar 2022, at 02:59, John Levine wrote: > It appears that Sabahattin Gucukoglu said: >> If code 556 is relevant post-RCPT on a public MX host, it must be = configured to refuse mail destined for an >> =E2=80=9Cunserviced=E2=80=9D domain, as above, otherwise it would = normally just refuse to relay mail for policy reasons for >> domains it didn=E2=80=99t know about, or refuse mail for unknown = mailboxes for domains it did. >=20 > I'm with you. An MTA is either configured to accept mail for a domain > or it isn't, and it's not likely to provide helpful opinions about the > ones it's not configured for. Agreed. > I can imagine some arcane edge cases like an MTA set up as a secondary = for a null MX, but now we're > into "don't do that" territory. >=20 > blah.wtf. MX 0 . > MX 10 secondary.wtf. <-- that one might give a 556, maybe I remember when it was trendy to allow yourself to be a backup MX for = anybody who wanted to use your services; you=E2=80=99d check the MX list = to see if you were a non-primary MX for the recipient domain and accept = and queue the mail if you were. I don=E2=80=99t know anyone doing that = in 2022 because it would make your reputation harder to protect from = complete strangers using your system to contact others on their behalf = or to inject forged mail for subsequent bouncing to a victim, but just = in case, I suppose we could distinguish between =E2=80=9Cconfigured=E2=80=9D= and =E2=80=9Cunconfigured=E2=80=9D (or similar) domains for the = purposes of the description of code 556 if that was still thought = useful. Cheers, Sabahattin From nobody Mon Mar 7 02:53:30 2022 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 963B13A08D0 for ; Mon, 7 Mar 2022 02:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=QsvEsEbZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=F4zWIZq4 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 KaA7l0SQlenT for ; Mon, 7 Mar 2022 02:53:18 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65E0D3A08C2 for ; Mon, 7 Mar 2022 02:53:17 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C1E1F5C01F3; Mon, 7 Mar 2022 05:53:16 -0500 (EST) Received: from imap42 ([10.202.2.92]) by compute3.internal (MEProxy); Mon, 07 Mar 2022 05:53:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; bh=4dsEKTFd8D7hfTNnviSPsAdUGb2Z1sJJmyrTZL p5snw=; b=QsvEsEbZ6p4jWQ9S38dm/HsnezvUYdOdouHscwpMkqWn5phmUZ5gsz CKVoWnmQVG3dtClfL9qypUR6aS1SF53Hw7qWewFru6P0ZqcpeY5xeRQ2kLxg8mzB OOAVHVgSNXjqltH5nVpPTnC47HNJdwKlFyhp7PSxHOnSKXNFMLB3VxZeLdPH7DoG 8TdzyqG7bnrV0wxD1oqD47j7vn4kf6gL8zwIqLIMNJGK4wzJKdK16LyUDm6aXnAy bDYMtnkXq/bUDLZXHgymTE5PTN1iREwmWqqVhgtJbEZt6R1WAhP4Vz4viNC2Ddlx kcvPe7UdJLsBmJmkK+YJpt5AslWpFSJQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=4dsEKTFd8D7hfTNnv iSPsAdUGb2Z1sJJmyrTZLp5snw=; b=F4zWIZq4C4Uqj/cJX+FusaNpALZsWaQkJ xevB6M0i45OozV0wZkaiHDCGjpo/tbmpM6rLEls7tJDuigkTaOD1MLgleEgqurB4 x7zXaOD99GWv2nOY3sAiJcVUNAY9MXS04YJeDlbAK4xMthE7VWGpxSzDovVHlh5T G3GFdMlVZt7G+ZGesrHmZhzWvGtZC4QPnQZ+wuXPe6ZVCtO4aqRUjSZ2I1tS7l7U xLgFJOzZdq8RzLfVoR7wpK62w77D1au6e30teCoitnObOWQdyKdFZBkCGqebX9Sf tt0Zi6pYlrI0pxUCi6RxXrAG0SXsO+YHeVhpNPo9UY5vYFRe/MzFw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddugedgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuggftrfgrthhtvghrnhepfeevteekfeefteetgedtgefhieegieetgefhkeei gfduhffgjedvuddukeejfeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 817412180078; Mon, 7 Mar 2022 05:53:16 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4778-g14fba9972e-fm-20220217.001-g14fba997 Mime-Version: 1.0 Message-Id: <97080ca8-270d-4543-8775-98ca8b498e72@www.fastmail.com> In-Reply-To: <1F0956DF9B26AAD73B20287F@PSB> References: <20220122042951.379BB355E84F@ary.qy> <66bead97-dff3-4968-b4eb-473d4ec6e65b@www.fastmail.com> <1F0956DF9B26AAD73B20287F@PSB> Date: Mon, 07 Mar 2022 10:52:56 +0000 From: "Alexey Melnikov" To: "John C Klensin" Cc: "John R Levine" , emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Post-Interim question about Section 3.4.2 of draft-ietf-emailcore-rfc5321bis-08 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, 07 Mar 2022 10:53:27 -0000 Hi John, Replying below as a participant: On Sun, Mar 6, 2022, at 2:20 AM, John C Klensin wrote: > --On Thursday, February 17, 2022 14:25 +0000 Alexey Melnikov > wrote: > >> Hi John/John, >> >> On Sat, Jan 22, 2022, at 5:47 AM, John C Klensin wrote: >>> --On Friday, January 21, 2022 23:29 -0500 John Levine >>> wrote: >>> >>>> It appears that John C Klensin said: >>>>> Hi. >>>>> >>>>> During Friday's interim meeting, a decision was made >>>>> (associated with Ticket #4) to drop the last sentence of the >>>>> first paragraph of Section 3.4.2, which reads (in -08): >>>>> >>>>> 'However, in this case, the message header section (RFC >>>>> 5322 [12]) MUST be left unchanged; in particular, the >>>>> "From" field of the header section is unaffected.' >>>>> >>>>> Checking back over my notes, that sentence appeared in RFC >>>>> 2821. Checking further, the decision in DRUMS to put it in >>>>> was apparently based on real-world confusion as to whether a >>>>> change in the reverse-path was required to be reflected in >>>>> the mail headers. >>>> >>>> If people still think that the bounce address has to match >>>> the From header, we've got worse problems than this sentence. >>> >>> Agreed. But I think we have worse problems than that sentence >>> even without that condition, so I am trying to be careful and >>> ask. >>> >>>> For the list-id issue, I suppose we could say that existing >>>> message headers are left unchanged, implying that if you want >>>> to add new ones, you can. >>> >>> That was the case I was concerned about and (as an >>> individual) I like your suggestion for how to handle it. >>> >>> Others? >> >> I still think that the replacement text proposed at the >> interim is better than taking this sentence out, but I am >> happy with either: >> >> This change to MAIL FROM doesn't affect the header section >> of the message. > > It seems to me that, after the interim and the subsequent > discussion, we have multiple options. In no particular order: > > (1) Leave the RFC 5321 text (in Section 3.9 there and Section > 3.4.2 of 5321bis-10 (forthcoming) unchanged. In the latter, > that sentence reads: > > However, in this case, the message header section (RFC > 5322 [12]) MUST be left unchanged; in particular, the > "From" field of the header section is unaffected. > > (2) Remove that sentence and replace it with nothing. > > (3) Replace that sentence with > > This change to MAIL FROM doesn't affect the header > section of the message. > > (4) Replace the sentence with something like > > This change to MAIL FROM does not affect any header that > is already present in the message. Did you mean "header" or "header field"? > For the last two options, I'm not sure whether we are agreed on > the descriptive "does not" or if we intend a normative MUST or > SHOULD. Either of the last 2 work for me. I don't think we need normative language in either case. > > I've added a note to the working copy of -10 flagging this. > > Alexey, please see my separate comments about untangling the > tickets that interact with that Section. Best Regards, Alexey From nobody Mon Mar 7 05:01:32 2022 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 934B33A0FCC for ; Mon, 7 Mar 2022 05:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 yP7sLdjK3pw9 for ; Mon, 7 Mar 2022 05:01:13 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (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 A8C533A0FF2 for ; Mon, 7 Mar 2022 05:01:10 -0800 (PST) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 44806549A2D for ; Mon, 7 Mar 2022 14:01:05 +0100 (CET) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3A4584EA855; Mon, 7 Mar 2022 14:01:05 +0100 (CET) Date: Mon, 7 Mar 2022 14:01:05 +0100 From: Toerless Eckert To: emailcore@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Archived-At: Subject: [Emailcore] How to send email to user@gmail.com ? 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, 07 Mar 2022 13:01:26 -0000 Sorry to send a question to the list that is purely operational in nature, but i wouldn't know a better list to ask such as question. if gmail was not free, they wouldn't answe... Since a few weeks ? I am having more and more trouble to do IETF work because many colleagues i need to send email to have gmail accounts, and i am more and more often getting the error message below from gmail, and the URL that google points to has the whole kitchen sink of possible anti-spam precautions that gmail seemingly would like to offload to senders of email. Which seems to me like a nice abuse of market power on behalv of gmail. That email was just a test email i sent to my own gmail account. And interestingly, the first email i sent made it through to my mailbox, and when i sent an email again a few minutes later it failed. Oh: bonus question: Any recommendations for another email service to use instead of gmail ? (this is not the only problem i encountered, gmail also announced they are shutting down supposedly "insecure" access to sending mail, so i can not even send emails from my service provider installed home router...). Thanks & cheers Toerless In-Reply-To: <20220307125430.2FC51549A2E@faui40.informatik.uni-erlangen.de> On Mon, Mar 07, 2022 at 01:54:30PM +0100, Mail Delivery System wrote: > This is the mail system at host faui40.informatik.uni-erlangen.de. > > I'm sorry to have to inform you that your message could not > be delivered to one or more recipients. It's attached below. > > For further assistance, please send mail to postmaster. > > If you do so, please include this problem report. You can > delete your own text from the attached returned message. > > The mail system > > : host > gmail-smtp-in.l.google.com[2a00:1450:400c:c0a::1a] said: 550-5.7.26 This > message does not have authentication information or fails to 550-5.7.26 > pass authentication checks. To best protect our users from spam, the > 550-5.7.26 message has been blocked. Please visit 550-5.7.26 > https://support.google.com/mail/answer/81126#authentication for more 550 > 5.7.26 information. n13-20020a056000170d00b001f1eb289340si4396727wrc.790 - > gsmtp (in reply to end of DATA command) > Reporting-MTA: dns; faui40.informatik.uni-erlangen.de > X-Postfix-Queue-ID: 48F455499E9 > X-Postfix-Sender: rfc822; eckert@i4.informatik.uni-erlangen.de > Arrival-Date: Mon, 7 Mar 2022 13:54:27 +0100 (CET) > > Final-Recipient: rfc822; toerless.eckert@gmail.com > Original-Recipient: rfc822;toerless.eckert@gmail.com > Action: failed > Status: 5.7.26 > Remote-MTA: dns; gmail-smtp-in.l.google.com > Diagnostic-Code: smtp; 550-5.7.26 This message does not have authentication > information or fails to 550-5.7.26 pass authentication checks. To best > protect our users from spam, the 550-5.7.26 message has been blocked. > Please visit 550-5.7.26 > https://support.google.com/mail/answer/81126#authentication for more 550 > 5.7.26 information. n13-20020a056000170d00b001f1eb289340si4396727wrc.790 - > gsmtp > Date: Mon, 7 Mar 2022 13:54:27 +0100 > From: Toerless Eckert > To: toerless.eckert@gmail.com > Subject: Test 2 from tte@cs.fau.de > > > -- > --- > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Mon Mar 7 07:57:02 2022 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 1479B3A0E54 for ; Mon, 7 Mar 2022 07:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=RhaFdYml; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=e3KoDHRh 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 ZcmdHi-sG4Wf for ; Mon, 7 Mar 2022 07:56:52 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C053A0D0E for ; Mon, 7 Mar 2022 07:56:41 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 72DD85C01C5; Mon, 7 Mar 2022 10:56:40 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Mon, 07 Mar 2022 10:56:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; bh=tSk7mbf/GFP/Dh ZdF6IHBRfT34uAHxxBINrzmfq8q48=; b=RhaFdYml8MzKO3xUNsjn+CfQICLYrR jwVWb6xzTVvtdi+1eHAXqEAKU5xdnndPn1S64oRMqi8QCTnM9VjFdMCxKdK+q2IQ KUzl3pv8LI2VJCrnfeTiaCpRjhXGmBXWf+kX+vDxvqYv005zP/YoCwh9STAsAj3k H5ao8oGOkK7CpvUrG46GvklZEL6E3ombKu/GP0e2NjSRoUHR2MDNBQlWzFBYgIDw RQlzTbyDB+VwMMFFdAR37IPLledt1n1j4FJ7nzqSFeGuOOVPmvzV2gQK9/K/Klfo nAy3Jd+NxfpndGqRxRJy3XmzoJxudb6Ax7j8KxnEU2Khq/mJGTkbiubw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=tSk7mbf/GFP/DhZdF 6IHBRfT34uAHxxBINrzmfq8q48=; b=e3KoDHRhBaydrw9TZWaD/MgV0DQ4v58sR fp7lgU5wGWPilrlJFVn8bhGqyjhjep0GrAmmnWRQVHsdF8Ir8sG2QcyNLf55hWKh AHxdNsSgyVuJkcyMDsntWzaH6JnK+gzUeWJHyVhgmTCgTZIkpx642iYY0rcHGSNb wNvZCbd7FYqvVXq8OclO2Ym2d/7OhjsdXRjGtuA1r6z4BHA3KsME6IcFPjtdEcEV F/yu/AEwV60LosDLql8/l20lbdF9e4CN2QEHiP0JXwKQaVK6MepUwLXLDgFE5uKu VczhKNLkrpmHxApS0t42kvuhMy6VRFR0LLQAaZHPpw578RR6kZHMg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddugedgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeelveegueevve eulefhfffgffdtjeffgfeitdekveeliefhleffgeekgfdtuddtvdenucffohhmrghinhep uhhnihdqvghrlhgrnhhgvghnrdguvgdpghhoohhglhgvrdgtohhmpdhivghtfhdrohhrgh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhho nhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0FFE4AC0E98; Mon, 7 Mar 2022 10:56:40 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4849-gd25ea29a5a-fm-20220301.001-gd25ea29a Mime-Version: 1.0 Message-Id: <7178c9c5-3873-43ed-9ea8-df5c03cf64e3@dogfood.fastmail.com> In-Reply-To: References: Date: Mon, 07 Mar 2022 07:56:19 -0800 From: "Bron Gondwana" To: "Toerless Eckert" , emailcore@ietf.org Content-Type: multipart/alternative; boundary=13e435a798d84a33ac77e8ece792eb94 Archived-At: Subject: Re: [Emailcore] How to send email to user@gmail.com ? 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, 07 Mar 2022 15:56:58 -0000 --13e435a798d84a33ac77e8ece792eb94 Content-Type: text/plain Sounds like your sending host doesn't have DKIM and/or SPF, or it's set up incorrectly. You'll have issues with a lot more than just gmail. You appear to be sending via IPV6. Are your connections coming from inside the range `2001:638:a000::/48` ? Also, are your emails DKIM signed? Gmail is significantly more strict about authentication for mail over IPv6. I see that your sending domain doesn't provide a DMARC record, so this could be the issue since it's sending over IPV6. And yes, "supposedly insecure" is flat out insecure - there's no way to authenticate that your home router isn't somebody else's home router in the general sense. Regards, Bron. On Mon, Mar 7, 2022, at 05:01, Toerless Eckert wrote: > Sorry to send a question to the list that is purely operational in nature, > but i wouldn't know a better list to ask such as question. > if gmail was not free, they wouldn't answe... > > Since a few weeks ? I am having more and more trouble to do IETF work because > many colleagues i need to send email to have gmail accounts, and i am more and > more often getting the error message below from gmail, and the URL that google > points to has the whole kitchen sink of possible anti-spam precautions that > gmail seemingly would like to offload to senders of email. Which seems to me > like a nice abuse of market power on behalv of gmail. That email was just a test > email i sent to my own gmail account. And interestingly, the first email i sent made it through > to my mailbox, and when i sent an email again a few minutes later it failed. > > Oh: bonus question: Any recommendations for another email service to use instead of gmail ? > (this is not the only problem i encountered, gmail also announced they are shutting down > supposedly "insecure" access to sending mail, so i can not even send emails from my > service provider installed home router...). > > Thanks & cheers > Toerless > > In-Reply-To: <20220307125430.2FC51549A2E@faui40.informatik.uni-erlangen.de> > > On Mon, Mar 07, 2022 at 01:54:30PM +0100, Mail Delivery System wrote: > > This is the mail system at host faui40.informatik.uni-erlangen.de. > > > > I'm sorry to have to inform you that your message could not > > be delivered to one or more recipients. It's attached below. > > > > For further assistance, please send mail to postmaster. > > > > If you do so, please include this problem report. You can > > delete your own text from the attached returned message. > > > > The mail system > > > > : host > > gmail-smtp-in.l.google.com[2a00:1450:400c:c0a::1a] said: 550-5.7.26 This > > message does not have authentication information or fails to 550-5.7.26 > > pass authentication checks. To best protect our users from spam, the > > 550-5.7.26 message has been blocked. Please visit 550-5.7.26 > > https://support.google.com/mail/answer/81126#authentication for more 550 > > 5.7.26 information. n13-20020a056000170d00b001f1eb289340si4396727wrc.790 - > > gsmtp (in reply to end of DATA command) > > > Reporting-MTA: dns; faui40.informatik.uni-erlangen.de > > X-Postfix-Queue-ID: 48F455499E9 > > X-Postfix-Sender: rfc822; eckert@i4.informatik.uni-erlangen.de > > Arrival-Date: Mon, 7 Mar 2022 13:54:27 +0100 (CET) > > > > Final-Recipient: rfc822; toerless.eckert@gmail.com > > Original-Recipient: rfc822;toerless.eckert@gmail.com > > Action: failed > > Status: 5.7.26 > > Remote-MTA: dns; gmail-smtp-in.l.google.com > > Diagnostic-Code: smtp; 550-5.7.26 This message does not have authentication > > information or fails to 550-5.7.26 pass authentication checks. To best > > protect our users from spam, the 550-5.7.26 message has been blocked. > > Please visit 550-5.7.26 > > https://support.google.com/mail/answer/81126#authentication for more 550 > > 5.7.26 information. n13-20020a056000170d00b001f1eb289340si4396727wrc.790 - > > gsmtp > > > Date: Mon, 7 Mar 2022 13:54:27 +0100 > > From: Toerless Eckert > > To: toerless.eckert@gmail.com > > Subject: Test 2 from tte@cs.fau.de > > > > > > -- > > --- > > tte@cs.fau.de > > > -- > --- > tte@cs.fau.de > > -- > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --13e435a798d84a33ac77e8ece792eb94 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Sounds like your sending host doesn't have DKIM and/or SPF= , or it's set up incorrectly.  You'll have issues with a lot more t= han just gmail.

You appear to be sending via IPV6.  = Are your connections coming from inside the range 2001:638:a000::/48 ?  Also, are your emai= ls DKIM signed?

Gmail is si= gnificantly more strict about authentication for mail over IPv6.  I= see that your sending domain doesn't provide a DMARC record, so this co= uld be the issue since it's sending over IPV6.

And yes, "supposedly insecure" is flat out insecure = - there's no way to authenticate that your home router isn't somebody el= se's home router in the general sense.

Regards,
<= span id=3D"lblResult">
Bron.

On Mon, Mar 7, 2022, at 05:01, Toerless Eckert = wrote:
Sorry to send a question to the list that is pu= rely operational in nature,
b= ut i wouldn't know a better list to ask such as question.
if gmail was not free, they wouldn't answe.= ..

Since a few weeks ? I am having more and more trouble = to do IETF work because
many = colleagues i need to send email to have gmail accounts, and i am more an= d
more often getting the erro= r message below from gmail, and the URL that google
points to has the whole kitchen sink of possible an= ti-spam precautions that
gmai= l seemingly would like to offload to senders of email. Which seems to me=
like a nice abuse of market = power on behalv of gmail. That email was just a test
email i sent to my own gmail account. And intere= stingly, the first email i sent made it through
to my mailbox, and when i sent an email again a few m= inutes later it failed.

<= /div>
Oh: bonus question: Any recommend= ations for another email service to use instead of gmail ?
(this is not the only problem i encountere= d, gmail also announced they are shutting down
supposedly "insecure" access to sending mail, so i can= not even send emails from my
service provider installed home router...).

Thanks &= cheers
    To= erless


On Mon, Mar 07= , 2022 at 01:54:30PM +0100, Mail Delivery System wrote:
> This is the mail system at host faui40.i= nformatik.uni-erlangen.de.
&g= t; 
> I'm sorry to ha= ve to inform you that your message could not
> be delivered to one or more recipients. It's attach= ed below.
> 
> For further assistance, please s= end mail to postmaster.
>&= nbsp;
> If you do so, plea= se include this problem report. You can
> delete your own text from the attached returned message.=
> 
>       =             = The mail system
> 
> <toerless.eckert@gmail.com>: host
>     gmail-sm= tp-in.l.google.com[2a00:1450:400c:c0a::1a] said: 550-5.7.26 This
>     message= does not have authentication information or fails to 550-5.7.26
>     pass au= thentication checks. To best protect our users from spam, the
<= div style=3D"font-family:Arial;">>     550-5.7.26= message has been blocked. Please visit 550-5.7.26
>     5.7.26 infor= mation. n13-20020a056000170d00b001f1eb289340si4396727wrc.790 -
=
>     gsmtp (in= reply to end of DATA command)

> Reporting-MTA: dns; f= aui40.informatik.uni-erlangen.de
> X-Postfix-Queue-ID: 48F455499E9
> X-Postfix-Sender: rfc822; eckert@i4.informatik.uni-erlangen.de=
> Arrival-Date: Mon, = ; 7 Mar 2022 13:54:27 +0100 (CET)
> 
> Final-Re= cipient: rfc822; toerl= ess.eckert@gmail.com
>= Original-Recipient: rfc822;toerless.eckert@gmail.com
> Action: failed
> St= atus: 5.7.26
> Remote-MTA:= dns; gmail-smtp-in.l.google.com
> Diagnostic-Code: smtp; 550-5.7.26 This message does not have au= thentication
>  =    information or fails to 550-5.7.26 pass authentication chec= ks. To best
>  &= nbsp;  protect our users from spam, the 550-5.7.26 message has been= blocked.
>  &nb= sp;  Please visit 550-5.7.26
>     5.7.26 information. n13-2002= 0a056000170d00b001f1eb289340si4396727wrc.790 -
>     gsmtp

>= Date: Mon, 7 Mar 2022 13:54:27 +0100
> From: Toerless Eckert <tte@cs.fau.de>
> Subject: Test= 2 from tte@cs.fau.de
> 
> 
&= gt; -- 
> ---

=

-- 
---
<= /div>

<= div style=3D"font-family:Arial;">-- 
Emailcore mailing list
Emailcore@ietf.org
<= /div>


--
  Bron G= ondwana, CEO, Fastmail Pty Ltd
  = brong@fastmailteam.com


--13e435a798d84a33ac77e8ece792eb94-- From nobody Mon Mar 7 08:41:18 2022 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 9125D3A0D1D for ; Mon, 7 Mar 2022 08:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 op9xiEShFt3q for ; Mon, 7 Mar 2022 08:41:14 -0800 (PST) Received: from veps.esmtp.org (veps.esmtp.org [155.138.203.148]) (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 EFA723A1221 for ; Mon, 7 Mar 2022 08:39:57 -0800 (PST) Received: from veps.esmtp.org (localhost. [127.0.0.1]) by veps.esmtp.org (MeTA1-1.1.Alpha17.0) with ESMTPS (TLS=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256, verify=OK) id S000000000002439800; Mon, 7 Mar 2022 16:39:56 +0000 Received: (from ca@localhost) by veps.esmtp.org (8.16.1/8.12.10.Beta0/Submit) id 227GdtdB075295 for emailcore@ietf.org; Mon, 7 Mar 2022 16:39:55 GMT Date: Mon, 7 Mar 2022 16:39:55 +0000 From: Claus Assmann To: emailcore@ietf.org Message-ID: <20220307163955.GA47922@veps.esmtp.org> Reply-To: emailcore@ietf.org Mail-Followup-To: emailcore@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Emailcore] How to send email to user@gmail.com ? 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, 07 Mar 2022 16:41:16 -0000 On Mon, Mar 07, 2022, Toerless Eckert wrote: > I am having more and more trouble to do IETF work because > many colleagues i need to send email to have gmail accounts, Maybe use the "matching" IETF mailing list, so it's their server, not yours, which contacts gmail? > Which seems to me > like a nice abuse of market power on behalv of gmail. "We don't care, we don't have to, we are the phone company." Agreed -- I am also getting more rejects even though I had communicated with the same people before. (No, I won't set up all the stuff that gmail requires... it's more and more -- where/when will it stop? - when you pay them money?) -- Address is valid for this mailing list only, please do not reply to it directly, but to the list. From nobody Mon Mar 7 10:56:53 2022 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 8E3E53A07B4 for ; Mon, 7 Mar 2022 10:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 fAFgF6Vda32E for ; Mon, 7 Mar 2022 10:56:45 -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 88B543A0115 for ; Mon, 7 Mar 2022 10:56:45 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nRIXD-000PK8-T6; Mon, 07 Mar 2022 13:56:43 -0500 Date: Mon, 07 Mar 2022 13:56:37 -0500 From: John C Klensin To: Alexey Melnikov cc: emailcore@ietf.org, John R Levine Message-ID: <3FF5676D01541E9B4A1B7383@PSB> In-Reply-To: <97080ca8-270d-4543-8775-98ca8b498e72@www.fastmail.com> References: <20220122042951.379BB355E84F@ary.qy> <66bead97-dff3-4968-b4eb-473d4ec6e65b@www.fastmail.com> <1F0956DF9B26AAD73B20287F@PSB> <97080ca8-270d-4543-8775-98ca8b498e72@www.fastmail.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] Post-Interim question about Section 3.4.2 of draft-ietf-emailcore-rfc5321bis-08 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, 07 Mar 2022 18:56:51 -0000 --On Monday, March 7, 2022 10:52 +0000 Alexey Melnikov wrote: >... >> It seems to me that, after the interim and the subsequent >> discussion, we have multiple options. In no particular order: >> (1) Leave the RFC 5321 text (in Section 3.9 there and Section >> 3.4.2 of 5321bis-10 (forthcoming) unchanged. In the latter, >> that sentence reads: >> >> However, in this case, the message header section (RFC >> 5322 [12]) MUST be left unchanged; in particular, the >> "From" field of the header section is unaffected. >> >> (2) Remove that sentence and replace it with nothing. >> >> (3) Replace that sentence with >> >> This change to MAIL FROM doesn't affect the header >> section of the message. >> >> (4) Replace the sentence with something like >> >> This change to MAIL FROM does not affect any header that >> is already present in the message. > > Did you mean "header" or "header field"? "Header field". I should not compose messages at 2AM. >> For the last two options, I'm not sure whether we are agreed >> on the descriptive "does not" or if we intend a normative >> MUST or SHOULD. > > Either of the last 2 work for me. I don't think we need > normative language in either case. Concur. Anyone who has a strong preference, or who wants to argue for either of the first two, should speak up. Otherwise, I will likely use (4) because, as John Levine suggested, (3) could be read as prohibiting adding additional header fields. I'm not sure that is an important case, but there is no reason to leave confusion about whether it would be prohibited or not. >> I've added a note to the working copy of -10 flagging this. Barring more interruptions, -10 should be posted with the hour. thanks, john From nobody Mon Mar 7 11:19:05 2022 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 F18383A113D for ; Mon, 7 Mar 2022 11:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 kfejGjvw0XGB for ; Mon, 7 Mar 2022 11:19:00 -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 A81263A0F44 for ; Mon, 7 Mar 2022 11:19:00 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nRIsl-000PNs-C7 for emailcore@ietf.org; Mon, 07 Mar 2022 14:18:59 -0500 Date: Mon, 07 Mar 2022 14:18:52 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: 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] draft-ietf-emailcore-rfc5321bis-10 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, 07 Mar 2022 19:19:03 -0000 EMAILCORE WG, As promised (threatened?) -10 is now in the posting queue and will, I assume, appear RSN. It contains few substantive changes since -09, partially because I got very busy in the interim but more because few of the issues that came up before or during the Interim have been unambiguously resolved since then (as some postings within the last 24 hours make clear). I have done some future cleaning up, inserted or revised notes to further clarify the issues or alternatives, and left notes to myself (ones that you won't see) that will make it easier to fix the text for some issues once they are resolved. I've also made a pass through the tickets to see if I could improve the alignment between that list and the document (and, I hope, gotten that right). As usual, there is an Appendix, H.3.14 in this version, that gives a more detailed description of changes. Happy reading. john From nobody Mon Mar 7 11:19:30 2022 Return-Path: X-Original-To: emailcore@ietf.org Delivered-To: emailcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 508F83A1206; Mon, 7 Mar 2022 11:19:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emailcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <164668075525.9158.5575120452711501674@ietfa.amsl.com> Date: Mon, 07 Mar 2022 11:19:15 -0800 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5321bis-10.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2022 19:19:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Revision of core Email specifications WG of the IETF. Title : Simple Mail Transfer Protocol Author : John C. Klensin Filename : draft-ietf-emailcore-rfc5321bis-10.txt Pages : 125 Date : 2022-03-07 Abstract: This document is a specification of the basic protocol for Internet electronic mail transport. It (including text carried forward from RFC 5321) consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. The document also provides information about use of SMTP for other than strict mail transport and delivery. This document replaces RFC 5321, the earlier version with the same title. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5321bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-rfc5321bis-10 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Mar 7 11:22:11 2022 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 E10E33A12BD for ; Mon, 7 Mar 2022 11:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 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, T_SCC_BODY_TEXT_LINE=-0.01, 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 VMIGI-RaQ8KA for ; Mon, 7 Mar 2022 11:21:56 -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 BCBA73A1290 for ; Mon, 7 Mar 2022 11:21:55 -0800 (PST) Received: (qmail 32133 invoked from network); 7 Mar 2022 19:21:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:reply-to:to:subject:in-reply-to:references:mime-version:content-type; s=7d82.62265b51.k2203; bh=Vm8VJP7rXHnQrRfS86pGVY9ino+duB3OGPORZ+htmyU=; b=qYCoapWpzv1wpMdm5f97kkGIK0O6UI3BP8BkvnxjW7dA6SVyBQ/GVqLQESoEHYbP//VnTxCOscfuTojWRDWxovWiEiroi0VDzVb+M7qqAt+9CscG0lRGur7m/zGFz9BoPJ9m4MHhQpACRZFtt4uQOSShvy7Z+s5pqYbQ85VwU6502K1cmg8u5ZBQC2z8iryt4TovU8lDhAjC7zhli/FQgT8B/JIe6/hkqwbwbN+Y4NNB6/BGZuFbikG8vUGrD8tfF/0FPghwHJkrfR8bMkmhGewQKMkLjUu2VQ+K/Kk0ljg7ypZphkdBUD7RndC4U2Qj17coEES4y4zSVY7iwAFr5g== 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; 07 Mar 2022 19:21:52 -0000 Received: by ary.qy (Postfix, from userid 501) id 0079238A0476; Mon, 7 Mar 2022 14:21:50 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 4097138A0458; Mon, 7 Mar 2022 14:21:50 -0500 (EST) Date: 7 Mar 2022 14:21:50 -0500 Message-ID: <7dc816a9-cacd-4207-2e72-0e17b61cdd49@iecc.com> From: "John R. Levine" Reply-To: johnl@iecc.com To: "Toerless Eckert" , emailcore@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] How to send email to user@gmail.com ? 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, 07 Mar 2022 19:22:07 -0000 > Since a few weeks ? I am having more and more trouble to do IETF work because > many colleagues i need to send email to have gmail accounts, and i am more and > more often getting the error message below from gmail, ... They have been tightening up their validation rules. Your SPF record seems to be OK but I agree that DKIM signing is likely to help a lot. > Oh: bonus question: Any recommendations for another email service to use instead of gmail ? If you want a free mail provider, you get what you pay for. Among paid providers, Fastmail has a good reputation and Bron would never tout his own service. > (this is not the only problem i encountered, gmail also announced they are shutting down > supposedly "insecure" access to sending mail, so i can not even send emails from my > service provider installed home router...). To send mail through Gmail you need to authenticate with oauth. This is tedious but it does work. I set up my gmail account in my copy of Alpine yesterday. 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 Mon Mar 7 14:22:47 2022 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 B10B23A0D42 for ; Mon, 7 Mar 2022 14:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 KVXhQigprIFL for ; Mon, 7 Mar 2022 14:22:40 -0800 (PST) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 6A2D43A1316 for ; Mon, 7 Mar 2022 14:22:25 -0800 (PST) Received: from kent.sdaoden.eu (kent.sdaoden.eu [192.0.2.2]) by sdaoden.eu (Postfix) with ESMTPS id F11A016057; Mon, 7 Mar 2022 23:22:22 +0100 (CET) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 8BCA866086; Mon, 7 Mar 2022 23:22:21 +0100 (CET) Date: Mon, 07 Mar 2022 23:22:21 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: emailcore@ietf.org Cc: "Toerless Eckert" Message-ID: <20220307222221.w_fAY%steffen@sdaoden.eu> In-Reply-To: <7dc816a9-cacd-4207-2e72-0e17b61cdd49@iecc.com> References: <7dc816a9-cacd-4207-2e72-0e17b61cdd49@iecc.com> Mail-Followup-To: emailcore@ietf.org, "Toerless Eckert" User-Agent: s-nail v14.9.23-243-g00c89d995b OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Archived-At: Subject: Re: [Emailcore] How to send email to user@gmail.com ? 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, 07 Mar 2022 22:22:45 -0000 John R. Levine wrote in [I left you off To:, right. I hate that bouncing.] <7dc816a9-cacd-4207-2e72-0e17b61cdd49@iecc.com>: |> Since a few weeks ? I am having more and more trouble to do IETF \ |> work because |> many colleagues i need to send email to have gmail accounts, and \ |> i am more and |> more often getting the error message below from gmail, ... | |They have been tightening up their validation rules. Your SPF record |seems to be OK but I agree that DKIM signing is likely to help a lot. ... |> (this is not the only problem i encountered, gmail also announced \ |> they are shutting down |> supposedly "insecure" access to sending mail, so i can not even send \ |> emails from my |> service provider installed home router...). | |To send mail through Gmail you need to authenticate with oauth. This is |tedious but it does work. I set up my gmail account in my copy of Alpine |yesterday. You can use 2-factor with an application-specific password, and that works with authentication schemes which do not need JSON and HTTP 1/[2/3] and a browser (but for setup). I hope they do not shut that down? --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Mon Mar 7 14:25:11 2022 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 94D4B3A0D1F for ; Mon, 7 Mar 2022 14:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 G12z1yJvffNo for ; Mon, 7 Mar 2022 14:25:05 -0800 (PST) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 10DC23A12E6 for ; Mon, 7 Mar 2022 14:24:52 -0800 (PST) Received: from kent.sdaoden.eu (kent.sdaoden.eu [192.0.2.2]) by sdaoden.eu (Postfix) with ESMTPS id C7F4F16057; Mon, 7 Mar 2022 23:24:49 +0100 (CET) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 7674F66088; Mon, 7 Mar 2022 23:24:48 +0100 (CET) Date: Mon, 07 Mar 2022 23:24:48 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: emailcore@ietf.org Cc: Toerless Eckert Message-ID: <20220307222448.A0vPg%steffen@sdaoden.eu> In-Reply-To: <20220307222221.w_fAY%steffen@sdaoden.eu> References: <7dc816a9-cacd-4207-2e72-0e17b61cdd49@iecc.com> <20220307222221.w_fAY%steffen@sdaoden.eu> Mail-Followup-To: emailcore@ietf.org, Toerless Eckert User-Agent: s-nail v14.9.23-243-g00c89d995b OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Archived-At: Subject: Re: [Emailcore] How to send email to user@gmail.com ? 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, 07 Mar 2022 22:25:10 -0000 Steffen Nurpmeso wrote in <20220307222221.w_fAY%steffen@sdaoden.eu>: |John R. Levine wrote in | <7dc816a9-cacd-4207-2e72-0e17b61cdd49@iecc.com>: ||> Since a few weeks ? I am having more and more trouble to do IETF \ ||> work because ||> many colleagues i need to send email to have gmail accounts, and \ ||> i am more and ||> more often getting the error message below from gmail, ... || ||They have been tightening up their validation rules. Your SPF record ||seems to be OK but I agree that DKIM signing is likely to help a lot. | ... ||> (this is not the only problem i encountered, gmail also announced \ ||> they are shutting down ||> supposedly "insecure" access to sending mail, so i can not even send \ ||> emails from my ||> service provider installed home router...). || ||To send mail through Gmail you need to authenticate with oauth. This is ||tedious but it does work. I set up my gmail account in my copy of Alpine ||yesterday. | |You can use 2-factor with an application-specific password, and |that works with authentication schemes which do not need JSON and |HTTP 1/[2/3] and a browser (but for setup). Not to mention that it seems impossible to get an OAUTH "client secret" (?) for a normal console based application at GMail. |I hope they do not shut that down? --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Mon Mar 7 19:47:53 2022 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 919843A0CF7 for ; Mon, 7 Mar 2022 19:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zXoFY8Fm4fhR for ; Mon, 7 Mar 2022 19:47:47 -0800 (PST) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 E07A73A0CF4 for ; Mon, 7 Mar 2022 19:47:46 -0800 (PST) Received: by mail-vk1-xa2a.google.com with SMTP id az23so4181040vkb.0 for ; Mon, 07 Mar 2022 19:47:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f2Z4AxiDdXKks3ZpTb5y9RyfZqK4kFM/WScl8InkD2M=; b=FtM7Vrm5xmP8WGfYv6bUX+UlxmSDxnEo170akDUegENEVYmyVG1eTVnOwsbhvfQotw e9cgXpNY9uVkBfjDbUcWh7olempYVLJWGCKeF/o7GH880afhAlxFgFZ2MqP4vmgezcSl alwSG0VohtGCjQ7ddl8VX4An4GdszUHFkc+JeDc5WEtlTV9utksEwh9UJNr2gw5z/mIR yA8dCqkAGRUl1+FpoQ3kKdteLABkUXgHRKQ+g8c19Zw0CuceJCBlFbirSIlpWZUml//G 98lg8K3PBCaO5s7gzUixGdMEVLVnKThsnRjU8ubywRoVKBp1+DWYi2xjg64j/JsPXXkp g/hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f2Z4AxiDdXKks3ZpTb5y9RyfZqK4kFM/WScl8InkD2M=; b=PGe4rcah5vSMNahWhdvNouA8RXCANT1c7QbvjDEnUVf1Z8jkA/964ymlhu0ir8UUUC vxGnsVPxHPd3AksPj6hBuarzb6zlBMstFut+U74VfVtzDTsQLrZLapLrFdDRF7dPfW9W lu0XJ2xu8hHJmnVeRVOAlZvZjRHosdt+yWSq0LV/hYzieqiWd4T3MS8ptwEXQ3dj0CPT DNCA2d/NwHEq8tcYsNnJ/kK0KoMpEeqjPI7vra9qAiU4/lSyxLrd4SKYYGVvaaJc9W3+ MM4zqspjmRDM/4CJbkepOZ8R5K853Hb4vz6u+oh9tas/mN2JqQkleIzQoXgN3tuLyDlJ UQ+A== X-Gm-Message-State: AOAM530xwwT1QDZbQgNUR6EhnIbmdNec53PwWdHqrrLWT+8MV969EuYm iaSpcVPjdNj1IpOVDj8u1txij5RBqe+nRYiMv8LhVmMY X-Google-Smtp-Source: ABdhPJwoV15PVSNPX3NnyjjpIOfhT0hmjDUWVU8pSZO3YSDxOZz2M2GB88zwHUBV/RCQnNcl/XOpaeASkIduCYo+SPc= X-Received: by 2002:a05:6122:ca8:b0:337:863b:a660 with SMTP id ba40-20020a0561220ca800b00337863ba660mr1620485vkb.8.1646711265328; Mon, 07 Mar 2022 19:47:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 7 Mar 2022 19:47:33 -0800 Message-ID: To: Alessandro Vesely Cc: emailcore@ietf.org Content-Type: multipart/alternative; boundary="00000000000004816505d9acd850" Archived-At: Subject: Re: [Emailcore] Should rfc5322bis register an Email Authentication Method to report overall format conformance? 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, 08 Mar 2022 03:47:52 -0000 --00000000000004816505d9acd850 Content-Type: text/plain; charset="UTF-8" On Sat, Mar 5, 2022 at 6:09 AM Alessandro Vesely wrote: > perhaps I should have questioned ietf-822 about this idea. However, since > the > standard is now being revised, perhaps it makes more sense to ask here > directly. > > As is well known, RFC 8601 provides ways to describe the level of trust > that a > message is considered to deserve, according to a variety of methods, in an > Authentication-Results: (A-R) header field. Deep down, all methods rely > on the > mail format. However, the format itself is not reported directly. > > For example, a popular DKIM filter has an option to refuse processing of a > message if the header field count does not conform to RFC5322 Section 3.6. > That stems from inconsistencies among different software about how to > treat > anomalies such as multiple From: fields, which can result in > authenticating a > field which is not the one displayed.[*] > > What to do in such cases? The old message just exemplified[*] had a > cryptographically correct A-R: > [...] > Using an authentication reporting mechanism to indicate something about compliance or format checking seems a lot like scope creep to me. -MSK, with no particular hat on --00000000000004816505d9acd850 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Mar 5, 2022 at 6:09 AM Alessandro= Vesely <vesely@tana.it> wrote:=
perhaps I should have questioned ietf-822 about this idea.=C2= =A0 However, since the
standard is now being revised, perhaps it makes more sense to ask here dire= ctly.

As is well known, RFC 8601 provides ways to describe the level of trust tha= t a
message is considered to deserve, according to a variety of methods, in an =
Authentication-Results: (A-R) header field.=C2=A0 Deep down, all methods re= ly on the
mail format.=C2=A0 However, the format itself is not reported directly.

For example, a popular DKIM filter has an option to refuse processing of a =
message if the header field count does not conform to RFC5322 Section 3.6. =
That stems from inconsistencies among different software about how to treat=
anomalies such as multiple From: fields, which can result in authenticating= a
field which is not the one displayed.[*]

What to do in such cases?=C2=A0 The old message just exemplified[*] had a <= br> cryptographically correct A-R:
[...]

Using an authentication reporting mech= anism to indicate something about compliance or format checking seems a lot= like scope creep to me.

-MSK, with no particular hat on
--00000000000004816505d9acd850-- From nobody Mon Mar 7 20:23:46 2022 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 98CE13A0D8D for ; Mon, 7 Mar 2022 20:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.861 X-Spam-Level: X-Spam-Status: No, score=-1.861 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, T_SCC_BODY_TEXT_LINE=-0.01, 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=krWWyXrZ; dkim=pass (2048-bit key) header.d=taugh.com header.b=sGZ5Bugo 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 zISufNYc5f0U for ; Mon, 7 Mar 2022 20:23:38 -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 774AD3A0990 for ; Mon, 7 Mar 2022 20:23:38 -0800 (PST) Received: (qmail 52409 invoked from network); 8 Mar 2022 04:23:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:reply-to:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=ccb6.6226da48.k2203; bh=0YkyhGva+GQcpqdlAMdQMjFpWOYHbOy3E0WasaJMBBE=; b=krWWyXrZWhOQEiNlstkt9Mz86BbB/ruau03FZz6fCmF1sm1wMAIHO+S/sdGp3wTLn7Kd95+5Go5qd8jtaQs4W/TH0lmoSzVYZyMndzqFG0JDRlR1TltVVXY1ON4rnjdm0dVnmSooHiM/21cqbC9ujQOi+xAvqeb5b15WQa97R7pyB7AeO2pUAp+5PmL5YrE3MOAo/moHHsMn3hBYx44CyJA7ZqnDZ6ZQ+sc882MiolC4jvup0F3F0pzwKz5NAniF0pLkYxEF/GWq6a0lLksZrLMClqzLNiZ8B60FBNsmT3Bf3PVEprg6XtbZC7XQhdVHjMgibgngZk5pgT42d6R3WQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:reply-to:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=ccb6.6226da48.k2203; bh=0YkyhGva+GQcpqdlAMdQMjFpWOYHbOy3E0WasaJMBBE=; b=sGZ5BugoId/QrpM0g2GWK+Tt7XCzK3rogDRTGrSIGCARxej/yQQvZ5sgQ1xdgc1+y0ifN7G/qfjK13oS78eBYRc3hTz643zPd2IFCHfVW3x8HuR5HVoGUgqckZe5GNgIGyhH7GCyGszIUNSS5vFEYuTGUIJ9zUAmzufDBZIc3yRmoI5nt5YvheLLLmhJzdggsgzFrGcoZaToI9dMI0WImgwiZsdVBuEs5wE+r/n9ZVcZ6bNmBQ7NRAYiV2wO+sPVz+MM8YIaF7qwkwujZgYCVyN9QPtfQNdivCTQXvvQkvUJp8XXBjfzXS2UpBYylQiovEilwmOJd5cFPu6yg3GjoA== 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; 08 Mar 2022 04:23:35 -0000 Received: by ary.qy (Postfix, from userid 501) id CA2C938A7B6F; Mon, 7 Mar 2022 23:23:34 -0500 (EST) Date: 7 Mar 2022 23:23:34 -0500 Message-Id: <20220308042334.CA2C938A7B6F@ary.qy> From: "John Levine" Reply-To: ietf-smtp@ietf.org To: emailcore@ietf.org Cc: superuser@gmail.com 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] Should rfc5322bis register an Email Authentication Method to report overall format conformance? 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, 08 Mar 2022 04:23:44 -0000 It appears that Murray S. Kucherawy said: >Using an authentication reporting mechanism to indicate something about >compliance or format checking seems a lot like scope creep to me. I don't know how to define a compliance metric and I'm pretty sure nobody else does, either. For that and other reasons this is a complete non-starter. [ replies directed to a list where this is slightly less off-topic ] R's, John From nobody Tue Mar 8 19:15:33 2022 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 4E0453A0C48 for ; Tue, 8 Mar 2022 19:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 rijt2aGv6UFD for ; Tue, 8 Mar 2022 19:15:27 -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 5B3233A0C39 for ; Tue, 8 Mar 2022 19:15:27 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nRmnG-0002g3-EN; Tue, 08 Mar 2022 22:15:18 -0500 Date: Tue, 08 Mar 2022 22:15:12 -0500 From: John C Klensin To: John Levine , Sabahattin Gucukoglu , emailcore@ietf.org Message-ID: In-Reply-To: <20220307025934.E3B0738948C9@ary.qy> References: <20220307025934.E3B0738948C9@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] 5321bis-10, code 556, 521, and maybe 554 (was: Re: 5321bis-09: Thinking About Interaction of Code 556 with 'postmaster') 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, 09 Mar 2022 03:15:33 -0000 --On Sunday, March 6, 2022 21:59 -0500 John Levine wrote: > It appears that Sabahattin Gucukoglu said: >> And yes, if a non-public intermediate or submission server >> performs checks in real time on mail being submitted against >> destination MXs or mailboxes then it can obviously be >> expected to informatively explain to the client that the >> destination domain is unreachable and no further >> configuration is necessary to achieve that effect. (I expect >> that many submission servers will refuse to do this for >> policy reasons, though, or to support submission clients or >> users that react poorly to failed submissions.) (no hat) This is far out of scope for SMTP and hence 5321bis, but I have trouble imagining why a submission server configuration would feel a need to hide information about a destination domain refusing to accept mail from the submitting client. After all, those two are supposed to have a close relationship. The submission server is not some random host on the network at which the client lobs a message. RFC 5068/BCP 134 specifies that it authenticate the client and RFC 8314 requires encryption. >From the standpoint of a user sitting in front of that client, the most likely cause of a 556 error is trying to use a bad address, possibly the result of a typographical error and it is in everyone's interest that such a problem be reported with an appropriate level of clarity so that error can be corrected. Now, I suppose that if one were running an open submission server (sort of like an open relay), accepting traffic on port 25 rather than 587, the situation would be quite different. But, to put it mildly, we don't consider running such servers to be a good practice and have not for many years. Now, if someone tells me that some of the very large mail providers don't handle submission very well and hence needed to obscure information to cover up their own failings, I guess I would not be surprised. However... > Given a choice between rejecting at submission time and a > bounce later, I'll take the reject. In my experience MUAs > don't do a fabulous job of explaining the failure, but it's > better than trying to figure out a bounce. This is the most > likely scenario for 556. Agreed. >> If code 556 is relevant post-RCPT on a public MX host, it >> must be configured to refuse mail destined for an >> "unserviced" domain, as above, otherwise it would >> normally just refuse to relay mail for policy reasons for >> domains it didn't know about, or refuse mail for unknown >> mailboxes for domains it did. > > I'm with you. An MTA is either configured to accept mail for a > domain or it isn't, and it's not likely to provide helpful > opinions about the ones it's not configured for. For the vast majority of cases, I agree. See below. > I can imagine some arcane edge cases like an MTA set up as a > secondary for a null MX, but now we're into "don't do that" > territory. > > blah.wtf. MX 0 . > MX 10 secondary.wtf. <-- that one might give a 556, > maybe Right, but that would be so blatantly stupid that I assume that, were it common, those who produce DNS software would be considering adding it to their sanity test tools. But let me walk through a moderately complicated --but, IMO, plausible-- scenario because I'm no longer sure what 5321bis should say. Consider the following with the understanding that this is probably uncommon at best: As I think I mentioned in another message, consider the possibility of an enterprise, call it LittleCo, in which those who maintain DNS records and those who maintain servers that handle mail are in separate organizations. It would be an especially nasty case if one organization had outsourced, e.g., mail and web services to one provider (example1.net) but DNS services to a different one (example2.net). I gather that occurs a lot (even if it would not pass for "common"). Also assume that both example1.net and example2.net (and example3.net, which I will get to in a moment), provide services to multiple domains. Skipping assorted possible complications and using CNAME, not because it is a good idea but because it makes the example shorter, we have, on the authoritative example2.net: LittleCo.example. IN CNAME example1.net. www.LittleCo.example. IN CNAME example1.net. LittleCo.example. MX 0 example1.net. Now, someone in the management of LittleCo decides that it does not like the mail service being provided by example1.net and wants to move it to example3.net. They get the service set up on example3.net and then send out memos to the provider who runs example1.net telling them that they no longer have a contract to support mail for LittleCo and to LittleCo's DNS provider telling them to change the MX RR. If they are smart and good negotiators, they get example1.net to host a relay for a while, presumably several times the TTL, so the target DNS structure during that period looks like: LittleCo.example. IN CNAME example1.net. www.LittleCo.example. IN CNAME example1.net. LittleCo.example. MX 10 example1.net. LittleCo.example. MX 0 example3.net. If those changes do not occur in the right order and with some luck, there might be a period in which example1 still thinks it is providing a final delivery service rather than a relay one and LittleCo would be smart to plan for that. Otherwise, so far, so good. But eventually the contract between LittleCo and example1 about mail service runs out and the the DNS is changed to LittleCo.example. IN CNAME example1.net. www.LittleCo.example. IN CNAME example1.net. LittleCo.example. MX 0 example3.net. Now, for the case of concern, if someone has a cache that should have expired but has not and opens an SMTP connection to example1.net (which is also providing mail support for other domains, so it cannot return a 5yz code at initial connection time). The client sends EHLO and MAIL commands as usual, then RCPT TO: Question 1: Would we prefer that example1.com reply with 556 or 521, indicating that example1 is not providing mail service for that domain, or 550 (no mailbox for that address). Either of the first two provide much more information than the 550 and, I think, do not give out any secret information. Question 2: Assuming 556 or 521, do we have a preference and why? Do we want to reserve 556 for connection-opening only so 521 is returned here? If not, what is 521 good for? Question 3: Sections 4.2.3 and 4.2.2 say, for 554, "(Or, historically in the case of a connection-opening response, "No SMTP service here". 521 is now preferred for that function at connection-opening if the server never accepts mail.)" Is that just wrong, i.e. should it say 556 instead of 521? ... and, now... Suppose LittleCo is in the process of going out of business but still owns the domain name. Assuming it can do so, it changes the DNS entries to LittleCo.example. IN CNAME tombstone.example1.net. www.LittleCo.example. IN CNAME tombstone.example1.net. LittleCo.example. MX 0 . Now, if during some transition period (inside or outside the DNS TTL), example3.net. gets a connection attempt exactly like the one for example1.net above, i.e., the connection attempt succeeds because example3.net provides SMTP service to domains that have nothing to do with LittleCo, the EHLO and MAIL commands go through without problems, and it then gets the same RCPT command as above. Questions 4 and 5 are identical to Questions 1 and 2 above, but it is not clear that the answers should be. If it is clear what the WG wants the text to say in those five cases, I can fix at least those parts of 4.2.4.2. I am now confused about the answers to some of those questions (although I have preferences) and am wondering a bit why we introduced the 556 code (which might be close to Sabahattin's original concern... or not). john From nobody Wed Mar 9 10:01:31 2022 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 86E0A3A1028 for ; Wed, 9 Mar 2022 10:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 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, T_SCC_BODY_TEXT_LINE=-0.01, 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=LEiClgDf; dkim=pass (2048-bit key) header.d=taugh.com header.b=Fi7nr4C3 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 P9jojFRXwxbc for ; Wed, 9 Mar 2022 10:01: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 E55593A1030 for ; Wed, 9 Mar 2022 10:01:21 -0800 (PST) Received: (qmail 51873 invoked from network); 9 Mar 2022 18:01:19 -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=ca9e.6228eb6f.k2203; bh=QiLugm7jGJPlp1GXw0/AcvCshuj/+tzt/WQSaQLTBrw=; b=LEiClgDfGfzQvoIh4ykOrS6534OhX5OVNz7Gyf5asQiefuUdwWdBwzYjEknWO1VcqnE38BqN8GeKO4E8Qs2mGZ4mizj5mHn2kZLMB0rzvyy+Vr/NpdF9l9PL3E+i31oKKiFo4GtcUOcWfAyxpRS87keL4vbS7j4gOzOSoMeMA/igzPwgkchAPJcHctNpy2OJZ1uT3zrUV/Kfw39K4KXdOSZmeCPcZ6qyl09AcFlecxpnVxgnUJsfvvjLs+S+ICVSVIQlwTIMYBGk9a2aJBvmg7kpFIRr3ll/PSEI7JaQaXpKeuELw7bkbk6isLPlo0V17ocY78gbe2MHirgXa0oYwg== 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=ca9e.6228eb6f.k2203; bh=QiLugm7jGJPlp1GXw0/AcvCshuj/+tzt/WQSaQLTBrw=; b=Fi7nr4C3iIY1sItsxh7ucA0sbMz+HA4cp2mrQDAC6WeGiR4hLEiv6uqt4YYIGYrs+Vd71sEA+FE99btUl3+Qwb+41AlDZQsv2JwWRifcPsnGBC7EfONmKZMDHrDwcHx9xmnF4cgekSrri+LUUC7gO9UNB9m9o61d9zYEV55bThcRjflGyNXwS4lYtZ6rYROC0vuK+l/julrIpikyKq1b/w2hNOo/fOsdBqCVTt5LrDoW5nhIU0pTXIAPKRqoI3Cu8a8+J92eJzJgN2eP2uGa/Wh/wNPX8aH5BpbFGG+9Lfj0Eforkm8ZVTZcF0olQxV/Jh0wyAVUHTWDlD+FWGgiMA== 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; 09 Mar 2022 18:01:19 -0000 Received: by ary.qy (Postfix, from userid 501) id 0EAFA38BC3F0; Wed, 9 Mar 2022 13:01:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 748CC38BC3D2; Wed, 9 Mar 2022 13:01:18 -0500 (EST) Date: 9 Mar 2022 13:01:18 -0500 Message-ID: <12d6f272-1352-fc4f-f93f-4f583d3725fb@taugh.com> From: "John R Levine" To: "John C Klensin" , emailcore@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: References: <20220307025934.E3B0738948C9@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] 5321bis-10, code 556, 521, and maybe 554 (was: Re: 5321bis-09: Thinking About Interaction of Code 556 with 'postmaster') 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, 09 Mar 2022 18:01:29 -0000 On Tue, 8 Mar 2022, John C Klensin wrote: > time). The client sends EHLO and MAIL commands as usual, then > RCPT TO: > > Question 1: Would we prefer that example1.com reply with 556 or > 521, indicating that example1 is not providing mail service for > that domain, or 550 (no mailbox for that address). In practice it's this or something close to it: 550 5.1.0 Mail system is not configured to accept that recipient > Question 3: Sections 4.2.3 and 4.2.2 say, for 554, > "(Or, historically in the case of a connection-opening > response, "No SMTP service here". 521 is now preferred > for that function at connection-opening if the server > never accepts mail.)" > Is that just wrong, i.e. should it say 556 instead of 521? No, that's fine. > Now, if during some transition period (inside or outside the DNS > TTL), example3.net. gets a connection attempt exactly like the > one for example1.net above, i.e., the connection attempt > succeeds because example3.net provides SMTP service to domains > that have nothing to do with LittleCo, the EHLO and MAIL > commands go through without problems, and it then gets the same > RCPT command as above. > > Questions 4 and 5 are identical to Questions 1 and 2 above, but > it is not clear that the answers should be. Same answer: 550 5.1.0 Mail system is not configured to accept that recipient I don't know how many ways to say that MTAs know who they accept mail for and who they don't, but they don't know *why* they don't accept mail for the ones they don't. 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 Mar 22 05:52:24 2022 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 BC0F63A1228 for ; Tue, 22 Mar 2022 05:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 Liq248ylw2gx for ; Tue, 22 Mar 2022 05:52:18 -0700 (PDT) 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 0BDFE3A1271 for ; Tue, 22 Mar 2022 05:52:17 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nWdzk-000Mp5-74 for emailcore@ietf.org; Tue, 22 Mar 2022 08:52:16 -0400 Date: Tue, 22 Mar 2022 08:52:10 -0400 From: John C Klensin To: emailcore@ietf.org Message-ID: <104C6A455630C1570E89BD01@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] Relaxing the IANA registration requirement for SMTP Extensions in rfc5321bis 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, 22 Mar 2022 12:52:23 -0000 Hi. Having become increasingly convinced over the years that high barriers to IANA registrations (of most types) don't necessarily improve quality but definitely discourage registrations and that the primary value of registrations is to prevent the same keyword accidentally being used for different things, I'm in favor of relaxing the requirements somewhat from Standards Track or IESG-approved Experimental. However, I'm afraid of losing something else in the process. One of the key points in the early work on SMTP extensions was the observation (I think first due to Marshall Rose), that too many of them is a bad thing and that each new one poses interoperability challenges. That principle appears in 5321bis in the last two paragraphs of Section 2.2.1. The requirement for IETF consensus (or, with current IESG procedures, at least a Last Call and opportunity for serious discussion) provided, in addition to the presumed gatekeeping, an opportunity for an IETF discussion and decision about whether the extension is worth the trouble. Dropping the registration threshold even as far as Specification Required eliminates the opportunity for that community discussion which has proven helpful to authors of other registrations. We should mitigate that loss by at least requiring the would-be registrants to explain themselves. That should not be a barrier to any serious extension proposal but might, almost as a side effect, raise the bar for silly vanity registrations. The latter would presumably be A Good Thing if it did not cause other problems. Suggestion: RFC 5321 Section 8, IANA Considerations, describes the three registries but does not actually specify what goes in them, nor does it follow what is now the normal practice of providing a specific registration template or list of fields and descriptions of possible values [1]. For the SMTP Extensions Registry, we should consider either specifying a template or a list of things required in an application for a Service Extension. We could then require that the registration application (or other documentation) explain the problem that the new extension is solving and the reasons why its benefits outweigh the possible costs. The idea above is compatible with either of the options in the meeting slides (at least the last time I looked at them). --john [1] Should the IESG decide to impose current standards, it is fairly clear to me that Section 8 of RFC 5321 is not in compliance with Section 2 of RFC 8126/ BCP 26. So, unless people are convinced that it will slip through because of the older document(s), we may want to think about revising that section anyway. From nobody Tue Mar 22 06:22:48 2022 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 994E33A11B9 for ; Tue, 22 Mar 2022 06:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 KKBnnKMhcVAK for ; Tue, 22 Mar 2022 06:22:43 -0700 (PDT) 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 B2E653A11A7 for ; Tue, 22 Mar 2022 06:22:43 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nWeTB-000N1B-71 for emailcore@ietf.org; Tue, 22 Mar 2022 09:22:41 -0400 Date: Tue, 22 Mar 2022 09:22:35 -0400 From: John C Klensin To: emailcore@ietf.org Message-ID: 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] RCPT commands, BCCs, and the "for" clause 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, 22 Mar 2022 13:22:46 -0000 Hi. I have been thinking about these (very connected, IMO) issues, partially in conjunction with some side conversations. My first conclusion is that they really are one basic issue and that trying to discuss them separately is just confusing us and that previous versions of that confusion may have created a hole in which we are continuing to dig. The second conclusion is that RFC 5321 says rather more about these topics than it should and that we are trying to fix the issues that text causes by adding more text and risking even more confusion (in other words, trying to get out of the hole by digging deeper). With the understanding that none of the ideas below are new except for the organization and context, my current hunch is that 5321bis should: (i) Remind people that a conforming SMTP server or (non-submission) client doesn't look at header fields, much less start performing heuristics on them, and hence does not have a clue as to which RCPT commands (or their arguments) are associated with "To:", "Cc:", or "Bcc:" header fields. Section 7.8 provides a loophole for, e.g., malware resistance measures, but does not change the principle. (ii) Mention that no attempt should be made to include "for" in a "Received:" header field if there is more than one RCPT command present, noting that this is forbidden by the syntax anyway. (iii) Clarify the text that mentions that "for" can cause unintended privacy disclosures and say that, if one is not sure of the appropriateness of the clause and the information that should go into it, it is generally better to just omit the clause. (iv) Mention as well that _any_ trace field might, under the wrong set of circumstances, disclose information that someone might consider sensitive and that, while those fields are often essential for debugging messages that have run into transport problems and may even be helpful in distinguishing spoofed or otherwise problematic messages from more desirable traffic (and even identifying the source of such bad traffic), complete protection of anything that might be considered private would argue for eliminating trace information entirely. Wordsmithing and some decisions about where to use 2119/8174 language obviously needed, but I'm hoping we can agree on the above or something like it as general principles. We then get rid of all of the hair-splitting about internal names and addresses on LANs, which addresses should be included in "for" clauses and which ones avoided, etc. If someone believes they can persuade the WG that it is worth doing the case analysis and offering more specific advice in the A/S they should certainly try (and be ready to write text). But, as far as 5321bis is concerned, my recommendation is that we concentrate on the above four points and tear everything else out. That would, IMO, improve clarity and and shorten 5321bis by a few pages. --john From nobody Tue Mar 22 07:09:50 2022 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 B5C093A1518 for ; Tue, 22 Mar 2022 07:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=EqBp2sbd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=g4M4XWOy 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 WX_1hj_Unahj for ; Tue, 22 Mar 2022 07:09:21 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D69E3A1569 for ; Tue, 22 Mar 2022 07:08:53 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id ADD305C0107; Tue, 22 Mar 2022 10:08:52 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 22 Mar 2022 10:08:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; bh=n1wcpKFmFGiVoL GQFV7wzbNYemoHaVyocwSUhUAq04o=; b=EqBp2sbdfQbZAdRzgbwvo3qCQvdbA1 HAJv89N/+Ax62OxD3p2L98ZoSw+iMDPSCzr6dFbjrOQ2ngH+LY4D/YbgOtfK42qI ChHRgWZw/DZszDS57xX8hfkhuF51KXB1FLIJ/jtnUYizPIoRPAyZQ93lsSm8CLNQ UvmPfheUaIm69SKP/fL5aCtAhiN4GpqlE+FD6vCM6mQUICk5+b5m0396gLUZKwqi PqPiAtGU7kUHq8CZyYnvgPd1XSsoJQey9HN1v+bsSjofmSM7+j9+jzgSwgpwHyva md1N8x3Ie4Z5DJE8Xa9q1AJiIXvYAlP2PBPKWpGR08l8JHdHOADp8ddA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=n1wcpKFmFGiVoLGQFV7wzbNYemoHaVyocwSUhUAq0 4o=; b=g4M4XWOybl6MDxkfWzCTHk6looa4Z90HSTe/LMqbKun3oRKeWSs6DQMQI v7DEfYJqLJk4VtQ6CK6BHffCpCNDGZS1vCvhZsVbGPV9XwXrYdDXLSSCXhDQkMss Kb6W/QfLQ7r73EwiR9TKu6BLfJFzF/G34ClzHfJEwSmca3AdEHY2h08T9yQ2xvhi Af0iYIU+3RGBmbxJtc7mlz+pfzz+fUy31Ezno0I2IO10XofX+Cg9cipLSJ/2qFqB yzNKr7pN4hcU/I6+O3g5MDhvfFypPl8Ysy5axcfQWaUizJ3R3qv6CDlMvX5PaK4a SYmwwaXNqwx8MV2nNirqgiBUTinOw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudeghedgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtgfgguffhjgffkfhfvffosehtqh hmtdhhtdejnecuhfhrohhmpeetlhgvgigvhicuofgvlhhnihhkohhvuceorggrmhgvlhhn ihhkohhvsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtthgvrhhnpefhgedtgedvje ejveeuieetffduleeuueefhfejkeevtdfgfefgvedtfeeitddvveenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 22 Mar 2022 10:08:52 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Alexey Melnikov In-Reply-To: Date: Tue, 22 Mar 2022 15:08:50 +0100 Cc: emailcore@ietf.org Message-Id: <06BA6973-002A-42A5-92A5-150BCEF0D958@fastmail.fm> References: To: John C Klensin X-Mailer: iPad Mail (18H107) Archived-At: Subject: Re: [Emailcore] RCPT commands, BCCs, and the "for" clause 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, 22 Mar 2022 14:09:34 -0000 Hi John, (Replying as a WG participant) > On 22 Mar 2022, at 14:22, John C Klensin wrote: >=20 > =EF=BB=BFHi. >=20 > I have been thinking about these (very connected, IMO) issues, > partially in conjunction with some side conversations. My > first conclusion is that they really are one basic issue and > that trying to discuss them separately is just confusing us and > that previous versions of that confusion may have created a hole > in which we are continuing to dig. >=20 > The second conclusion is that RFC 5321 says rather more about > these topics than it should and that we are trying to fix the > issues that text causes by adding more text and risking even > more confusion (in other words, trying to get out of the hole by > digging deeper). With the understanding that none of the ideas > below are new except for the organization and context, my > current hunch is that 5321bis should: >=20 > (i) Remind people that a conforming SMTP server or > (non-submission) client doesn't look at header fields, much less > start performing heuristics on them, and hence does not have a > clue as to which RCPT commands (or their arguments) are > associated with "To:", "Cc:", or "Bcc:" header fields. Section > 7.8 provides a loophole for, e.g., malware resistance measures, > but does not change the principle. >=20 > (ii) Mention that no attempt should be made to include "for" in > a "Received:" header field if there is more than one RCPT > command present, noting that this is forbidden by the syntax > anyway. I think this statement is stronger than currently specified in the draft and= is not something I agree. If a message has 2 RCPT TO recipients A and B (le= t=E2=80=99s assume for simplicity that A and B are end user email addresses,= not mailing lists), I think it is perfectly ok to do either: 1) The same message with Received with no FOR is delivered to both A and B or 2) Recipient A receives a copy of the message with Received with FOR A, whil= e recipient B receives a copy of the message with Received with FOR B. Your statement (ii) prevents choice 2) >=20 > (iii) Clarify the text that mentions that "for" can cause > unintended privacy disclosures and say that, if one is not sure > of the appropriateness of the clause and the information that > should go into it, it is generally better to just omit the > clause. Agreed. >=20 > (iv) Mention as well that _any_ trace field might, under the > wrong set of circumstances, disclose information that someone > might consider sensitive and that, while those fields are often > essential for debugging messages that have run into transport > problems and may even be helpful in distinguishing spoofed or > otherwise problematic messages from more desirable traffic (and > even identifying the source of such bad traffic), complete > protection of anything that might be considered private would > argue for eliminating trace information entirely. Agreed. > Wordsmithing and some decisions about where to use 2119/8174 > language obviously needed, but I'm hoping we can agree on the > above or something like it as general principles. >=20 > We then get rid of all of the hair-splitting about internal > names and addresses on LANs, which addresses should be included > in "for" clauses and which ones avoided, etc. If someone > believes they can persuade the WG that it is worth doing the > case analysis and offering more specific advice in the A/S they > should certainly try (and be ready to write text). But, as far > as 5321bis is concerned, my recommendation is that we > concentrate on the above four points and tear everything else > out. That would, IMO, improve clarity and and shorten 5321bis > by a few pages. I am personally Ok with this direction, but I think I would like to see the n= ew proposed text before fully committing to it. Is it something you can post= to the mailing list before Friday or at least soon-ish? Thank you, Alexey >=20 > --john >=20 > --=20 > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore From nobody Tue Mar 22 07:30:34 2022 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 D91AB3A1514 for ; Tue, 22 Mar 2022 07:30:06 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 IZvaIJXogcsc for ; Tue, 22 Mar 2022 07:30:01 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 DFAD33A0420 for ; Tue, 22 Mar 2022 07:30:00 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id i4so14526907qti.7 for ; Tue, 22 Mar 2022 07:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=7mRGuEMQAyk9A3Ob607J3B16xnoOw/8/1pXqXuPDwxU=; b=Gx/6MUQE8WpOu1p6Pu/PbGqZ2nhIgKLD/z1QaT4pJa2sTd80D9PhUru2zfBmq1ija4 OcdTcngnsfNT5dabGyaCUm1KcwlwdosS2HQVP2Rf6JdPMkAkloll11edDQpJPWOvFtPr +Dqmgsa3Em/YkZDyN3dTvHiLnnQ+p+pNrUj1kU4fWfhG0LbzLvotfVnnnTNDhie5I9t4 HtakrgKp6n6QyfaKxj59XKNQ9mgRq9JkYR+qEt8tsjD9N5lXMvczXu1Nc/EoJjDJINtr KiteVfsOZkNgMk9j2EUIqWbGAcZKuv0MTuBKFoQRclk2L02NoSR9EO9mD/OCckQkaMqq y+qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7mRGuEMQAyk9A3Ob607J3B16xnoOw/8/1pXqXuPDwxU=; b=QTaJ5WjMNKlkLijjzZPybBl+cSvCEbGHAK7FMynMAjRV1hpWye0JmHemNRqRQuN5xZ fzvO0Azh20PK5ZaLBX9O7PYcM94cubavh0xhXiTxI/kkwpybwvPEy83NweulQ2xsonlU RLccqCHU+TcFPBUhPlrWtBHGYm9r1+jX1SXD4U2TONFs8ykH8c/ZebkjLxYhfJcJQA84 aG5K6Eye3JlM77rpR/AOFa5d/pKXiKqUZXy+nEKkkQZYEtbFFPOlun4iSBYAmUxCZd89 eNp6JsZ4l3dcgTC6bUgJbllfcI/klZETXJdEwl0nKWybzZEHw5fGAJo0mnUqDje+zVJb pi6g== X-Gm-Message-State: AOAM533tg4e+R5vYcoWY/gYhAbfqCijZ5ET1TpK8yZ0olyEefyh7gHpa CHjNf2RIs7opEhkeXhPD+wHpxB2EuPSJ9/r/F72C5hXffpoyqA== X-Google-Smtp-Source: ABdhPJxi/Dy6mwvRB5o+36CbppRTZRSsZE1TLpcEkab9HsmJIAVcZrm+ZAVPnlofvEASg895EWbUWbRlMF/As2lUY8M= X-Received: by 2002:a05:622a:1392:b0:2e1:e993:493e with SMTP id o18-20020a05622a139200b002e1e993493emr20343098qtk.619.1647959399201; Tue, 22 Mar 2022 07:29:59 -0700 (PDT) MIME-Version: 1.0 From: Todd Herr Date: Tue, 22 Mar 2022 10:29:43 -0400 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000980fbf05dacf72cb" Archived-At: Subject: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 22 Mar 2022 14:30:14 -0000 --000000000000980fbf05dacf72cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Greetings. I've reviewed the comments generated by my posting rev 3 here at the end of January, and I've incorporated some of them. The one that I didn't incorporate was one that Dave Crocker made to perhaps discuss the concepts of Channel Security versus Object Security in section 5.5, Message-Level Confidentiality. While I thought the suggestion had merit on its face, the fact that the section is just a paragraph talking about how OpenPGP and S/MIME (and similar technologies) are out of scope for the A/S made me decide not to add more text to this section. Current revision follows, there's a place in the agenda to discuss it during Friday's meeting. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D cut here =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D A/S Proposed Text - Confidentiality and Authentication 5. Confidentiality and Authentication with SMTP SMTP is specified without embedded mechanisms for authentication or confidentiality; its traffic is therefore =E2=80=9Cin the clear=E2=80=9D. Y= ears of operational experience have shown that such transmission exposes the message to easy compromise, including wiretapping and spoofing. To mitigate these risks, operation of SMTP has evolved over the years so that it is used with the benefit of Transport Layer Security (TLS - RFC8446) to provide both confidentiality and authentication in the transmission of messages. This section discusses those topics and their most common uses. It is important that the reader understand what is meant by the terms =E2=80=9CAuthentication=E2=80=9D and =E2=80=9CConfidentiality=E2=80=9D, and= for that we will borrow directly from RFC8446. - Authentication is the process of establishing the identity of one or more of the endpoints of a communication channel. TLS only requires authentication of the server side of the communication channel; authentication of the client side is optional. - The term =E2=80=9Cconfidentiality=E2=80=9D describes a state where the d= ata (i.e., the message) is transmitted in a way that it is only visible to the endpoint= s of a communication channel. It is not uncommon for implementers to use the term =E2=80=9Cencryption=E2= =80=9D to mean =E2=80=9Cconfidentiality=E2=80=9D, but this is not quite correct. Rather, e= ncryption using TLS is the current method by which confidentiality is achieved with SMTP, but that does not mean that future methods might not be developed. Note: With typical email use of TLS, authentication only is performed by the sending client of the target receiving server. That is, it serves to validate that the connection has been made to the intended server, but does not validate who initiated it. 5.1 Optional Confidentiality The most common implementation of message confidentiality is what=E2=80=99s= known as =E2=80=9Copportunistic TLS=E2=80=9D, which is frequently referred to as = =E2=80=9Copportunistic encryption=E2=80=9D. With this method, a receiving server announces in its = greeting that it is capable of supporting TLS encryption through the presence of the =E2=80=9CSTARTTLS=E2=80=9D keyword. The sending client then attempts to neg= otiate an encrypted connection, and if successful, transmits the message in encrypted form; if negotiation fails, the client falls back to sending the message in clear text. Opportunistic TLS is confidentiality without authentication, because no effort is made to authenticate the receiving server, and it is optional confidentiality due to the ability to fall back to transmission in the clear if a secure connection cannot be established. That said, most modern implementations of SMTP support this method, especially at the largest mailbox providers, and so the vast majority of email traffic is encrypted during its time transiting from the client to the server. Note: While TLS provides protection while the message is in transit for a single SMTP connection, a message that is encrypted for one SMTP hop might not be encrypted on the next hop and it might not be encrypted within the MTAs relaying the message or at its destination. In fact, storage in plain text should be expected! 5.2 Required Confidentiality, with Receiving Server Authentication Two protocols exist that move message confidentiality from optional to required (with conditions as noted below) - MTA-STS [RFC8461] and DANE for SMTP [RFC7672]. While they differ in their implementation details, receiving servers relying on either protocol are stating that they only accept mail if the transmission can be encrypted with TLS, and a failure to negotiate a secure connection MUST result in the sending client refusing to transmit the message. These two protocols differ from Opportunistic TLS in that they require receiving server authentication and there is no fallback to sending in the clear if negotiation of an encrypted connection fails. Note: Both protocols mentioned in this section rely not only on the receiving server but also the sending client supporting the protocol intended to be used. If the sending client does not implement or understand the protocol requested by the receiving server, the sending client will use Opportunistic TLS or clear-text to transmit the message. 5.3 Message-Level Authentication Protocols exist to allow for authentication of different identities associated with an email message - SPF [RFC7208] and DKIM [RFC6376]. A third protocol, DMARC [RFC7489], relies on SPF and DKIM to allow for validation of the domain in the visible From header, and a fourth, ARC [RFC8617], provides a way for each hop to record results of authentication checks performed at that hop. All of these are outside the scope of this document, as they are outside the scope of SMTP. They deal with validating the authorized usage of one or more domains in an email message, and not with establishing the identity of the receiving server. 5.4 SMTP Authentication SMTP Authentication, which is often abbreviated as SMTP AUTH, is an extension to SMTP. Its name might suggest that it would be within scope for this section of the Applicability Statement, but in fact it=E2=80=99s not. SMTP AUTH defines a method for a client to identify itself to a Message Submission Agent (MSA) when presenting a message for transmission, usually using port 587 rather than the traditional port 25. The most common implementation of SMTP AUTH is for a person to present a username and password to their mailbox provider=E2=80=99s outbound SMTP server when conf= iguring their MUA for sending mail. 5.5 Message-Level Confidentiality Protocols such as S/MIME (RFC8551) and OpenPGP (RFC4880) exist to allow for message confidentiality outside of the operation of SMTP. That is to say, using these protocols results in encryption of the message prior to its being submitted to the SMTP communications channel, and decryption of the message is the responsibility of the message recipient. There are numerous implementations of these protocols, too many to list here. As they operate fully independent of SMTP, they are out of scope for this document. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D cut here =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D --=20 *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000980fbf05dacf72cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings.

I've reviewed the comments g= enerated by my posting rev 3 here at the end of January, and I've incor= porated some of them.

The one that I didn't incorporate was one that= Dave Crocker made to perhaps discuss the concepts of Channel Security vers= us Object Security in section 5.5, Message-Level Confidentiality. While I t= hought the suggestion had merit on its face, the fact that the section is j= ust a paragraph talking about how OpenPGP and S/MIME (and similar technolog= ies) are out of scope for the A/S made me decide not to add more text to th= is section.

Current revision follows, there's a place in the agenda = to discuss it during Friday's=C2=A0meeting.

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D cut here =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

A/S Pr= oposed Text - Confidentiality and Authentication


5. Confidentiality and Authentication with SMT= P

SMTP is specified without embedded mec= hanisms for authentication or confidentiality; its traffic is therefore =E2= =80=9Cin the clear=E2=80=9D. Years of operational experience have shown tha= t such transmission exposes the message to easy compromise, including wiret= apping and spoofing. To mitigate these risks, operation of SMTP has evolved= over the years so that it is used with the benefit of Transport Layer Secu= rity (TLS - RFC8446) to provide both confidentiality and authentication in = the transmission of messages. This section discusses those topics and their= most common uses.

It is important that = the reader understand what is meant by the terms =E2=80=9CAuthentication=E2= =80=9D and =E2=80=9CConfidentiality=E2=80=9D, and for that we will borrow d= irectly from RFC8446.

  • Authentication is the process of establishing the identity o= f one or more of the endpoints of a communication channel. TLS only require= s authentication of the server side of the communication channel; authentic= ation of the client side is optional.

  • The term = =E2=80=9Cconfidentiality=E2=80=9D describes a state where the data (i.e., t= he message) is transmitted in a way that it is only visible to the endpoint= s of a communication channel.

= It is not uncommon for implementers to use the term =E2=80=9Cencryption=E2= =80=9D to mean =E2=80=9Cconfidentiality=E2=80=9D, but this is not quite cor= rect. Rather, encryption using TLS is the current method by which confident= iality is achieved with SMTP, but that does not mean that future methods mi= ght not be developed.

Note: With typical= email use of TLS, authentication only is performed by the sending client o= f the target receiving server. That is, it serves to validate that the conn= ection has been made to the intended server, but does not validate who init= iated it.

5.1 Optional C= onfidentiality

The most common implement= ation of message confidentiality is what=E2=80=99s known as =E2=80=9Copport= unistic TLS=E2=80=9D, which is frequently referred to as =E2=80=9Copportuni= stic encryption=E2=80=9D. With this method, a receiving server announces in= its greeting that it is capable of supporting TLS encryption through the p= resence of the =E2=80=9CSTARTTLS=E2=80=9D keyword. The sending client then = attempts to negotiate an encrypted connection, and if successful, transmits= the message in encrypted form; if negotiation fails, the client falls back= to sending the message in clear text.

O= pportunistic TLS is confidentiality without authentication, because no effo= rt is made to authenticate the receiving server, and it is optional confide= ntiality due to the ability to fall back to transmission in the clear if a = secure connection cannot be established. That said, most modern implementat= ions of SMTP support this method, especially at the largest mailbox provide= rs, and so the vast majority of email traffic is encrypted during its time = transiting from the client to the server.=C2=A0

Note: While TLS provides protection while the message is in transit= for a single SMTP connection, a message that is encrypted for one SMTP hop= might not be encrypted on the next hop and it might not be encrypted withi= n the MTAs relaying the message or at its destination. In fact, storage in = plain text should be expected!

5.2 Required Confidentiality, with Receiving Server Authentication

Two protocols exist that move message con= fidentiality from optional to required (with conditions as noted below) - M= TA-STS [RFC8461] and DANE for SMTP [RFC7672]. While they differ in their im= plementation details, receiving servers relying on either protocol are stat= ing that they only accept mail if the transmission can be encrypted with TL= S, and a failure to negotiate a secure connection MUST result in the sendin= g client refusing to transmit the message.=C2=A0

These two protocols differ from Opportunistic TLS in that they req= uire receiving server authentication and there is no fallback to sending in= the clear if negotiation of an encrypted connection fails.

Note: Both protocols mentioned in this section rely not= only on the receiving server but also the sending client supporting the pr= otocol intended to be used. If the sending client does not implement or und= erstand the protocol requested by the receiving server, the sending client = will use Opportunistic TLS or clear-text to transmit the message.

5.3 Message-Level Authentication<= /span>

Protocols exist to allow for authenticat= ion of different identities associated with an email message - SPF [RFC7208= ] and DKIM [RFC6376]. A third protocol, DMARC [RFC7489], relies on SPF and = DKIM to allow for validation of the domain in the visible From header, and = a fourth, ARC [RFC8617], provides a way for each hop to record results of a= uthentication checks performed at that hop.

All of these are outside the scope of this document, as they are outsi= de the scope of SMTP. They deal with validating the authorized usage of one= or more domains in an email message, and not with establishing the identit= y of the receiving server.

5.4 SMTP Authentication

SMTP Authenti= cation, which is often abbreviated as SMTP AUTH, is an extension to SMTP. I= ts name might suggest that it would be within scope for this section of the= Applicability Statement, but in fact it=E2=80=99s not.

SMTP AUTH defines a method for a client to identify itself = to a Message Submission Agent (MSA) when presenting a message for transmiss= ion, usually using port 587 rather than the traditional port 25. The most c= ommon implementation of SMTP AUTH is for a person to present a username and= password to their mailbox provider=E2=80=99s outbound SMTP server when con= figuring their MUA for sending mail.

5.5 Message-Level Confidentiality

Protocols such as S/MIME (RFC8551) and OpenPGP (RFC4880) exist to al= low for message confidentiality outside of the operation of SMTP. That is t= o say, using these protocols results in encryption of the message prior to = its being submitted to the SMTP communications channel, and decryption of t= he message is the responsibility of the message recipient. There are numero= us implementations of these protocols, too many to list here. As they opera= te fully independent of SMTP, they are out of scope for this document.

= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D cut here =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D


--

Todd Herr | Technical Director, S= tandards and Ecosystem
m: 703.220.4153

This email and al= l data transmitted with it contains confidential and/or proprietary informa= tion intended solely for the use of individual(s) authorized to receive it.= If you are not an intended and authorized recipient you are hereby notifie= d of any use, disclosure, copying or distribution of the information includ= ed in this transmission is prohibited and may be unlawful. Please immediate= ly notify the sender by replying to this email and then delete it from your= system.

--000000000000980fbf05dacf72cb-- From nobody Tue Mar 22 09:39:18 2022 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 9348E3A0100 for ; Tue, 22 Mar 2022 09:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.861 X-Spam-Level: X-Spam-Status: No, score=-1.861 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, T_SCC_BODY_TEXT_LINE=-0.01, 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=aQN87l2k; dkim=pass (2048-bit key) header.d=taugh.com header.b=g/RPFjZG 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 pMIe8mJNkRt4 for ; Tue, 22 Mar 2022 09:38:57 -0700 (PDT) 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 A969A3A00D3 for ; Tue, 22 Mar 2022 09:38:42 -0700 (PDT) Received: (qmail 78384 invoked from network); 22 Mar 2022 16:38:40 -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=1322e.6239fb90.k2203; bh=SMK3regkweQeOy4agOcKdkl5w6tAPdrcg8LwEXjhog4=; b=aQN87l2kOV+IG05Jap84TCCS5mhGKK+Aewhts3F06LqrUsPUZCAfyBD42k+l/0qIOnaCi1j0bqPqTn97umRF2wSHC/fI4ayhdkwKndFRPfTsngsnCdko3f611rYhSZV3UWyiy7Xv0PiVnduWWfFDBFnPyfNCkosQm0cTh1FERfhNpJOEXOrywl/kw8agvAzxUDpi9bx6u7gTQ2Mjynue720L5PzAdCVRi3QWu8w9iXqpawid3owW4qC/sf7aih5yitqnZIwfxLM76BI4bLaPNVE/Za4kEcF7DC49zOzNaihB0QUJt/83cxlr2hqfRNs10m9awR1ApwIwV9nEFA5fIA== 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=1322e.6239fb90.k2203; bh=SMK3regkweQeOy4agOcKdkl5w6tAPdrcg8LwEXjhog4=; b=g/RPFjZGXe5X9bGCyZ22T9jvIp53LJmeS/W2tPKPofYSg/ThpBIbbuvkqTIEr7+fk5WRGHrEEnYgSGAHdgLMdNtzFKRvXlt04llK9X+avMtJ8uOY5FcVRbrmpsbMXpvnphLm51lFMtJedEJkg5sOaLfDbi4R+xVaefj2Hkg2i+Qq7Z5vxYmuoklgGwkuLENoxf6PODrxeShwJohDm6iEW9LRv3IsVVl9i44CngnO8Vow1n9CuNrPq89STpM8uYVORO3XSCnB2VPkjsSZTSP61EwPSgItRACXhtv2ofMit7G0C00DosBdjEQQuG6g+FQqFv367EP+6zLsPNrz/TZVzA== 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; 22 Mar 2022 16:38:40 -0000 Received: by ary.qy (Postfix, from userid 501) id 20E54398FD7E; Tue, 22 Mar 2022 12:38:38 -0400 (EDT) Date: 22 Mar 2022 12:38:38 -0400 Message-Id: <20220322163839.20E54398FD7E@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: john-ietf@jck.com In-Reply-To: <104C6A455630C1570E89BD01@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] Relaxing the IANA registration requirement for SMTP Extensions in rfc5321bis 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, 22 Mar 2022 16:39:05 -0000 It appears that John C Klensin said: >keyword accidentally being used for different things, I'm in >favor of relaxing the requirements somewhat from Standards Track >or IESG-approved Experimental. My inclination is somewhere between specification required and expert review, with the understanding that the point of the review is just to see that the specification is at least superficially plausible. We have our share of unused extensions (MTRK, CONNEG, ...) and I'm not worried that there is a flood of worse ones waiting. >Suggestion: RFC 5321 Section 8, IANA Considerations, describes >the three registries but does not actually specify what goes in >them, nor does it follow what is now the normal practice of >providing a specific registration template or list of fields and >descriptions of possible values [1]. For the SMTP Extensions >Registry, we should consider either specifying a template or a >list of things required in an application for a Service >Extension. That would be a good idea. Yesterday Alexey and I realized that 5321 says VRFY is a service extension that somehow never made it into the registry. R's, John From nobody Tue Mar 22 10:28:12 2022 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 27AD43A07CF for ; Tue, 22 Mar 2022 10:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=q0p391TE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ge3fuSPz 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 aMOHbQSZNTo8 for ; Tue, 22 Mar 2022 10:28:04 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719653A07AA for ; Tue, 22 Mar 2022 10:28:04 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E9C565C00D4; Tue, 22 Mar 2022 13:27:59 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 22 Mar 2022 13:27:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; bh=UIzkE6Bvyzssqs eZqBFqFS9py01bN44tVPZcBnOMRh4=; b=q0p391TERw/UgKTnW4ze5HG2qvJR2k MCvUN2N/36pIglxVg6YRvgrZlnUNYgHgV1p9PlcEA7HM6yrO/zx9jYWSxbKZX515 r2StSTeIPKQmN2r9wLWOW4xmYwOUo65/IXrvN13oghD0RnpG/XMtWpx0lg/74eGI H1uvuFR1jOk07qNVaK/1RGB/aAkFzXtqL45gTYKu3p5lABbjazFib86psPeKP8Vg 6K0GMVUC0bqUYNaPI3xWQHCzxOVPcdf0GPKu7iffFAMq/NR0MlhYgvmTDPsrEJQY 3E8hMci3+H7u8c4RPXfn2XO1XJuCz3XVBF9rBqu4Dm51UZ5IR0MmtDXg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=UIzkE6BvyzssqseZqBFqFS9py01bN44tVPZcBnOMR h4=; b=Ge3fuSPzlbc7u8M2nqjMxlSXKCCszFrT7O/lUSuzr3T12XoTscMoLxOBQ zCThsvkbjNd2lu2Emkk60LCbeoV/BsmK85n0xVTvQb5su27ryKHlvjGyliSsz4Zq 3I/Ps8EmvIqnjdBYdm4SQOh90FJ+RdZ1j8mXp4hE1+S6LNlgjgEEmJwIU7mAQJ1T eZDouFzew8jlw4NfD3IGQzWCLO18sde52CyMbLT5t1UsJH7DckBDkY+hgeSgnEVU sFVaqS2tcxAE189guN6em0X5a9k9BGBULdORZ02Q6uq77Q5EIOolbaJS3VRLd1KA ntqOvi41su2QdTTFIc6Kp1xxTnW8A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudeghedgleekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtgfgguffhjgffkfhfvffosegrje hmrehhtdejnecuhfhrohhmpeetlhgvgigvhicuofgvlhhnihhkohhvuceorggrmhgvlhhn ihhkohhvsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtthgvrhhnpefgtedtgffgfe fhjeeiffdvveekfffgteetheefhfejveegjeevhfduheelvdefleenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 22 Mar 2022 13:27:59 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-1943BF25-B148-49E6-8473-B1DACB3B6215 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Alexey Melnikov In-Reply-To: Date: Tue, 22 Mar 2022 18:27:57 +0100 Cc: emailcore@ietf.org Message-Id: <4F1E3A68-12D1-4351-840F-3414DDC735DD@fastmail.fm> References: To: Todd Herr X-Mailer: iPad Mail (18H107) Archived-At: Subject: Re: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 22 Mar 2022 17:28:09 -0000 --Apple-Mail-1943BF25-B148-49E6-8473-B1DACB3B6215 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Todd, (With my WG participant hat on) > On 22 Mar 2022, at 15:31, Todd Herr wrote: >=20 > =EF=BB=BF > Greetings. >=20 > I've reviewed the comments generated by my posting rev 3 here at the end o= f January, and I've incorporated some of them. >=20 > The one that I didn't incorporate was one that Dave Crocker made to perhap= s discuss the concepts of Channel Security versus Object Security in section= 5.5, Message-Level Confidentiality. While I thought the suggestion had meri= t on its face, the fact that the section is just a paragraph talking about h= ow OpenPGP and S/MIME (and similar technologies) are out of scope for the A/= S made me decide not to add more text to this section. >=20 > Current revision follows, there's a place in the agenda to discuss it duri= ng Friday's meeting. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D cut here =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Thank you for this text. Minor comments below: > A/S Proposed Text - Confidentiality and Authentication >=20 > 5. Confidentiality and Authentication with SMTP >=20 > SMTP is specified without embedded mechanisms for authentication or confid= entiality; its traffic is therefore =E2=80=9Cin the clear=E2=80=9D. Years of= operational experience have shown that such transmission exposes the messag= e to easy compromise, including wiretapping and spoofing. To mitigate these r= isks, operation of SMTP has evolved over the years so that it is used with t= he benefit of Transport Layer Security (TLS - RFC8446) to provide both confi= dentiality and authentication in the transmission of messages. This section d= iscusses those topics and their most common uses. >=20 > It is important that the reader understand what is meant by the terms =E2=80= =9CAuthentication=E2=80=9D and =E2=80=9CConfidentiality=E2=80=9D, and for th= at we will borrow directly from RFC8446. >=20 > Authentication is the process of establishing the identity of one or more o= f the endpoints of a communication channel. TLS only requires authentication= of the server side of the communication channel; authentication of the clie= nt side is optional. > The term =E2=80=9Cconfidentiality=E2=80=9D describes a state where the dat= a (i.e., the message) is transmitted in a way that it is only visible to the= endpoints of a communication channel. >=20 > It is not uncommon for implementers to use the term =E2=80=9Cencryption=E2= =80=9D to mean =E2=80=9Cconfidentiality=E2=80=9D, but this is not quite corr= ect. Rather, encryption using TLS is the current method by which confidentia= lity is achieved with SMTP, but that does not mean that future methods might= not be developed. >=20 > Note: With typical email use of TLS, authentication only is performed by t= he sending client of the target receiving server. That is, it serves to vali= date that the connection has been made to the intended server, but does not v= alidate who initiated it. >=20 > 5.1 Optional Confidentiality >=20 > The most common implementation of message confidentiality is what=E2=80=99= s known as =E2=80=9Copportunistic TLS=E2=80=9D, which is frequently referred= to as =E2=80=9Copportunistic encryption=E2=80=9D. With this method, a recei= ving server announces in its greeting that it is capable of supporting TLS e= ncryption through the presence of the =E2=80=9CSTARTTLS=E2=80=9D keyword. Th= e sending client then attempts to negotiate an encrypted connection, and if s= uccessful, transmits the message in encrypted form; if negotiation fails, th= e client falls back to sending the message in clear text. >=20 > Opportunistic TLS is confidentiality without authentication, because no ef= fort is made to authenticate the receiving server, and it is optional confid= entiality due to the ability to fall back to transmission in the clear if a s= ecure connection cannot be established. That said, most modern implementatio= ns of SMTP support this method, especially at the largest mailbox providers,= and so the vast majority of email traffic is encrypted during its time tran= siting from the client to the server.=20 >=20 > Note: While TLS provides protection while the message is in transit for a s= ingle SMTP connection, a message that is encrypted for one SMTP hop might no= t be encrypted on the next hop and it might not be encrypted within the MTAs= relaying the message or at its destination. In fact, storage in plain text s= hould be expected! >=20 I think you should move the above note to Section 5, as it applies equally t= o opportunistic and mandated confidentiality. > 5.2 Required Confidentiality, with Receiving Server Authentication >=20 > Two protocols exist that move message confidentiality from optional to req= uired (with conditions as noted below) - MTA-STS [RFC8461] and DANE for SMTP= [RFC7672]. While they differ in their implementation details, receiving ser= vers relying on either protocol are stating that they only accept mail if th= e transmission can be encrypted with TLS, and a failure to negotiate a secur= e connection MUST result in the sending client refusing to transmit the mess= age.=20 >=20 > These two protocols differ from Opportunistic TLS in that they require rec= eiving server authentication and there is no fallback to sending in the clea= r if negotiation of an encrypted connection fails. >=20 > Note: Both protocols mentioned in this section rely not only on the receiv= ing server but also the sending client supporting the protocol intended to b= e used. If the sending client does not implement or understand the protocol r= equested by the receiving server, the sending client will use Opportunistic T= LS or clear-text to transmit the message. >=20 > 5.3 Message-Level Authentication >=20 > Protocols exist to allow for authentication of different identities associ= ated with an email message - SPF [RFC7208] and DKIM [RFC6376]. A third proto= col, DMARC [RFC7489], relies on SPF and DKIM to allow for validation of the d= omain in the visible =46rom header, and a fourth, ARC [RFC8617], provides a w= ay for each hop to record results of authentication checks performed at that= hop. >=20 > All of these are outside the scope of this document, as they are outside t= he scope of SMTP. They deal with validating the authorized usage of one or m= ore domains in an email message, and not with establishing the identity of t= he receiving server. >=20 > 5.4 SMTP Authentication >=20 > SMTP Authentication, which is often abbreviated as SMTP AUTH, is an extens= ion to SMTP. Its name might suggest that it would be within scope for this s= ection of the Applicability Statement, but in fact it=E2=80=99s not. >=20 > SMTP AUTH defines a method for a client to identify itself to a Message Su= bmission Agent (MSA)=20 >=20 While this is the most common use, SMTP AUTH is actually not limited to MSAs= . I would reword the above to say that why SMTP AUTH is defined for both MSAs a= nd MTAs, it is most commonly used with MSAs, and thus it is out of scope for= A/S. > when presenting a message for transmission, usually using port 587 rather t= han the traditional port 25.=20 >=20 You need a reference here. > The most common implementation of SMTP AUTH is for a person to present a u= sername and password to their mailbox provider=E2=80=99s outbound SMTP serve= r when configuring their MUA for sending mail. >=20 > 5.5 Message-Level Confidentiality >=20 > Protocols such as S/MIME (RFC8551) and OpenPGP (RFC4880) exist to allow fo= r message confidentiality=20 >=20 =E2=80=9Cand integrity=E2=80=9D > outside of the operation of SMTP. That is to say, using these protocols re= sults in encryption of the message prior to its being submitted to the SMTP c= ommunications channel, and decryption of the message is the responsibility o= f the message recipient. There are numerous implementations of these protoco= ls, too many to list here. As they operate fully independent of SMTP, they a= re out of scope for this document. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D cut here =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >=20 >=20 > --=20 > Todd Herr | Technical Director, Standards and Ecosystem > e: todd.herr@valimail.com=20 > m: 703.220.4153 >=20 > This email and all data transmitted with it contains confidential and/or p= roprietary information intended solely for the use of individual(s) authoriz= ed to receive it. If you are not an intended and authorized recipient you ar= e hereby notified of any use, disclosure, copying or distribution of the inf= ormation included in this transmission is prohibited and may be unlawful. Pl= ease immediately notify the sender by replying to this email and then delete= it from your system. > --=20 > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore --Apple-Mail-1943BF25-B148-49E6-8473-B1DACB3B6215 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Todd,
(With my WG participant hat on)

On 22 Mar 2022, at 15:31, Todd Herr <= todd.herr=3D40valimail.com@dmarc.ietf.org> wrote:

=EF=BB=BF
Greetings.<= br clear=3D"all">

I've reviewed the comments generated by my posting rev 3 h= ere at the end of January, and I've incorporated some of them.

The one that I= didn't incorporate was one that Dave Crocker made to perhaps discuss the co= ncepts of Channel Security versus Object Security in section 5.5, Message-Le= vel Confidentiality. While I thought the suggestion had merit on its face, t= he fact that the section is just a paragraph talking about how OpenPGP and S= /MIME (and similar technologies) are out of scope for the A/S made me decide= not to add more text to this section.

Current revision follows, there's a p= lace in the agenda to discuss it during Friday's meeting.

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D cut here =3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
<= /div>

Thank you for this text. Minor commen= ts below:

A/S Pr= oposed Text - Confidentiality and Authentication


5. Confidentiality and Authentication with SMTP

SMTP is specified without embedded mechanisms for= authentication or confidentiality; its traffic is therefore =E2=80=9Cin the= clear=E2=80=9D. Years of operational experience have shown that such transm= ission exposes the message to easy compromise, including wiretapping and spo= ofing. To mitigate these risks, operation of SMTP has evolved over the years= so that it is used with the benefit of Transport Layer Security (TLS - RFC8= 446) to provide both confidentiality and authentication in the transmission o= f messages. This section discusses those topics and their most common uses.<= /span>

It is important that the reader understand w= hat is meant by the terms =E2=80=9CAuthentication=E2=80=9D and =E2=80=9CConf= identiality=E2=80=9D, and for that we will borrow directly from RFC8446.

  • Authentication is t= he process of establishing the identity of one or more of the endpoints of a= communication channel. TLS only requires authentication of the server side o= f the communication channel; authentication of the client side is optional.<= /span>

  • The term =E2=80=9Cconfidentiality=E2=80=9D describes a s= tate where the data (i.e., the message) is transmitted in a way that it is o= nly visible to the endpoints of a communication channel.

    • It is not uncommon for implementers to use the term =E2= =80=9Cencryption=E2=80=9D to mean =E2=80=9Cconfidentiality=E2=80=9D, but thi= s is not quite correct. Rather, encryption using TLS is the current method b= y which confidentiality is achieved with SMTP, but that does not mean that f= uture methods might not be developed.

    Note: W= ith typical email use of TLS, authentication only is performed by the sendin= g client of the target receiving server. That is, it serves to validate that= the connection has been made to the intended server, but does not validate w= ho initiated it.

    5.1 Optiona= l Confidentiality

    The most common implementa= tion of message confidentiality is what=E2=80=99s known as =E2=80=9Copportun= istic TLS=E2=80=9D, which is frequently referred to as =E2=80=9Copportunisti= c encryption=E2=80=9D. With this method, a receiving server announces in its= greeting that it is capable of supporting TLS encryption through the presen= ce of the =E2=80=9CSTARTTLS=E2=80=9D keyword. The sending client then attemp= ts to negotiate an encrypted connection, and if successful, transmits the me= ssage in encrypted form; if negotiation fails, the client falls back to send= ing the message in clear text.

    Opportunistic= TLS is confidentiality without authentication, because no effort is made to= authenticate the receiving server, and it is optional confidentiality due t= o the ability to fall back to transmission in the clear if a secure connecti= on cannot be established. That said, most modern implementations of SMTP sup= port this method, especially at the largest mailbox providers, and so the va= st majority of email traffic is encrypted during its time transiting from th= e client to the server. 

    Note: While TL= S provides protection while the message is in transit for a single SMTP conn= ection, a message that is encrypted for one SMTP hop might not be encrypted o= n the next hop and it might not be encrypted within the MTAs relaying the me= ssage or at its destination. In fact, storage in plain text should be expect= ed!

I think you should m= ove the above note to Section 5, as it applies equally to opportunistic and m= andated confidentiality.

5.2 Re= quired Confidentiality, with Receiving Server Authentication

Two protocols exist that move message confidentiality from o= ptional to required (with conditions as noted below) - MTA-STS [RFC8461] and= DANE for SMTP [RFC7672]. While they differ in their implementation details,= receiving servers relying on either protocol are stating that they only acc= ept mail if the transmission can be encrypted with TLS, and a failure to neg= otiate a secure connection MUST result in the sending client refusing to tra= nsmit the message. 

These two protocols= differ from Opportunistic TLS in that they require receiving server authent= ication and there is no fallback to sending in the clear if negotiation of a= n encrypted connection fails.

Note: Both pro= tocols mentioned in this section rely not only on the receiving server but a= lso the sending client supporting the protocol intended to be used. If the s= ending client does not implement or understand the protocol requested by the= receiving server, the sending client will use Opportunistic TLS or clear-te= xt to transmit the message.

= 5.3 Message-Level Authentication

Protocols e= xist to allow for authentication of different identities associated with an e= mail message - SPF [RFC7208] and DKIM [RFC6376]. A third protocol, DMARC [RFC= 7489], relies on SPF and DKIM to allow for validation of the domain in the v= isible =46rom header, and a fourth, ARC [RFC8617], provides a way for each h= op to record results of authentication checks performed at that hop.<= /p>

All of these are outside the scope of this document= , as they are outside the scope of SMTP. They deal with validating the autho= rized usage of one or more domains in an email message, and not with establi= shing the identity of the receiving server.

5.4 SMTP Authentication

SMTP A= uthentication, which is often abbreviated as SMTP AUTH, is an extension to S= MTP. Its name might suggest that it would be within scope for this section o= f the Applicability Statement, but in fact it=E2=80=99s not.

SMTP AUTH defines a method for a client to identify itself t= o a Message Submission Agent (MSA)

While this is the most common use, SMTP AUTH is actually not limited= to MSAs.

I would reword the above to say that why SMTP A= UTH is defined for both MSAs and MTAs, it is most commonly used with MSAs, a= nd thus it is out of scope for A/S.

=

when presenting a= message for transmission, usually using port 587 rather than the traditiona= l port 25.

You need a r= eference here.

The most common implementation of SMTP AUTH is= for a person to present a username and password to their mailbox provider=E2= =80=99s outbound SMTP server when configuring their MUA for sending mail.

5.5 Message-Level Confidential= ity

Protocols such as S/MIME (RFC8551) and O= penPGP (RFC4880) exist to allow for message confidentiality

=E2=80=9Cand integrity=E2=80=9D

outside of the operation of SMTP. That is to say, using these protocols re= sults in encryption of the message prior to its being submitted to the SMTP c= ommunications channel, and decryption of the message is the responsibility o= f the message recipient. There are numerous implementations of these protoco= ls, too many to list here. As they operate fully independent of SMTP, they a= re out of scope for this document.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D cut here =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


--

=
Todd Herr = | Technical Director, Standards and Ecosystem
= e: todd.herr@valimail.com
m: 703.220.4153

This email and all data transmitted with it contains= confidential and/or proprietary information intended solely for the use of i= ndividual(s) authorized to receive it. If you are not an intended and author= ized recipient you are hereby notified of any use, disclosure, copying or di= stribution of the information included in this transmission is prohibited an= d may be unlawful. Please immediately notify the sender by replying to this e= mail and then delete it from your system.

--
Emailcore mailing list
Emailcore@i= etf.org
https://www.ietf.org/mailman/listinfo/emailcore
= --Apple-Mail-1943BF25-B148-49E6-8473-B1DACB3B6215-- From nobody Tue Mar 22 10:29:17 2022 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 E4BD13A07CF for ; Tue, 22 Mar 2022 10:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 hrfZpJoFt_9E for ; Tue, 22 Mar 2022 10:29:11 -0700 (PDT) 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 2A7683A07AA for ; Tue, 22 Mar 2022 10:29:09 -0700 (PDT) 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 5A3946C2455 for ; Tue, 22 Mar 2022 17:20:21 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (unknown [127.0.0.6]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 5A6C96C239C for ; Tue, 22 Mar 2022 17:20:20 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1647969620; a=rsa-sha256; cv=none; b=x/+tLXDHiJR7OYSgfHMcrdxKUBW642UvGQfYG2HGfrZKlfolaaP0rqQDXlmvGoNGXPrv3r Qe36QNOFi0aERYY6uDHZgXq2zq9ABLW3UOlyH/TVGFOSzIXEFlqvjIQA6EpxCsC55JZVAl 6tjwI4lzO9ZaOUCz9l2WIwPkr1IcPBPiyKUuv4DoSyuWS/OUjNdbSyWNEaoNDpTc8uOl+g 48XcZhnc4bESQR2r9H7sEUEh7D4ESSEbp/AK3dSVHlY6k82rfT3/XdbLADFsvorQvQZh64 IIQF+bcqZB48S+0np/3WFx/iNAV9J0I1JH/QrlOgUJJQhHTnsOE7AiUsxMArLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1647969620; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:dkim-signature; bh=CCU0NdwhlU/yp3ZOgVxtQWk+fyXQo/+QeyP4HpV/Jdk=; b=jWr/jTmM8oEjr3K0ZPeUrArm7LT4AEw5ljtqKDmL9bxHqXtcuQCB/FO/AKTiAMfA4f8Ha4 cD3XX+LvhB0eraDYTAeQ9yi4yrXobXcyXuKLTJ1RSyTHDcGKVhwrj3iggCcHWR1KoIKR9V bPQzW2Z76KDTcwYARDHNwCRCLEfW2yXBUQxYvk78K+gMQD84e+2LmD1PFCYIBBQhbe6GL5 H7NqDeWy6EFllGUYteZO+Nyoa6WoijHt9q3MrlnRJXWGjuKS/i0l6M0zjtuDgIYmJu1d3j 3LMTgSBYx5YORwMWULDSGGMGvUwb0AfgO41zerKzX7Qmx3azvrfO10g3sSmW1g== ARC-Authentication-Results: i=1; rspamd-74bfb75fc6-bjjqc; auth=pass smtp.auth=hostingeremail smtp.mailfrom=dhc@dcrocker.net X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (gcp-us-central1-a-smtpout2.hostinger.io [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.124.238.100 (trex/6.5.3); Tue, 22 Mar 2022 17:20:21 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Befitting-Wiry: 476624f66d478971_1647969620876_3508416588 X-MC-Loop-Signature: 1647969620876:3392714523 X-MC-Ingress-Time: 1647969620876 Received: from [192.168.0.112] (c-73-170-122-71.hsd1.ca.comcast.net [73.170.122.71]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 4KNJCR3ZsBz7YpHS for ; Tue, 22 Mar 2022 17:20:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1647969619; bh=zNaqJ5chkIAxXitYKGescRkJIQ6shJe6DY8sqOZuqlM=; h=Date:From:Reply-To:Subject:To; b=EhqFkwMa4SwZqs2vuQx9xWyAJZ1U9GnvBm+xWe4sNlD6PbyxzXmvqFyklgtu5EYv7 cdABBTTnSB/v3Fkg85qmZoOHZTYubWqGQUuCJmtafsW/xEXrPfFoJTy6Fnivj31ZGT bcFN2NWCk4puucEfanRo8DrGcrygcZBqbvKEdJpFyFBkC0cyPw7IqsK3LJxM4dTbm9 FVzH19uQoiaiMnBjICKifEx5q0slRVmu4M8qxpE8WCXvMYMkm4XNgjFRfOMw9qGYJp l/+lWNjda+c3UoPUrKRvpML+MhAiGrg33NYBZ1YexWmL/R6WKaP/kCj3xD9e8l0WCR UqKsfG+dQZrZQ== Content-Type: multipart/alternative; boundary="------------1rNmSE0V0XuiKiPDxz8BA1qh" Message-ID: <3c3986a6-e90b-9319-b62b-c532f88a8cae@dcrocker.net> Date: Tue, 22 Mar 2022 10:20:17 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking To: EmailCore WG Archived-At: Subject: [Emailcore] Emailcore wg charter 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, 22 Mar 2022 17:29:16 -0000 This is a multi-part message in MIME format. --------------1rNmSE0V0XuiKiPDxz8BA1qh Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit G'day, Seeing an email citing Ticket #54, as well as a new posting for rfc5321bis, I wonder whether all of the work being done on the revisions is within the working group's charter? The charter has language typical for revision efforts needing tight focus, seeking to limit changes and potential disruption for the installed base.  Specifically... Emailcore Charter: https://datatracker.ietf.org/doc/charter-ietf-emailcore/ This working group will conduct a limited review and revision to the base email specifications ... The limited review is restricted to corrections and clarifications only, with a strong emphasis on keeping these minimal and avoiding broader changes to terminology or document organization. ... However, no new protocol extensions or amendments will be considered 54 ticket items seems like quite a few, given the constraints.  As for changes to the SMTP specification, consider the diff between RFC 5321 and latest rfc5321bis draft: https://www.ietf.org/rfcdiff?url1=rfc5321&url2=draft-ietf-emailcore-rfc5321bis-10 A few questions to consider: * Are enough wg participants able and willing to justify every change, in detail, as conforming to the charter? Simply put, why were they essential, within the charter constraints? * Given the number of changes, what is the basis for believing that an average reader will be able to apply the revised specification, while ensuring continued interoperability, especially given how creative readers can be with new text? The concern is not whether any given change is broadly reasonable or a generally good idea, but whether it is essential to the immediate working group goal and within its charter? One could reasonably expect significant evidence of a problem that needs fixing, for each change. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------1rNmSE0V0XuiKiPDxz8BA1qh Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

G'day,

Seeing an email citing Ticket #54, as well as a new posting for rfc5321bis, I wonder whether all of the work being done on the revisions is within the working group's charter? 

The charter has language typical for revision efforts needing tight focus, seeking to limit changes and potential disruption for the installed base.  Specifically...

Emailcore Charter:

https://datatracker.ietf.org/doc/charter-ietf-emailcore/

This working group will conduct a limited review and revision to the base email specifications
... 
The limited review is restricted to corrections and clarifications only, with a strong emphasis on keeping
these minimal and avoiding broader changes to terminology or document organization.
...
However, no new protocol extensions or amendments will be considered
54 ticket items seems like quite a few, given the constraints.  As for changes to the SMTP specification, consider the diff between RFC 5321 and latest rfc5321bis draft:

https://www.ietf.org/rfcdiff?url1=rfc5321&url2=draft-ietf-emailcore-rfc5321bis-10

A few questions to consider:

  • Are enough wg participants able and willing to justify every change, in detail, as conforming to the charter? Simply put, why were they essential, within the charter constraints?
  • Given the number of changes, what is the basis for believing that an average reader will be able to apply the revised specification, while ensuring continued interoperability, especially given how creative readers can be with new text?

The concern is not whether any given change is broadly reasonable or a generally good idea, but whether it is essential to the immediate working group goal and within its charter? 

One could reasonably expect significant evidence of a problem that needs fixing, for each change.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------1rNmSE0V0XuiKiPDxz8BA1qh-- From nobody Tue Mar 22 11:07:41 2022 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 899B53A0E79 for ; Tue, 22 Mar 2022 11:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 G2PnFfGuvZ4R for ; Tue, 22 Mar 2022 11:07:28 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 690073A0E16 for ; Tue, 22 Mar 2022 11:07:28 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id v2so15110932qtc.5 for ; Tue, 22 Mar 2022 11:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=w7sT3/FUFtzcRNbSZLqb5CFOYGV5fxVul08QD6XnAaU=; b=bBE1s66LeRxZuFM1eMgFNXZkUseUjTIiWGyf7kb71GPcbgHupBP8abaaQ2bW0eswTT 9bx643zGm6pr6eihYk8AW+/thBq41LhAPpWMnmBGpIAIL3k8hO9SgIPjd2Sm3RSVq6Z2 dPItDunfTiF21qEC7ACQy6oTWSd2J0oTbXI+mLUrtzdffsA5QiaQLJcaERTjhRoAUaWW gEteys33JZ6CLcmiDTeNE2o2c7xEiO53pCZuWB/chUJSGPA6oc07XWHiN7ijaj6poZDS 8bsBJ/Ia+B23KUdtGzd1goyBd4AvQfyg3JeujWP8ZFG9nwbQDX83+G+lPARhU1D6Zn4s sQyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=w7sT3/FUFtzcRNbSZLqb5CFOYGV5fxVul08QD6XnAaU=; b=ZHYnXkjoIXf89EsatnQPMGKFc9jKcec+wkNVWjCRYzs7gFP+Q/RskQxo0idQ0Ngr4D KQ/+lD+9TCSs95gxOXHeWLztX6PCuOFf5OIK9vPJCzP4T/sIzeDawJf1WAM9CIeZ41Ef 07kt64ocK1+pNLT/HnkiQJCKbQccVoUj634ER6qiERxmJCj8U1/5Pba2QOU8oQS6YVM1 oOxVef/3cBjnirXogO97wHkE7ldD3xl0gVy3i2BPJEYZ/HmavEL3GNtAufAF1DjksNqP EOXzrZf369clRRNDffecR7/wRpDkXdYLxxM/9xjbj+LhwcEEtBYKCYhuRS4TdtnkRYqH cJYA== X-Gm-Message-State: AOAM533NTwGECLzKZDLHGXn/eeCoTxLC9SAMclvxQzOr+PeyQNrxES0/ 5xdeTwmn57+TKRMjuosRI0/YpzCi80Dg2GmC4HLQo+ziKc4= X-Google-Smtp-Source: ABdhPJwQtZWEmpo/DEGZ9aLWxoyg9ZKK9SQiB1HYNZTbpV9k9y2kisdA7r5vepj+ts5I8zCtWvsMiSXCbNrpIX5QUG8= X-Received: by 2002:a05:622a:82:b0:2e1:d61d:81ec with SMTP id o2-20020a05622a008200b002e1d61d81ecmr21385029qtw.674.1647972446727; Tue, 22 Mar 2022 11:07:26 -0700 (PDT) MIME-Version: 1.0 References: <3c3986a6-e90b-9319-b62b-c532f88a8cae@dcrocker.net> In-Reply-To: <3c3986a6-e90b-9319-b62b-c532f88a8cae@dcrocker.net> From: Todd Herr Date: Tue, 22 Mar 2022 14:07:10 -0400 Message-ID: To: EmailCore WG Content-Type: multipart/alternative; boundary="00000000000049879505dad27cbb" Archived-At: Subject: Re: [Emailcore] Emailcore wg charter 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, 22 Mar 2022 18:07:39 -0000 --00000000000049879505dad27cbb Content-Type: text/plain; charset="UTF-8" On Tue, Mar 22, 2022 at 1:29 PM Dave Crocker wrote: > G'day, > > Seeing an email citing Ticket #54, as well as a new posting for > rfc5321bis, I wonder whether all of the work being done on the revisions is > within the working group's charter? > > The charter has language typical for revision efforts needing tight focus, > seeking to limit changes and potential disruption for the installed base. > Specifically... > > Emailcore Charter: > > https://datatracker.ietf.org/doc/charter-ietf-emailcore/ > > This working group will conduct a limited review and revision to the base email specifications > ... > The limited review is restricted to corrections and clarifications only, with a strong emphasis on keeping > these minimal and avoiding broader changes to terminology or document organization. > ... > However, no new protocol extensions or amendments will be considered > > > 54 ticket items seems like quite a few, given the constraints. > Hatless... I've understood the text I've been proposing for ticket 54 to be intended for the Applicability Statement, not for 5321bis itself. Does that change your opinion of the impact of this ticket on our adherence to the charter? -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --00000000000049879505dad27cbb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar 22, 2022 at 1:29 PM Dave Crocker <dhc@dcrocker.net> wrote:
=20 =20 =20

G'day,

Seeing an email citing Ticket #54, as well as a new posting for rfc5321bis, I wonder whether all of the work being done on the revisions is within the working group's charter?=C2=A0

The charter has language typical for revision efforts needing tight focus, seeking to limit changes and potential disruption for the installed base.=C2=A0 Specifically...

Emailcore Charter:

https://datatracker.ietf.org/doc/charter-ietf-emailcor= e/

This working group will conduct a limited review and revision to=
 the base email specifications
...=20
The limited review is restricted to corrections and clarifications only, wi=
th a strong emphasis on keeping
these minimal and avoiding broader changes to terminology or document organ=
ization.
...
However, no new protocol extensions or amendments will be considered
54 ticket items seems like quite a few, given the constraints.=C2=A0

Hatless...

I've understood the text I'v= e been proposing for ticket 54 to be intended for the Applicability Stateme= nt, not for 5321bis itself.

Does that change your opinion of the impact = of this ticket on our adherence to the charter?
--

Todd Herr | Technical Director, Sta= ndards and Ecosystem
<= span>m: 703.220.4153

This email and = all data transmitted with it contains confidential and/or proprietary infor= mation intended solely for the use of individual(s) authorized to receive i= t. If you are not an intended and authorized recipient you are hereby notif= ied of any use, disclosure, copying or distribution of the information incl= uded in this transmission is prohibited and may be unlawful. Please immedia= tely notify the sender by replying to this email and then delete it from yo= ur system.

--00000000000049879505dad27cbb-- From nobody Tue Mar 22 11:34:36 2022 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 7AE813A103E for ; Tue, 22 Mar 2022 11:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 qSq4GDjqeinu for ; Tue, 22 Mar 2022 11:34:20 -0700 (PDT) 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 CA29A3A1064 for ; Tue, 22 Mar 2022 11:34:19 -0700 (PDT) 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 F2CA46226BA; Tue, 22 Mar 2022 18:34:17 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (unknown [127.0.0.6]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 56AB362252A; Tue, 22 Mar 2022 18:34:17 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1647974057; a=rsa-sha256; cv=none; b=9vYFANhsWhuAwcI5ktJ6581lZawsjBDJOcUbvBdwtE3M7BtNHr7NUI75njSsEWjXJg22hW V+yc6YWOtTVROltchVcqAkpzh+HZ3DVvxiUGvL1OfRQIpMCUXtqatptPkyRc1egeOJ5/Dx DJyycuOYTgo5ANDvwEfB0G5P4HOMI6SGcFU1uVBmiG+m7NkervXJ5veqV6d46hvdwf+Sfd QFfHSWz/cCGEoNnn4ORQB6N4sq1iPKah82yQJ4MSqiO8f7DL5fdlkUr0qp2LbqFooqIwef u/4ZCog9euSdU/r94eVBb4YpNh4bCOfb3v59WclZf8WWiSrKzY+GrcC2A/B+VA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1647974057; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=CnH1vJeyu+p5OPYU5poaArIMKIc6ggG7tQ9GKwGfm5E=; b=lqFnNHmJSaGj5+yB1xgfI+759F52OsQugao+8YZojR5q24lCw6AkWr3NMQXgXBxdnPlNh/ ac6XK1lP7M8FXj8qfxeP05C1jSc92hWAQbCeSHlu5AMjXJlCBdzI2ACdFVf8ytdhAki18/ cCMPMKcJY1kUr7du02b70ycSlbxGx0CpDtTCJL24Bbenagh/3+g7unWXj+M+tMq+7VGP1p PTsMHkC/SAu6UlasLI3cCfdJTaFMslZBJGQBsgfLAblZPDTUUx/yVUI74yI/AYqWruXuGD WfTxcHEK3m7b1QTrNUa//f2gVi0sQwsWWcr49Tzpl3blOIxPjuZly6rzIxzbig== ARC-Authentication-Results: i=1; rspamd-c9cb649d9-jg7pk; auth=pass smtp.auth=hostingeremail smtp.mailfrom=dhc@dcrocker.net X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (gcp-us-central1-a-smtpout2.hostinger.io [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.107.0.146 (trex/6.5.3); Tue, 22 Mar 2022 18:34:17 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Spot-Imminent: 6089879f5d92f2ae_1647974057756_238991506 X-MC-Loop-Signature: 1647974057756:1978154131 X-MC-Ingress-Time: 1647974057756 Received: from [192.168.0.112] (c-73-170-122-71.hsd1.ca.comcast.net [73.170.122.71]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 4KNKrl3SF5z7YpHX; Tue, 22 Mar 2022 18:34:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1647974056; bh=7urTUHCoPeyNR7k+BshYKXuQLvf9m02OaTYt9LI8Iqw=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To; b=XFUdBEpNRfrHkRC+hmKrFo4/r5x07x5uaFKHlnMY39sfULbd31/G8r5QQ3dmDNzrM DkDYzd5p3nrvYRB0UwfpkcHVP9Htz1BXoMBjuzNLieKqq7/0wKeRNt/dglk0QpNj2r fsX/tjRjsB2oqqGAx7vNB0aPXjV+l9ePRFOQb9xlG2hh01tXveLzOi2wvY7Uf7b0pa 6HL+BRd/VPlgQDE86I31u0918zDXPGJnkZw/vb+7MhN5ptECwUbFnRkm4lJeIiuk/i DJvGQdHimC5y1toZFm31vk/53PvCckN51r7k8h/WeVKTU1rOHMBsnA9KOmoBxbxX1p +KaVVxuALPLPg== Message-ID: <084e651e-cca7-c139-9ba1-ac327a4a1b0b@dcrocker.net> Date: Tue, 22 Mar 2022 11:34:13 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Reply-To: dcrocker@bbiw.net Content-Language: en-US To: Todd Herr , EmailCore WG References: <3c3986a6-e90b-9319-b62b-c532f88a8cae@dcrocker.net> From: Dave Crocker Organization: Brandenburg InternetWorking In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Emailcore wg charter 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, 22 Mar 2022 18:34:33 -0000 On 3/22/2022 11:07 AM, Todd Herr wrote: > > Does that change your opinion of the impact of this ticket on our > adherence to the charter? Todd, Since the concern I'm raising is general, it was the number, not the target. I had in fact spent a moment of thought about doing a careful accounting for how many tickets applied to each working draft, but decided that that would be a distraction. Look at the diff. That's a lot of changes for a document with this charter's intent. And it is not at all clear to me that all those changes are essential, within the confines of the charter. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Mar 22 11:40:12 2022 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 989CB3A0FFA for ; Tue, 22 Mar 2022 11:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 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, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 AvVrZAVzOb_S for ; Tue, 22 Mar 2022 11:40:05 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 E17083A0FE2 for ; Tue, 22 Mar 2022 11:40:04 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id a11so11274586qtb.12 for ; Tue, 22 Mar 2022 11:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=7H2Zok4EUgpSDl/OeaSCCDV1OhQf0CxxAC8P2yBgS+Y=; b=EgA07jE1fEP7WpKcP6ULNDgZEp/sw5n+rYwE8tp8tROH7aS+m58etNNf+qO8Ei4W2o p7mJ5O3QWvPp5NY4rRqZPOzvf82xiOhofJ/rCOphlqPHLCiGtdOTcSckWi3q3xQWXkzB 07y/SQ01r9KrebiBA2q4nhQHXjyAgyHkeDMSP7CX0DyG7oo2b2f26k9+grXFmJDcWUnJ dZGslIRw1ETnfmt6lAyeILnGaGZ8bAH+bzf3HNXufg6RLZzRa1hrxQwkRyqdEkQ9JOEk vF48KYf08kYsMzKtjVx7O2+AJGKLvfjrek8uLEY4v8UiI9H6Axzc3zizyAcxZxwmSG2V aZDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=7H2Zok4EUgpSDl/OeaSCCDV1OhQf0CxxAC8P2yBgS+Y=; b=5aj/mHdJWcG9ocSdYSoTbP6/+SfGcxFVQdcMGAdG3je5Pdh75DwZLbcZti9j59gQe/ j+79Pnh4jI85/zpJ4Ug4/inqGUGDLzoGquLaEOP2F6vWqjjA/3wAK9Upt0v/q8Xn/fP+ KCnrNcFuU3MHWkvl2/shMcIl4mh74238uWNOVZDUrVvjODsbsLUIi9afmvynBsESXVsR NU5tDNI0ceAJFAtlf3udo4kXzj4MvJVQopxIe+b0RSe9v6eTK5EdOL4c5Hwi5IuzPsLt kJzS/WLokQb0Ot7IMa230ATL8F8gr9smISrzeRIulvT0QlThie77L+jSrB6VGJuooBiL aR9w== X-Gm-Message-State: AOAM532aUgaqI6WMOaqtaZtiHIcFQG6VbJ5S0md5A0d2m1APXs/KdbAZ j6FfYzE4WFG3G8FB41tLWCuYAPxgFlWUL6r52z5gZNMbGgI= X-Google-Smtp-Source: ABdhPJwBI6n+1MfqHBOfZzaQkQnsVfspTzQ7bXi3yygAgLLElP91YPS773ROuhD1HOm0LB4bph51faxvA2l8elhVod4= X-Received: by 2002:ac8:5a8f:0:b0:2e1:df21:d86f with SMTP id c15-20020ac85a8f000000b002e1df21d86fmr21429484qtc.450.1647974403172; Tue, 22 Mar 2022 11:40:03 -0700 (PDT) MIME-Version: 1.0 References: <3c3986a6-e90b-9319-b62b-c532f88a8cae@dcrocker.net> <084e651e-cca7-c139-9ba1-ac327a4a1b0b@dcrocker.net> In-Reply-To: <084e651e-cca7-c139-9ba1-ac327a4a1b0b@dcrocker.net> From: Todd Herr Date: Tue, 22 Mar 2022 14:39:47 -0400 Message-ID: To: EmailCore WG Content-Type: multipart/alternative; boundary="000000000000e682fa05dad2f083" Archived-At: Subject: Re: [Emailcore] Emailcore wg charter 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, 22 Mar 2022 18:40:10 -0000 --000000000000e682fa05dad2f083 Content-Type: text/plain; charset="UTF-8" On Tue, Mar 22, 2022 at 2:34 PM Dave Crocker wrote: > > Todd, Since the concern I'm raising is general, it was the number, not > the target. > > I see. Thank you for the clarification. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000e682fa05dad2f083 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Mar 22, 2022 at 2:34 PM Dave Croc= ker <dhc@dcrocker.net> wrote:=

Todd, Since the concern I'm raising is general, it was the number, not =
the target.

I see. Thank you for the clarification.

--

Todd Herr | Tech= nical Director, Standards and Ecosystem
e: todd.herr@valimail.com
=
m: 703.220.4153

This email and all data transmitted with it contains confidential and/o= r proprietary information intended solely for the use of individual(s) auth= orized to receive it. If you are not an intended and authorized recipient y= ou are hereby notified of any use, disclosure, copying or distribution of t= he information included in this transmission is prohibited and may be unlaw= ful. Please immediately notify the sender by replying to this email and the= n delete it from your system.

--000000000000e682fa05dad2f083-- From nobody Wed Mar 23 07:42:46 2022 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 65DF03A14DD for ; Wed, 23 Mar 2022 07:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=episteme.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 ekeHlHLcfTHf for ; Wed, 23 Mar 2022 07:42:40 -0700 (PDT) Received: from helm.helm.episteme.net (helm.helm.episteme.net [209.51.32.195]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE773A1385 for ; Wed, 23 Mar 2022 07:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=episteme.net; s=mail; t=1648046558; bh=0wP3RdeBWElidkBO2uo/d79OikOuhON2xZWhVU5iq9w=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=mBzPuPkCToOVI+JcKvYgtg8dxk9UHXAMg8C9b2OjNvukYBLx4gRH344FPsAZTReBp CGZkP/wDYI1QC7fgZvDYw5aM3mud1lyLabo0K6qtFMbQmPgUXN04FBRrblCIpzO2j1 RYq+kzhK56zhQB/4a6J+ftbHlhi/MWBuqk2JHm0w= From: Pete Resnick To: dcrocker@bbiw.net Cc: EmailCore WG Date: Wed, 23 Mar 2022 15:42:31 +0100 X-Mailer: MailMate (1.14r5880) Message-ID: <6D8239AA-DA26-456D-B547-DFC1B777001A@episteme.net> In-Reply-To: <3c3986a6-e90b-9319-b62b-c532f88a8cae@dcrocker.net> References: <3c3986a6-e90b-9319-b62b-c532f88a8cae@dcrocker.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_006B455F-0053-450B-8087-F8C09275B53B_=" Archived-At: Subject: Re: [Emailcore] Emailcore wg charter 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, 23 Mar 2022 14:42:46 -0000 --=_MailMate_006B455F-0053-450B-8087-F8C09275B53B_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 22 Mar 2022, at 18:20, Dave Crocker wrote: > https://www.ietf.org/rfcdiff?url1=3Drfc5321&url2=3Ddraft-ietf-emailcore= -rfc5321bis-10 > > A few questions to consider: > > - Are enough wg participants able and willing to justify every = > change, in detail, as conforming to the charter? Simply put, why were = > they essential, within the charter constraints? > - Given the number of changes, what is the basis for believing that = > an average reader will be able to apply the revised specification, = > while ensuring continued interoperability, especially given how = > creative readers can be with new text? > > The concern is not whether any given change is broadly reasonable or a = > generally good idea, but whether it is essential to the immediate = > working group goal and within its charter?=C2=A0 I certainly think it's a good idea to go through the diff and make sure = that we agree with the changes being made and that they are really = needed. Interestingly (to me), I just did a quick run-through of the = diff above and I was surprised with how *few* changes there actually = were in the document. Lots (most?) of the changes are changed reference = numbers, different spacing, or a moved paragraph or two; there were less = substantive changes than I had remembered. But on this suggestion, I = definitely will set aside some time to do a thorough review with the "is = this necessary" mantra in mind. That said, as per RFC 2418 3.3, it is in the end the chairs' call = whether any suggested change is within or out of scope of the charter. = I'm willing to presume they have been paying attention enough to have = called out anything that they noticed out of scope already, bit it's = certainly it's reasonable for any of us to ask the chairs to review any = particular change with regard to scope, and they may ask for = justification. And it's also reasonable to disagree with the chairs' = call on that call and appeal to the AD (etc.) if needed. But I don't = think we need to do some special collection of justifying "significant = evidence" for each change unless some question is raised about it that = hasn't already been reviewed. pr -- = Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best --=_MailMate_006B455F-0053-450B-8087-F8C09275B53B_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 22 Mar 2022, at 18:20, Dave Crocker wrote:

https://www.ietf.org/rfcdiff?url1=3Drfc5321&url2=3D= draft-ietf-emailcore-rfc5321bis-10

A few questions to consider:

- Are enough wg participants able and willing to justif= y every change, in detail, as conforming to the charter? Simply put, why = were they essential, within the charter constraints?
- Given the number of changes, what is the basis for believing that an = average reader will be able to apply the revised specification, while ens= uring continued interoperability, especially given how creative readers c= an be with new text?

The concern is not whether any given change is broadly re= asonable or a generally good idea, but whether it is essential to the imm= ediate working group goal and within its charter?=C2=A0

I certainly think it's a good idea to go through the diff= and make sure that we agree with the changes being made and that they ar= e really needed. Interestingly (to me), I just did a quick run-through of= the diff above and I was surprised with how few changes there a= ctually were in the document. Lots (most?) of the changes are changed ref= erence numbers, different spacing, or a moved paragraph or two; there wer= e less substantive changes than I had remembered. But on this suggestion,= I definitely will set aside some time to do a thorough review with the &= quot;is this necessary" mantra in mind.

That said, as per RFC 2418 3.3, it is in the end the chai= rs' call whether any suggested change is within or out of scope of the ch= arter. I'm willing to presume they have been paying attention enough to h= ave called out anything that they noticed out of scope already, bit it's = certainly it's reasonable for any of us to ask the chairs to review any p= articular change with regard to scope, and they may ask for justification= =2E And it's also reasonable to disagree with the chairs' call on that ca= ll and appeal to the AD (etc.) if needed. But I don't think we need to do= some special collection of justifying "significant evidence" f= or each change unless some question is raised about it that hasn't alread= y been reviewed.

pr

--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

--=_MailMate_006B455F-0053-450B-8087-F8C09275B53B_=-- From nobody Wed Mar 23 09:11:53 2022 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 87D193A1554 for ; Wed, 23 Mar 2022 09:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 48yJD0kNqe13 for ; Wed, 23 Mar 2022 09:11:42 -0700 (PDT) Received: from dormouse.elm.relay.mailchannels.net (dormouse.elm.relay.mailchannels.net [23.83.212.50]) (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 2A4CF3A17AD for ; Wed, 23 Mar 2022 09:11:41 -0700 (PDT) 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 40C126C3123; Wed, 23 Mar 2022 16:11:39 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (unknown [127.0.0.6]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 1E5606C3080; Wed, 23 Mar 2022 16:11:38 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1648051898; a=rsa-sha256; cv=none; b=E97l0GfD7FcivtFRA/scwWA1TiZ2nmfofDLx/tWBRUWm6hZ/YN23RaerQito5JcMRQ0kES ZTSqRx8GwrgoIYUKkgrsOygPaFy/jNZpfzf1qxyWicSARwbdeCO8uSt+Xeke3E87brQJJQ kXXOgCSMs1pzHEq2nFMm6TrHBkJ1/HQnNW8N9mPoPR7vt/Sc9lcPm0m3YAyQeqlN4ulAbd t0gbCP8Sm1rJEIwMWx7K0eAscK7rABmZqsgV2h5NdO1fU0ntSaXppnAz6J3uiAmg8VVBjG GWUErh+Q98SDotNzwJx9ph2NlQzapGFvpP36lD2GWVgcaVq37leZHqAtkBbYhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1648051898; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=TjrzrZSse+lYlRhWaGHwMkSaawR92iSd1mV2pUBX/FA=; b=QEK/Bs0eYx5aX8+8yNFlMeVZnKomN4CIFemeCqQRwXhCqF1TNXGw/dokNLzvQQlw00s/c7 OZ6cp5tvuUlKKuv6W+rRdSdZzgsrskergd5UoJyHJVuaV6Ds4+XQ754hCyl9c3emhO0CgB jaJcID5o+zS5HlTfLsn3d1xb98U2GW7QzUneHamgncSuy4yFXKk009zi7/pWBj4oAFJrft zoMiGg4C4zVdtvWqt3StPgZyA8XX1dQ6jH9MntS69KyTZtgBpfgik7v90sttqmnBMnRc72 7biNEfTzQ+DqDfKo1AsLpka4WCwX1HrfnXGtUCHz9VMctE0L+WOF/ZP7rL2H+Q== ARC-Authentication-Results: i=1; rspamd-55d445dbdb-nndj9; auth=pass smtp.auth=hostingeremail smtp.mailfrom=dhc@dcrocker.net X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (gcp-us-central1-a-smtpout2.hostinger.io [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.120.230.141 (trex/6.5.3); Wed, 23 Mar 2022 16:11:39 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Bubble-Thread: 6ecc730526963a17_1648051898588_1553583338 X-MC-Loop-Signature: 1648051898587:2024777117 X-MC-Ingress-Time: 1648051898587 Received: from [192.168.0.112] (c-73-170-122-71.hsd1.ca.comcast.net [73.170.122.71]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 4KNtdg6PTXz7YmlB; Wed, 23 Mar 2022 16:11:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1648051897; bh=peGz8h0Lry4/XEZYTW2wAgFOvI05aSFCmu/rjJUpLhU=; h=Date:Subject:To:Cc:References:From:Reply-To:In-Reply-To; b=ljcYDCPEJ+TY9+DukKUO/tC1IdmYzRWYEaPHyWGtBYUXMQ9UJAXenRd5OebJ/9QbQ ycEyworKY3WJfz216lyB5NsjxcUo5qh8t19p2ofwdSfzfI8bzHOyhZPoldcqdWdRxk V7PfnlTYhtPwjzT27YFGmskA02mipWjg3eXn+dYBQMLVbFQHoTs9vz/AstLxPoTZdU OykMX09DaJ5UxRjzwLrVhaCEwkAneQvzqy4k0Hp9bxgv/A/DAwxN3D2d7UiFlKLMW2 KnV+OTj/nrBlEs3OChE9mYxQvDOODre9J56rM21YK8ermpQztt4SLz/1oWLQFyFckT 7YW4XumGUS+BA== Message-ID: <4f962797-5f79-e5e7-9d05-5ff9e185f0e7@dcrocker.net> Date: Wed, 23 Mar 2022 09:11:33 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Pete Resnick Cc: EmailCore WG References: <3c3986a6-e90b-9319-b62b-c532f88a8cae@dcrocker.net> <6D8239AA-DA26-456D-B547-DFC1B777001A@episteme.net> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking In-Reply-To: <6D8239AA-DA26-456D-B547-DFC1B777001A@episteme.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Emailcore wg charter 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, 23 Mar 2022 16:11:51 -0000 On 3/23/2022 7:42 AM, Pete Resnick wrote: > But I don't think we need to do some special collection of justifying > "significant evidence" for each change unless some question is raised > about it that hasn't already been reviewed. That is, at base, a 'default yes' model. A charter with these kinds of constraints, typically benefits from a much more active consideration whether each possible change is within scope. I haven't done an audit, but it has seemed to me that consideration of scope has been rather more erratic than that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Mar 24 01:59:51 2022 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 DA8453A123F for ; Thu, 24 Mar 2022 01:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 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, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=episteme.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 ePIz95Na26nf for ; Thu, 24 Mar 2022 01:59:44 -0700 (PDT) Received: from helm.helm.episteme.net (helm.helm.episteme.net [209.51.32.195]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72553A137A for ; Thu, 24 Mar 2022 01:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=episteme.net; s=mail; t=1648112382; bh=ZL/SeenQuABKozqP1i1eMN5v/dteaN53vSsSHw51/nc=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=XK27Xjt+OfUdJNH3FXNMBDUthXets9SLQ2x8o1dQsqDIu+GER20KFwUsiL7Lo/faN d02nKcZuEXNyZfNwt1PuwPThxRBq7/Pz7C6ZQ0RH5nFmSoZst3APHiK5Bjiw6lKbE+ JWmCbiOLTr+AjP1+do9lf7P7LCThMpkcsxlfqXZI= From: Pete Resnick To: dcrocker@bbiw.net Cc: EmailCore WG Date: Thu, 24 Mar 2022 09:59:37 +0100 X-Mailer: MailMate (1.14r5880) Message-ID: <5067A054-3A57-4A38-8EBA-5430FB725117@episteme.net> In-Reply-To: <4f962797-5f79-e5e7-9d05-5ff9e185f0e7@dcrocker.net> References: <3c3986a6-e90b-9319-b62b-c532f88a8cae@dcrocker.net> <6D8239AA-DA26-456D-B547-DFC1B777001A@episteme.net> <4f962797-5f79-e5e7-9d05-5ff9e185f0e7@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Emailcore] Emailcore wg charter 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, 24 Mar 2022 08:59:50 -0000 On 23 Mar 2022, at 17:11, Dave Crocker wrote: > On 3/23/2022 7:42 AM, Pete Resnick wrote: >> But I don't think we need to do some special collection of justifying >> "significant evidence" for each change unless some question is raised >> about it that hasn't already been reviewed. > > > That is, at base, a 'default yes' model. Not at all. As I said, I've been presuming that the chairs have been doing their job by defaulting "no" to changes. I've certainly seen a consistent pattern of that, both from the chairs and from WG participants. So I don't think there's much of a reason to believe that we've made some big mistake along these lines. > A charter with these kinds of constraints, typically benefits from a > much more active consideration whether each possible change is within > scope. And I agree, again from my earlier message, that it would be prudent for each of us to re-read, with diff in hand, to make sure we believe that the due diligence was done. The thing that I don't see as necessary is what I took to be your proposal for that review to be so formal as to have documentation of "significant evidence" that each change met the appropriate charter criteria. We've had plenty of WGs in the past with very constrained charters and I've never heard of us doing that formal of an audit. > I haven't done an audit, but it has seemed to me that consideration of > scope has been rather more erratic than that. Not my impression, but a sanity check is always a good thing. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Thu Mar 24 21:51:15 2022 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 5F7103A08D6 for ; Thu, 24 Mar 2022 21:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.907 X-Spam-Level: X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 RbJ6kD-DKky8 for ; Thu, 24 Mar 2022 21:50:06 -0700 (PDT) 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 161E73A08D0 for ; Thu, 24 Mar 2022 21:50:05 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nXbti-000BuY-6o; Fri, 25 Mar 2022 00:50:02 -0400 Date: Fri, 25 Mar 2022 00:49:57 -0400 From: John C Klensin To: Alexey Melnikov cc: emailcore@ietf.org Message-ID: <729F25470553787206254C68@PSB> In-Reply-To: <06BA6973-002A-42A5-92A5-150BCEF0D958@fastmail.fm> References: <06BA6973-002A-42A5-92A5-150BCEF0D958@fastmail.fm> 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] RCPT commands, BCCs, and the "for" clause 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, 25 Mar 2022 04:50:22 -0000 --On Tuesday, March 22, 2022 15:08 +0100 Alexey Melnikov wrote: > Hi John, > (Replying as a WG participant) > >> On 22 Mar 2022, at 14:22, John C Klensin >> wrote: >> The second conclusion is that RFC 5321 says rather more about >> these topics than it should and that we are trying to fix the >> issues that text causes by adding more text and risking even >> more confusion (in other words, trying to get out of the hole >> by digging deeper). With the understanding that none of the >> ideas below are new except for the organization and context, >> my current hunch is that 5321bis should: >> >> (i) Remind people that a conforming SMTP server or >> (non-submission) client doesn't look at header fields, much >> less start performing heuristics on them, and hence does not >> have a clue as to which RCPT commands (or their arguments) are >> associated with "To:", "Cc:", or "Bcc:" header fields. >> Section 7.8 provides a loophole for, e.g., malware resistance >> measures, but does not change the principle. >> >> (ii) Mention that no attempt should be made to include "for" >> in a "Received:" header field if there is more than one RCPT >> command present, noting that this is forbidden by the syntax >> anyway. > > I think this statement is stronger than currently specified in > the draft and is not something I agree. If a message has 2 > RCPT TO recipients A and B (let's assume for simplicity that > A and B are end user email addresses, not mailing lists), I > think it is perfectly ok to do either: > > 1) The same message with Received with no FOR is delivered to > both A and B > > or > > 2) Recipient A receives a copy of the message with Received > with FOR A, while recipient B receives a copy of the message > with Received with FOR B. > > Your statement (ii) prevents choice 2) I think we are thinking about different parts of the relay chain. For the server that is inserting a "Received:" header just before making final delivery, you are absolutely correct. The "for" clause of that trace field is, I think, also fairly useless unless some post-delivery process makes changes to the recipient address. However, assume DNS records that look like example1.com. MX 5 relay1.example. example1.com. MX 2 relay2.example. example1.com. MX 0 deliveryServer1.example1.com. example2.com. MX 5 relay1.example. example2.com. MX 0 deliveryServer2.example2.com. Also assume the message in question leaves the MSA with RCPT TO: RCPT TO: RCPT TO: Now, assuming the two deliveryServers and relay2 are not answering when the MSA asks and that the MSA does not decide to send three separate messages on principle, relay1 gets a single mail transaction with the RCPT commands above. So, question 1 is what, if any, it puts in the "for" clause of the trace field it adds given that it has three possible target mailbox addresses? Statement (ii) above says "no for clause" but I'm listening for other options that clarify RFC 5321 rather than making substantive changes. Now, it (relay1) notices that the message contains domains with two different next-hop MX preferences (again assuming that deliveryServer1 is not being responsive). It opens a connection to relay2 with a mail transaction specifying RCPT TO: RCPT TO: Question 2 is what relay2 puts in the "for" clause of the trace field it generates. It still has a choice of two addresses and, as far as it is concerned, it is delivering one message to both. It opens a mail transaction to deliveryServer1, which, assuming it actually delivers separately to the two mailboxes (your case), generates a trace header for each that differs only in the "for" clause. FWIW, if deliveryServer1 hands off to a separate MDA (a distinction RFC 5321 does not recognize) that splits the messages up on a per-mailbox basis and deposits them in the mail store (something else 5321 at best hand waves about), it has the same problem as relay2 and cannot split the "for" clauses either. deliveryServer2 of course has it easier. It gets only one recipient from relay1, harry@example2.com, puts that in the "for" clause in the trace field it generates, and delivers the message to that mailbox. And, of course, if there were any way for relay1 to write a "for" clause with more than one RCPT command, tom, dick, and harry would all find out about the others unless the respective delivery servers edited those additional "for" subclauses out. 5321 forbids both multiple addresses per "for" clause and editing of trace fields by servers later in the chain, so that is, fortunately, a non-issue. So, my statement of the options (I did say "hunch" and not "conclusion" :-)) was clearly not correct and is in need of fixing (at least). On the other hand, your choice 2 is possible only for the MTA that splits multiple-recipient messages into individual ones, presumably for delivery. >> (iii) Clarify the text that mentions that "for" can cause >> unintended privacy disclosures and say that, if one is not >> sure of the appropriateness of the clause and the information >> that should go into it, it is generally better to just omit >> the clause. > Agreed. >> (iv) Mention as well that _any_ trace field might, under the >> wrong set of circumstances, disclose information that someone >> might consider sensitive and that, while those fields are >> often essential for debugging messages that have run into >> transport problems and may even be helpful in distinguishing >> spoofed or otherwise problematic messages from more desirable >> traffic (and even identifying the source of such bad >> traffic), complete protection of anything that might be >> considered private would argue for eliminating trace >> information entirely. > Agreed. >> Wordsmithing and some decisions about where to use 2119/8174 >> language obviously needed, but I'm hoping we can agree on the >> above or something like it as general principles. >> >> We then get rid of all of the hair-splitting about internal >> names and addresses on LANs, which addresses should be >> included in "for" clauses and which ones avoided, etc. If >> someone believes they can persuade the WG that it is worth >> doing the case analysis and offering more specific advice in >> the A/S they should certainly try (and be ready to write >> text). But, as far as 5321bis is concerned, my >> recommendation is that we concentrate on the above four >> points and tear everything else out. That would, IMO, >> improve clarity and and shorten 5321bis by a few pages. > I am personally Ok with this direction, but I think I would > like to see the new proposed text before fully committing to > it. Is it something you can post to the mailing list before > Friday or at least soon-ish? Obviously, no, since it is Friday already (busy week). Up to you, in your chair capacity, to decide whether we should discuss in circa seven hours or just defer the whole topic for the mailing list. My personal preference would be to see if we can get general agreement on the approach and then sort text out on the mailing list but, again, up to you. best, john From nobody Thu Mar 24 22:12:43 2022 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 895403A0489 for ; Thu, 24 Mar 2022 22:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 LO7WdDWRepFK for ; Thu, 24 Mar 2022 22:12:36 -0700 (PDT) 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 3BC003A0657 for ; Thu, 24 Mar 2022 22:12:35 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nXcFW-000BwV-AI; Fri, 25 Mar 2022 01:12:34 -0400 Date: Fri, 25 Mar 2022 01:12:29 -0400 From: John C Klensin To: John Levine , emailcore@ietf.org cc: "Murray S. Kucherawy" Message-ID: In-Reply-To: <20220322163839.20E54398FD7E@ary.qy> References: <20220322163839.20E54398FD7E@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] Relaxing the IANA registration requirement for SMTP Extensions in rfc5321bis 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, 25 Mar 2022 05:12:42 -0000 --On Tuesday, March 22, 2022 12:38 -0400 John Levine wrote: > It appears that John C Klensin said: >> keyword accidentally being used for different things, I'm in >> favor of relaxing the requirements somewhat from Standards >> Track or IESG-approved Experimental. > > My inclination is somewhere between specification required and > expert review, with the understanding that the point of the > review is just to see that the specification is at least > superficially plausible. We have our share of unused > extensions (MTRK, CONNEG, ...) and I'm not worried that there > is a flood of worse ones waiting. The cases that have gotten me concerned are variations of some of the recent discussions about media types. RFC 8494 opened the door to specialized uses of SMTP, uses that an Expert or Expert team might not fully understand. While 8494 (IMO) does not have that problem and does not introduce any new extensions (as far as the extension system is concerned, it is basically a profile). I don't think it is hard to imagine some specialized use coming along that involves a new extension or two for which the descriptions could be entirely plausible but incomprehensible to most of us. My instinct is that figuring out a way to do a community Last Call in conjunction with Expert Review -- Murray and I have kicked that back and forth a bit and probably the right way to do it is to stick with IESG review but involve the Designated Reviewers in the evaluation of the document and the Last Call and have the IESG's role be mostly pro-forma. >> Suggestion: RFC 5321 Section 8, IANA Considerations, describes >> the three registries but does not actually specify what goes >> in them, nor does it follow what is now the normal practice of >> providing a specific registration template or list of fields >> and descriptions of possible values [1]. For the SMTP >> Extensions Registry, we should consider either specifying a >> template or a list of things required in an application for a >> Service Extension. > That would be a good idea. Yesterday Alexey and I realized > that 5321 says VRFY is a service extension that somehow never > made it into the registry. I think that is a separate problem. I wish 5321 was more clear (and hope we can fix that) but VRFY support is (modulo the usual loopholes) required by 5321 but still required to be listed in EHLO responses. That makes it a required feature that is treated as a service extension (and, if you and Alexey found statements that seem to contradict other statements... well, I would not be terribly surprised). From the standpoint of the registry, especially in the days when there was no such thing as a required extension, that means is it not an extension at all and should not be listed. From the standpoint of common sense and minimization of confusion, it should clearly be in the registry, perhaps with a brief note. best, john From nobody Fri Mar 25 06:04:48 2022 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 BE6AB3A12D2 for ; Fri, 25 Mar 2022 06:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 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, T_SCC_BODY_TEXT_LINE=-0.01, 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 j4wY7Ted3gb7 for ; Fri, 25 Mar 2022 06:04:33 -0700 (PDT) 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 F26AD3A1300 for ; Fri, 25 Mar 2022 06:04:31 -0700 (PDT) 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 4945320E7D; Fri, 25 Mar 2022 13:04:30 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (unknown [127.0.0.6]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id A372720E11; Fri, 25 Mar 2022 13:04:29 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1648213469; a=rsa-sha256; cv=none; b=55c1EhLLG7F98iJsS20Os6c4FajF2DDCoxlJno/fOkYgswaKcvH2rybvJxyvXeuIh1q+TJ Axiu8MFiMxIEtgRLOKbMxaXV/xWcY/iHBwVCvClLqYRFDdRlDGWfI39sAdGWbLlUR0BUAy +oK18ZbvYQbkKhMf55ZVesv3kpgvihs2cQ/FWF93xaUcs99xR2xLF6qni8feMdmqLTitKv Qp3783B3WhWx0OR3n285xcx4lDf5+YbcpQ1dEHEBnUDExGFsIA/QvXR+RZgChwIijABp2n XDsjsryofwrAEjU7o/BHcgeSHrvuA4pLc1vYpQpkmWGFU/B0iVGlg2+J+j0pig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1648213469; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=QvkbEFaOs1VFsGbMlHTEGkB8T6V5T2a8pMhtlUU/g4U=; b=J4PMAoad8UwifK1Oc3bnU+pWst+51i8gCRzS6kbQdmdKdPNebwUrBo7Sz7PPzgeVAHZLiL njeEW75hQrcDBlucegY3/peSb3jX2Vmr0VCh5lU8XP02vLzkWcUOGQhx5SsxJOaHPgMaMx jl39jhbMQuTUeSl9fz7Q/as1+U18I+k8IJmx5set1YJWrsr6LgAG11VmGol+zYFzqq4ayu ONmECCAlgbOw2guTedcr/x8zvAqluV7sjyTiJ1WgoRpzlM9hblIe7MthMJ/KH0/QHQtkb8 aBLFcgHtpNKM1o+K6Qe0X7qIrCSaoqWT9VwYgsSR4JoqymfQueLN5I5LpX0iOw== ARC-Authentication-Results: i=1; rspamd-7b6f4d8d7c-2wvhz; auth=pass smtp.auth=hostingeremail smtp.mailfrom=dhc@dcrocker.net X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (gcp-us-central1-a-smtpout2.hostinger.io [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.96.38 (trex/6.5.3); Fri, 25 Mar 2022 13:04:30 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Thread-Suffer: 4780be193f31912f_1648213470067_3870104893 X-MC-Loop-Signature: 1648213470067:2529393180 X-MC-Ingress-Time: 1648213470067 Received: from [192.168.0.112] (c-73-170-122-71.hsd1.ca.comcast.net [73.170.122.71]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 4KQ2Nq5PwKz7YpHS; Fri, 25 Mar 2022 13:04:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1648213468; bh=AusPa2xF0TFJzmHmgy5GNvggxHL9f8GfTPFiToUsmQQ=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To; b=kZLyip2wMVffKwC17M0MPhSIXe0T81nk6cQH6R2TW8FcBO4LtpLCG5f9VStpyACzF ZcSBGR7HHqdsh/e94mHXrzVyzdgXJBLdGnw0b2EQUutsDtZAn0SeaRIz/0G8gdUsTA 99WEK2L0Bpst5j1uLWdhIfagmKm77vQtFQYyHXn8d4ynWq7dLiFYQEyvH29OgoEcQ/ QetF2E7LPFj+LKWoZ/MLBcUYAZJhHI8AmamEM2/C3G516bLCYah5KdiRzikXZ59WJH cx68FPRPgbn+AS/2Yc4IaAgbusoVgVm2Tm3Gu+kELaIAF4DL3lLSCMN+nNt9j3G58H CoUxS9Va376iQ== Message-ID: <867f9c68-1f1b-a170-ad5c-36631f6c701d@dcrocker.net> Date: Fri, 25 Mar 2022 06:04:24 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Reply-To: dcrocker@bbiw.net Content-Language: en-US To: Todd Herr , emailcore@ietf.org References: From: Dave Crocker Organization: Brandenburg InternetWorking In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 25 Mar 2022 13:04:47 -0000 On 3/22/2022 7:29 AM, Todd Herr wrote: > Authentication is the process of establishing the identity of one or > more of the endpoints of a communication channel. TLS only requires > authentication of the server side of the communication channel; > authentication of the client side is optional. Authentication is the process of validating an asserted identity of one or more of the endpoints of a communication channel. TLS usage typically only attempts authentication of the server side of the communication channel; authentication of the client side is optional. Further, 'opportunistic' use of TLS offers a somewhat fragile form of authentication. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Mar 25 06:17:40 2022 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 A35763A120F for ; Fri, 25 Mar 2022 06:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 68cxmFIpnx0U for ; Fri, 25 Mar 2022 06:17:32 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 9BE413A1209 for ; Fri, 25 Mar 2022 06:17:32 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id j13so7983433plj.8 for ; Fri, 25 Mar 2022 06:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:from:to :subject; bh=AkL30Gfk7RJmcvSlkoKmHn1cwZiu7tHFvv7JF3IiXuo=; b=Em+KOQW7riNeOZJgMUCCh29i+s0xkbTtZytvztewSwXQyivqJYzUQ7DUEtCBJGwO8W U4xRszPwcHtamNtCDKPT3dawVFtfA+QI7jSukPflc5J4bPsY8vnUvMJl6QNTyemHJehW qXDBhc2au69wYXzzsUR1ToPj40sabukv9p/1+WU8TkVsC7j9E4B+OpsS4Y6Hf8u/ujF3 bfOWKMEEAu2c7DDcIk3306AtLIQ5tD86bt9rLqH2qtnWTrNqHxbUgd3W8vAGMGS4Z/0H kYuV25+VYVaxt0VXkAWi5I+OhdmR0gvAAtg6nYEhArrVab3KaLgO2+l58Ac8gT9o3dQr uyhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:from:to:subject; bh=AkL30Gfk7RJmcvSlkoKmHn1cwZiu7tHFvv7JF3IiXuo=; b=rVtEkAdit1M7xoKAL05q8DQlB4WJvfEz35VjWJoDjx9VTavPzt5VyxIdjpVD9dwvoL HV3exxguz0xYw8xJK0mfhBMO/NMmsc93oDaFTKpMbWLpxdYZ4LJpC7n9Nd7fC7HzESOw I++Clj0irxP8zYQHEqkFvnBkI2FJx6LChyMUhPaxZp7DFOWx2bqSd8+JQLYMyZBpLpts a5ZDlfndq0B/qN/uV9tJ/PuduLT65uuuProcBUh8RY1PttPL6YG8gHmN62ABDjo5CxsI YCKJV/MHwns3R+6yrLrc4ag2C5gRVZwNwby3KR+P02S9NLQUSDxQiqE+cKcIe4x6FJxT q6Gg== X-Gm-Message-State: AOAM531Rvbd1bB4/8YUFQ36g+aVG6rNaQEBPdCc7rpCnCWtYYQy6bfTC 4iOE0nnauipOU+KlPyvo7vQj25bONe4= X-Google-Smtp-Source: ABdhPJwZYe+su1MpjWBnm6DXEq2bQs9117xmOZRyFMu6nfCrPsRdPrBXJosEx2hKaFEJQ8Fhqfvu6g== X-Received: by 2002:a17:902:8d86:b0:153:9858:b4c1 with SMTP id v6-20020a1709028d8600b001539858b4c1mr11736401plo.59.1648214251652; Fri, 25 Mar 2022 06:17:31 -0700 (PDT) Received: from [192.168.0.112] (c-73-170-122-71.hsd1.ca.comcast.net. [73.170.122.71]) by smtp.gmail.com with ESMTPSA id p10-20020a637f4a000000b00373a2760775sm5474152pgn.2.2022.03.25.06.17.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Mar 2022 06:17:31 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------UZMdMf3Ao3XOsPCjGn4jdCyy" Message-ID: <14c279c3-aa67-4a47-e9a6-92f4c6ea8741@gmail.com> Date: Fri, 25 Mar 2022 06:17:29 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US From: Dave Crocker To: EmailCore WG Archived-At: Subject: [Emailcore] sub-addressing 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, 25 Mar 2022 13:17:38 -0000 This is a multi-part message in MIME format. --------------UZMdMf3Ao3XOsPCjGn4jdCyy Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit A propos the reference to sub-addressing at the end of the wg session: RFC 5598, Section 3.1: > It is common for sites to have local structuring conventions for the > left-hand side, , of an . This permits sub- > addressing, such as for distinguishing different discussion groups > used by the same participant. However, it is worth stressing that > these conventions are strictly private to the User's organization and > are not interpreted by any domain except the one listed in the right > side of the . The exceptions are those specialized > services that conform to public, standardized conventions, as noted > below. > > Basic email addressing defines the as being globally > opaque. However, there are some uses of email that add a > standardized, global schema to the value, such as between an Author > and a Gateway. The details remain invisible to the > public email transfer infrastructure, but provide addressing and > handling instructions for further processing by the Gateway. > Standardized examples of these conventions are the telephone > numbering formats for the Voice Profile for Internet Mail (VPIM) > [RFC3801 ], such as: > > +16137637582@vpim.example.com, > > and iFax ([RFC3192 ], [RFC4143 ] such as: > > FAX=+12027653000/T33S=1387@ifax.example.com. -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crocker2@redcross.org --------------UZMdMf3Ao3XOsPCjGn4jdCyy Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

A propos the reference to sub-addressing at the end of the wg session:


RFC 5598, Section 3.1:

It is common for sites to have local structuring conventions for the
   left-hand side, <local-part>, of an <addr-spec>.  This permits sub-
   addressing, such as for distinguishing different discussion groups
   used by the same participant.  However, it is worth stressing that
   these conventions are strictly private to the User's organization and
   are not interpreted by any domain except the one listed in the right
   side of the <addr-spec>.  The exceptions are those specialized
   services that conform to public, standardized conventions, as noted
   below.

   Basic email addressing defines the <local-part> as being globally
   opaque.  However, there are some uses of email that add a
   standardized, global schema to the value, such as between an Author
   and a Gateway.  The <local-part> details remain invisible to the
   public email transfer infrastructure, but provide addressing and
   handling instructions for further processing by the Gateway.
   Standardized examples of these conventions are the telephone
   numbering formats for the Voice Profile for Internet Mail (VPIM)
   [RFC3801], such as:

                       +16137637582@vpim.example.com,

   and iFax ([RFC3192], [RFC4143] such as:

                FAX=+12027653000/T33S=1387@ifax.example.com.

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crocker2@redcross.org
--------------UZMdMf3Ao3XOsPCjGn4jdCyy-- From nobody Fri Mar 25 12:26:53 2022 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 E64653A00DB for ; Fri, 25 Mar 2022 12:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 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, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=episteme.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 VGd6MQtluS7V for ; Fri, 25 Mar 2022 12:26:46 -0700 (PDT) Received: from helm.helm.episteme.net (helm.helm.episteme.net [209.51.32.195]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC8E3A00E1 for ; Fri, 25 Mar 2022 12:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=episteme.net; s=mail; t=1648236404; bh=IVIqt5r8Ks99W9A6sd6OyeSEM6B1ji1PU+Q1cXK7dAE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Ni62JuXoUfqnAsffExV1W1lOGldAzYOZeHLs1ujvqFcojEIMovTUmIpbVqc98T3Ry mRoPKgvNXrw8ymnaoySjneVHGl79gh34H8ka04vZyN1q3UK1/X87qXSnuHVbIsd1pO M/7HK35Lxv2LtxiFnZFg0Mbh2KhD9Z7KbEyi5LqU= From: Pete Resnick To: dcrocker@bbiw.net Cc: Todd Herr , emailcore@ietf.org Date: Fri, 25 Mar 2022 20:26:35 +0100 X-Mailer: MailMate (1.14r5880) Message-ID: <1AEF385E-EDFC-46A5-830C-6F235758D6B1@episteme.net> In-Reply-To: <867f9c68-1f1b-a170-ad5c-36631f6c701d@dcrocker.net> References: <867f9c68-1f1b-a170-ad5c-36631f6c701d@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 25 Mar 2022 19:26:52 -0000 On 25 Mar 2022, at 14:04, Dave Crocker wrote: > Further, 'opportunistic' use of TLS offers a somewhat fragile form of > authentication. I don't think that's quite correct. In one set of cases, opportunistic TLS provides absolutely no form of authentication (as the text Todd provided explains). In the other set of cases (opportunistic DANE TLS), you get solid authentication. Calling that combination "fragile" seems inaccurate. I'd rather leave off this extra sentence and leave it to sections 5.1 and 5.2 to explain what's available. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Fri Mar 25 14:19:27 2022 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 A481C3A080B for ; Fri, 25 Mar 2022 14:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 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, T_SCC_BODY_TEXT_LINE=-0.01, 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=j9gnS+aY; dkim=pass (2048-bit key) header.d=taugh.com header.b=ZdKglazv 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 P8u40jTMRhP5 for ; Fri, 25 Mar 2022 14:19:20 -0700 (PDT) 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 A3D203A0B88 for ; Fri, 25 Mar 2022 14:19:20 -0700 (PDT) Received: (qmail 26861 invoked from network); 25 Mar 2022 21:19:18 -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=68eb.623e31d6.k2203; bh=EaO/CqWESD0mP8FcZ9zQfGo6ltRZeLWRZDXjElPEomE=; b=j9gnS+aYBUDdL4C1/bIHL05sxw5TA8865Duaz+rNncdSXI2NeRQusypk+eABE4DSQY3e6F/9wT2UMkEFNU4m5s1xDaha/tnLS6jKMeHovz8vsLGQhwp0+jbdKGOZEJwisYh+qdxLp8BB61hYLsxtTabgsFHHEsvZtDw2y8XSf2SzBRmKryEoKg2MqrXO18ctb0lA3gK21szPI61ZUHxhyPZHyAb0RdHEBs54Qw7RwScJ2M9McHpzQW/LaRXFLIMIxIJJ2W2xaBe8tjB1HfSRqCOKcjdn42v5SC+m7km+j5aS9kyTj73TzI3t3gLteZ1Zbm5JtBk1DLLhMy1JN0USoA== 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=68eb.623e31d6.k2203; bh=EaO/CqWESD0mP8FcZ9zQfGo6ltRZeLWRZDXjElPEomE=; b=ZdKglazvwbim+pohkWW1NXLvSJzQGnmYjT4jSo0lUIioPUhz+17IO/jJMuBQ17Ey9OEHzGjon/oW+lCnoC4D9QLGIInCmktKZPaY6JsqrTqbgQiBnmmamtKwMtSZCIT2SCk3O/bQA4TGRoehpmjC9crO+TTRefBhlwpPfkViQVwwnZfM2li+aYGxS1W+xF0uauEixld88zSi7vs22yoBqtZ5eXRqNF2bF0gqS4glIQHUuE0BwDpAVwzS4V2dzwhB8aO/6eKIQROeByQx5+rE1pnop+tBlrEW3W/427dq2+LeL++UXbXv7+X0mUAu94+02xSMAICnxbZ8XgC3UbPLHA== 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; 25 Mar 2022 21:19:18 -0000 Received: by ary.qy (Postfix, from userid 501) id 32C3939C442D; Fri, 25 Mar 2022 17:19:16 -0400 (EDT) Date: 25 Mar 2022 17:19:16 -0400 Message-Id: <20220325211917.32C3939C442D@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: resnick@episteme.net In-Reply-To: <1AEF385E-EDFC-46A5-830C-6F235758D6B1@episteme.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] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 25 Mar 2022 21:19:26 -0000 It appears that Pete Resnick said: >On 25 Mar 2022, at 14:04, Dave Crocker wrote: > >> Further, 'opportunistic' use of TLS offers a somewhat fragile form of >> authentication. > >I don't think that's quite correct. In one set of cases, opportunistic >TLS provides absolutely no form of authentication (as the text Todd >provided explains). In the other set of cases (opportunistic DANE TLS), >you get solid authentication. Don't forget MTA-STS (RFC 8461) which provides more or less the same thing as DANE TLS in a klunkier way. If you use DANE and MTA-STS in enforce mode I agree you get solid server authentication, give or take how widely implemented they are. R's, John From nobody Sat Mar 26 03:43:46 2022 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 200D33A12B6; Sat, 26 Mar 2022 03:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 rCe3YUFWjQKy; Sat, 26 Mar 2022 03:43:39 -0700 (PDT) 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 EA48E3A0CF1; Sat, 26 Mar 2022 03:43:38 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nY3tR-000Fpb-6V; Sat, 26 Mar 2022 06:43:37 -0400 Date: Sat, 26 Mar 2022 06:43:31 -0400 From: John C Klensin To: Todd Herr , emailcore@ietf.org Message-ID: <2E7CBA0AF40E2351EFFAC747@PSB> In-Reply-To: References: 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] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 26 Mar 2022 10:43:45 -0000 Todd, This comment may partially relate to the discussion among Dave, Pete, and John, but my concern is a bit different. While someone who knows what to look for and is reading carefully will figure it out, I think it is very important that you make two distinctions explicitly: (1) Putting S/MIME and PGP aside, none of these techniques, at least as I understand them, offer user/sender level authentication. Those that provide authentication authenticate hosts, not users, and some provide integrity protection to part or all of the message (integrity protection is the third part of the puzzle and should probably be mentioned along with authentication and confidentiality). They _may_ authorize particular users or mailboxes to send mail, but do not authenticate the users themselves. These distinctions should be made clear. (2) Again putting S/MIME and PGP aside, confidentially for these methods is strictly hop by hop, with messages in clear on relays. Put more strongly, if servers can easily be attacked, protecting messages in transit between them does not help much. And these procedures do not provide endpoint to endpoint confidentiality. In addition, your Section 5.5 on S/MIME and PGP should note that, properly used and with the right options, they provide not only endpoint-to-endpoint confidentiality of message content but strong authentication of sending users (not just mailboxes) and message body integrity. Finally, I question dismissing S/MIME and PGP on the grounds that they "operate fully independent of SMTP". Certainly that is true. But, when SMTP runs over a security layer (such as TLS or even SSH) that security layer is operating fully independent of SMTP too. I don't have a serious problem with your explaining them briefly and then saying "out of scope", but I think you need a better explanation. john --On Tuesday, March 22, 2022 10:29 -0400 Todd Herr wrote: > Greetings. > > I've reviewed the comments generated by my posting rev 3 here > at the end of January, and I've incorporated some of them. > > The one that I didn't incorporate was one that Dave Crocker > made to perhaps discuss the concepts of Channel Security > versus Object Security in section 5.5, Message-Level > Confidentiality. While I thought the suggestion had merit on > its face, the fact that the section is just a paragraph talking > about how OpenPGP and S/MIME (and similar technologies) are > out of scope for the A/S made me decide not to add more text > to this section. > > Current revision follows, there's a place in the agenda to > discuss it during Friday's meeting. > > =========================== cut here ======================== > > A/S Proposed Text - Confidentiality and Authentication > > 5. Confidentiality and Authentication with SMTP > > SMTP is specified without embedded mechanisms for > authentication or confidentiality; its traffic is therefore > "in the clear". Years of operational experience have shown > that such transmission exposes the message to easy compromise, > including wiretapping and spoofing. To mitigate these risks, > operation of SMTP has evolved over the years so that it is > used with the benefit of Transport Layer Security (TLS - > RFC8446) to provide both confidentiality and authentication in > the transmission of messages. This section discusses those > topics and their most common uses. > > It is important that the reader understand what is meant by > the terms "Authentication" and "Confidentiality", and > for that we will borrow directly from RFC8446. > > - > > Authentication is the process of establishing the identity > of one or more of the endpoints of a communication channel. > TLS only requires authentication of the server side of the > communication channel; authentication of the client side is > optional. > - > > The term "confidentiality" describes a state where the > data (i.e., the message) is transmitted in a way that it is > only visible to the endpoints of a communication channel. > > It is not uncommon for implementers to use the term > "encryption" to mean "confidentiality", but this is > not quite correct. Rather, encryption using TLS is the current > method by which confidentiality is achieved with SMTP, but > that does not mean that future methods might not be developed. > > Note: With typical email use of TLS, authentication only is > performed by the sending client of the target receiving > server. That is, it serves to validate that the connection has > been made to the intended server, but does not validate who > initiated it. > > 5.1 Optional Confidentiality > > The most common implementation of message confidentiality is > what's known as "opportunistic TLS", which is frequently > referred to as "opportunistic encryption". With this > method, a receiving server announces in its greeting that it > is capable of supporting TLS encryption through the presence > of the "STARTTLS" keyword. The sending client then > attempts to negotiate an encrypted connection, and if > successful, transmits the message in encrypted form; if > negotiation fails, the client falls back to sending the > message in clear text. > > Opportunistic TLS is confidentiality without authentication, > because no effort is made to authenticate the receiving > server, and it is optional confidentiality due to the ability > to fall back to transmission in the clear if a secure > connection cannot be established. That said, most modern > implementations of SMTP support this method, especially at the > largest mailbox providers, and so the vast majority of email > traffic is encrypted during its time transiting from the > client to the server. > > Note: While TLS provides protection while the message is in > transit for a single SMTP connection, a message that is > encrypted for one SMTP hop might not be encrypted on the next > hop and it might not be encrypted within the MTAs relaying the > message or at its destination. In fact, storage in plain text > should be expected! > > 5.2 Required Confidentiality, with Receiving Server > Authentication > > Two protocols exist that move message confidentiality from > optional to required (with conditions as noted below) - > MTA-STS [RFC8461] and DANE for SMTP [RFC7672]. While they > differ in their implementation details, receiving servers > relying on either protocol are stating that they only accept > mail if the transmission can be encrypted with TLS, and a > failure to negotiate a secure connection MUST result in the > sending client refusing to transmit the message. > > These two protocols differ from Opportunistic TLS in that they > require receiving server authentication and there is no > fallback to sending in the clear if negotiation of an > encrypted connection fails. > > Note: Both protocols mentioned in this section rely not only > on the receiving server but also the sending client supporting > the protocol intended to be used. If the sending client does > not implement or understand the protocol requested by the > receiving server, the sending client will use Opportunistic > TLS or clear-text to transmit the message. > > 5.3 Message-Level Authentication > > Protocols exist to allow for authentication of different > identities associated with an email message - SPF [RFC7208] > and DKIM [RFC6376]. A third protocol, DMARC [RFC7489], relies > on SPF and DKIM to allow for validation of the domain in the > visible From header, and a fourth, ARC [RFC8617], provides a > way for each hop to record results of authentication checks > performed at that hop. > > All of these are outside the scope of this document, as they > are outside the scope of SMTP. They deal with validating the > authorized usage of one or more domains in an email message, > and not with establishing the identity of the receiving server. > > 5.4 SMTP Authentication > > SMTP Authentication, which is often abbreviated as SMTP AUTH, > is an extension to SMTP. Its name might suggest that it would > be within scope for this section of the Applicability > Statement, but in fact it's not. > > SMTP AUTH defines a method for a client to identify itself to > a Message Submission Agent (MSA) when presenting a message for > transmission, usually using port 587 rather than the > traditional port 25. The most common implementation of SMTP > AUTH is for a person to present a username and password to > their mailbox provider's outbound SMTP server when > configuring their MUA for sending mail. > > 5.5 Message-Level Confidentiality > > Protocols such as S/MIME (RFC8551) and OpenPGP (RFC4880) exist > to allow for message confidentiality outside of the operation > of SMTP. That is to say, using these protocols results in > encryption of the message prior to its being submitted to the > SMTP communications channel, and decryption of the message is > the responsibility of the message recipient. There are numerous > implementations of these protocols, too many to list here. As > they operate fully independent of SMTP, they are out of scope > for this document. > =========================== cut here ======================== From nobody Sat Mar 26 07:25:47 2022 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 11C0B3A08C6 for ; Sat, 26 Mar 2022 07:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.862 X-Spam-Level: X-Spam-Status: No, score=-6.862 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_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=WsKsaZUk; dkim=pass (2048-bit key) header.d=taugh.com header.b=AkuKXVyq 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 Ua1HxgFLZACO for ; Sat, 26 Mar 2022 07:25:41 -0700 (PDT) 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 DB09C3A08D0 for ; Sat, 26 Mar 2022 07:25:40 -0700 (PDT) Received: (qmail 58513 invoked from network); 26 Mar 2022 14:25:38 -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=e48f.623f2262.k2203; bh=ZVO0INPe1wSuLtoHaF21WJKZC3goaqUbG9G5Krn7U7E=; b=WsKsaZUkjaM70w+jbecoDlYMWqF4drxEXjvGvwJQ2zJ3NRNlqzVHJtPZVaE7yTzi6C0UdPgqUmvST58E/NeL9xGhTg5H/olRtNZTxfN6KD7Xz8VWfYEXE2YbGQkArSlRsTlDq+Y1oSD/IPh9QR+eh8uNi0cNdUgKbPPUXlM4aCvRgmn5hGQTpjnUfumBXT+A+UCZL+RPGQA0/bbByop/AquIOfOVXRShH9MQKGTMl3DIeSD1xoQ1Tl+r8CsW1aC0QRTpXXRRosyFyMCnecw9IUP8yRmLvnq/9ougfokQjejVR8OyfLRE9yE32C0IY7rdU574gKY9YqV+eUydW7obUg== 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=e48f.623f2262.k2203; bh=ZVO0INPe1wSuLtoHaF21WJKZC3goaqUbG9G5Krn7U7E=; b=AkuKXVyqoGAapIbpzpV0lUXt/M2fb54ZqYfyAkDikD16cmifg8cpTzQqD9RLcSgpZkX9D4RsdanJGl5v9ZBLIPtM344MbKSs5PSxaFGbUhhk78mXBT0ImaRGDDAAeYFqosYfVMibdW91N8qLr15BFBAUnYWfA4WAEjkZSpHPezPn2UHYPoFKrMod1jM0Srgvje+Oot+KagnRj7dL+us4iA7xbwB2PSqZCf1Th8OzUG9iDwgkgEM+spwP59EocbegPngYjKf6S3wFsfs6V2Un/V9c5AxCHvnEDJircp56c/ibxASf5mV1y4jTag/sCtuRMOin2DXuNzB5VsrtzhS1+A== 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; 26 Mar 2022 14:25:38 -0000 Received: by ary.qy (Postfix, from userid 501) id 06D4939CC70C; Sat, 26 Mar 2022 10:25:36 -0400 (EDT) Date: 26 Mar 2022 10:25:36 -0400 Message-Id: <20220326142538.06D4939CC70C@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: john-ietf@jck.com In-Reply-To: <2E7CBA0AF40E2351EFFAC747@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] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 26 Mar 2022 14:25:46 -0000 It appears that John C Klensin said: >Finally, I question dismissing S/MIME and PGP on the grounds >that they "operate fully independent of SMTP". Certainly that >is true. But, when SMTP runs over a security layer (such as TLS >or even SSH) that security layer is operating fully independent >of SMTP too. ... When the client uses DANE or MTA-STS, it's using TLS to verify that the SMTP server is the one it expects to be talking to. I don't think that's outside of SMTP, and it seems quite different from S/MIME. I do agree that the threats and mitigations could be matched up better. R's, John PS: I suppose I should send text. From nobody Sat Mar 26 11:14:47 2022 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 7FB583A11BB for ; Sat, 26 Mar 2022 11:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 DP6FYptpnC72 for ; Sat, 26 Mar 2022 11:14:40 -0700 (PDT) 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 CA7623A11BC for ; Sat, 26 Mar 2022 11:14:40 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nYAvt-000Iwn-2O; Sat, 26 Mar 2022 14:14:37 -0400 Date: Sat, 26 Mar 2022 14:14:31 -0400 From: John C Klensin To: John Levine , emailcore@ietf.org Message-ID: <07DA3334CF0B97061CE559F4@PSB> In-Reply-To: <20220326142538.06D4939CC70C@ary.qy> References: <20220326142538.06D4939CC70C@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] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 26 Mar 2022 18:14:46 -0000 --On Saturday, March 26, 2022 10:25 -0400 John Levine wrote: > It appears that John C Klensin said: >> Finally, I question dismissing S/MIME and PGP on the grounds >> that they "operate fully independent of SMTP". Certainly that >> is true. But, when SMTP runs over a security layer (such as >> TLS or even SSH) that security layer is operating fully >> independent of SMTP too. ... > > When the client uses DANE or MTA-STS, it's using TLS to verify > that the SMTP server is the one it expects to be talking to. I > don't think that's outside of SMTP, and it seems quite > different from S/MIME. That is fair. I was thinking much more about backward (sender-side) authentication (of sending users, and sender-SMTP hosts) than about forward authentication of receiver-SMTP hosts. Our apparent disagreement is, IMO, more reinforcement for the idea that the document should be far more clear about exactly what it is talking about and where. > I do agree that the threats and mitigations could be matched > up better. Yeah. thanks, john From nobody Sat Mar 26 11:43:04 2022 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 2D5E03A11E7 for ; Sat, 26 Mar 2022 11:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.11 X-Spam-Level: X-Spam-Status: No, score=-7.11 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_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=O7T9QpBW; dkim=pass (2048-bit key) header.d=taugh.com header.b=nqsZcOiS 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 BKFSyzQMENXu for ; Sat, 26 Mar 2022 11:42:56 -0700 (PDT) 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 0DD6F3A11E5 for ; Sat, 26 Mar 2022 11:42:55 -0700 (PDT) Received: (qmail 17475 invoked from network); 26 Mar 2022 18:42:51 -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=4440.623f5eab.k2203; bh=cavGvxHMCDZ7zPXF3rXTwpMDV/YY6Pt7bcD/41j85sY=; b=O7T9QpBW6MmPUcIr1gbbIcuDRINGCgUoenfosNH8sW8NI3efUFQHBYm3Cvy5w06/wvt1n7oxJ0Jv4YWdR44f4aiWmj1LwlPgSSvQ2bhK0ApevX38/stVNwtVJ0Qex+JhYqSw5BNEQcFY0DycQXp8+ffROy0DHtL7aDYAvW2P6IZlzL7PZmrZFPrlAD9Ic0geTqnX7S4S/LmquOWwSGh4Mx+71uV6ctSjdoWFHr25W9IXjk2E4eKQs9JpPPZzVLQYdte/ZNBOkZL/+VxsH0OrSPMV9FKg/ZQV531HfIo8YK7V6syBcu5nzjalEwDWeqNkJdJMieitDqPd6+RlnSwrCw== 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=4440.623f5eab.k2203; bh=cavGvxHMCDZ7zPXF3rXTwpMDV/YY6Pt7bcD/41j85sY=; b=nqsZcOiSy13vUE/zdNBk4m00LbN5E4EMQTcO5HqLi37JqDOXL127gXeVjAeak7bdmmMZX1xJLef412YlGHlJ5Nl/G5Qg9/dn4snYlNQ9jMhVv/gUl3Y2e85751Y3TIWhUpnCi7eaUic8Ced+VBLbcROLm/oB1bDeeFMyzOiY3vq1vdtQ3FyQcLaff7/dpzpX2YynesbAU5VXrv4D3jCtjsA+bFHAke+H9Eh9HLKMKDiw+g3flMWVyjxsJ+Du8vozkbyYG83+aOqeB4IBZ3c8hben5uFacjrMbo5/NFC3R7Fv2gnBawy/zeUukW1LYhA7Z6pS6DAulbf3evIHx0pfrw== 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; 26 Mar 2022 18:42:51 -0000 Received: by ary.qy (Postfix, from userid 501) id C3FFE39D011D; Sat, 26 Mar 2022 14:42:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 2F8B739D00FF; Sat, 26 Mar 2022 14:42:50 -0400 (EDT) Date: 26 Mar 2022 14:42:50 -0400 Message-ID: <6c88b685-fc9b-c737-60c5-eafdfe6171ef@taugh.com> From: "John R Levine" To: "John C Klensin" , emailcore@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: <07DA3334CF0B97061CE559F4@PSB> References: <20220326142538.06D4939CC70C@ary.qy> <07DA3334CF0B97061CE559F4@PSB> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 26 Mar 2022 18:43:02 -0000 On Sat, 26 Mar 2022, John C Klensin wrote: >> When the client uses DANE or MTA-STS, it's using TLS to verify >> that the SMTP server is the one it expects to be talking to. ... > > That is fair. I was thinking much more about backward > (sender-side) authentication (of sending users, and sender-SMTP > hosts) than about forward authentication of receiver-SMTP hosts. I have seen code that does client authentication with client certs, but to the extent it even exists, it's definitely submission, not SMTP. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Mar 26 12:25:29 2022 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 F162C3A1253 for ; Sat, 26 Mar 2022 12:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.908 X-Spam-Level: X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 Y0H9CnGB16DD for ; Sat, 26 Mar 2022 12:25:25 -0700 (PDT) Received: from veps.esmtp.org (veps.esmtp.org [155.138.203.148]) (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 495FB3A1252 for ; Sat, 26 Mar 2022 12:25:23 -0700 (PDT) Received: from veps.esmtp.org (localhost. [127.0.0.1]) by veps.esmtp.org (MeTA1-1.1.Alpha17.1) with ESMTPS (TLS=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256, verify=OK) id S0000000000027BAB00; Sat, 26 Mar 2022 19:25:22 +0000 Received: (from ca@localhost) by veps.esmtp.org (8.16.1/8.12.10.Beta0/Submit) id 22QJPLhk016734 for emailcore@ietf.org; Sat, 26 Mar 2022 19:25:21 GMT Date: Sat, 26 Mar 2022 19:25:21 +0000 From: Claus Assmann To: emailcore@ietf.org Message-ID: <20220326192521.GA3224@veps.esmtp.org> Reply-To: emailcore@ietf.org Mail-Followup-To: emailcore@ietf.org References: <20220326142538.06D4939CC70C@ary.qy> <07DA3334CF0B97061CE559F4@PSB> <6c88b685-fc9b-c737-60c5-eafdfe6171ef@taugh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6c88b685-fc9b-c737-60c5-eafdfe6171ef@taugh.com> Archived-At: Subject: Re: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 26 Mar 2022 19:25:28 -0000 On Sat, Mar 26, 2022, John R Levine wrote: > I have seen code that does client authentication with client certs, but to > the extent it even exists, it's definitely submission, not SMTP. sendmail can enforce client authentication via certs in SMTP and it is being used as such (based on data I've seen). -- Address is valid for this mailing list only, please do not reply to it directly, but to the list. From nobody Sat Mar 26 12:52:21 2022 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 ABE6A3A0DDA for ; Sat, 26 Mar 2022 12:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.61 X-Spam-Level: X-Spam-Status: No, score=-5.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 ptQD9aNkauUb for ; Sat, 26 Mar 2022 12:52:14 -0700 (PDT) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 008BB3A11E6 for ; Sat, 26 Mar 2022 12:52:13 -0700 (PDT) Received: from kent.sdaoden.eu (kent.sdaoden.eu [192.0.2.2]) by sdaoden.eu (Postfix) with ESMTPS id 386FA16059; Sat, 26 Mar 2022 20:52:10 +0100 (CET) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 110026C04F; Sat, 26 Mar 2022 20:52:08 +0100 (CET) Date: Sat, 26 Mar 2022 20:52:08 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: emailcore@ietf.org Message-ID: <20220326195208.FgRUo%steffen@sdaoden.eu> In-Reply-To: <20220326192521.GA3224@veps.esmtp.org> References: <20220326142538.06D4939CC70C@ary.qy> <07DA3334CF0B97061CE559F4@PSB> <6c88b685-fc9b-c737-60c5-eafdfe6171ef@taugh.com> <20220326192521.GA3224@veps.esmtp.org> Mail-Followup-To: emailcore@ietf.org User-Agent: s-nail v14.9.23-255-gdafaa09dd5 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 26 Mar 2022 19:52:19 -0000 Claus Assmann wrote in <20220326192521.GA3224@veps.esmtp.org>: |On Sat, Mar 26, 2022, John R Levine wrote: |> I have seen code that does client authentication with client certs, \ |> but to |> the extent it even exists, it's definitely submission, not SMTP. | |sendmail can enforce client authentication via certs in SMTP |and it is being used as such (based on data I've seen). Even though Viktor Dukhovni is here .. i was also using client certificates with postfix. (And SMTPS, so it is possible. In fact i always have a hard time seeing the difference except for the dedicated configuration that listens on a dedicated socket. =46rom my own dumb user point of view i connect to SMTPS:465.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Sat Mar 26 12:59:00 2022 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 88AEF3A12FA for ; Sat, 26 Mar 2022 12:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=zIXsdN+9; dkim=pass (2048-bit key) header.d=wizmail.org header.b=csdPhi4c 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 kQsmcoY1CSLI for ; Sat, 26 Mar 2022 12:58:52 -0700 (PDT) Received: from wizmail.org (wizmail.org [217.146.107.12]) (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 BB7353A12E4 for ; Sat, 26 Mar 2022 12:58:52 -0700 (PDT) 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:From:References:To:Subject:MIME-Version:Date:Message-ID: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=wFevabvu+h96jfBZJMPvcK6GWnZnEb75ne5H1vqkAbo=; b=zIXsdN+9cokEvplPQ+OqYee2hd 05N/Tqc5rFhSwPvfIkkL+mrzwNlN2IssNYE6OSHiKLhUmGyTAZL4V24Q7vCg==; 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:From: References:To:Subject:MIME-Version:Date:Message-ID: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=wFevabvu+h96jfBZJMPvcK6GWnZnEb75ne5H1vqkAbo=; b=csdPhi4cZ/OIaIgn5gsYDDuHvs ssE3vDbUlxdrP5evYynAxEHlfZrKZsca14SRF2U3MU0ebYHQk9pphOoLqmqVkQoRd+kpyVSy14+UF 6r5oJnf+YmjEi0F37svLWldpNI9KKtM4gyNV2BgHu5hs3ZXFk/uUifStB1DYDbVEdfmmjMTKdj/EN dAZPC13r/Tm6nh46T5ZGhGcIACmCWHRjbcG4DWPoDo6aeAJuCjfYfQSy6bxYK5pGRQ72SJ2flfpew x3kU23pc0dhshuEPiYTi9FiLIidCwfsx52+ldqDUQmnfkWKY/4WP2in6QaRF7lmTPIzhpOd5hOLoe v0HiSz+A==; 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=[IPV6:2a00:1940:107:1194::1000]) by wizmail.org (Exim 4.95.113) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1nYCYh-0073bh-0K for emailcore@ietf.org (return-path ); Sat, 26 Mar 2022 19:58:47 +0000 Message-ID: <93d3ea6e-fd7e-0515-c855-88f23a7915e8@wizmail.org> Date: Sat, 26 Mar 2022 19:58:33 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-GB To: emailcore@ietf.org References: <20220326142538.06D4939CC70C@ary.qy> <07DA3334CF0B97061CE559F4@PSB> <6c88b685-fc9b-c737-60c5-eafdfe6171ef@taugh.com> <20220326192521.GA3224@veps.esmtp.org> <20220326195208.FgRUo%steffen@sdaoden.eu> From: Jeremy Harris In-Reply-To: <20220326195208.FgRUo%steffen@sdaoden.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=[IPV6:2a00:1940:107:1194::1000]) with esmtpsa Archived-At: Subject: Re: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 26 Mar 2022 19:58:59 -0000 On 26/03/2022 19:52, Steffen Nurpmeso wrote: > Claus Assmann wrote in > |sendmail can enforce client authentication via certs in SMTP > |and it is being used as such (based on data I've seen). > > i was also using client > certificates with postfix. As can Exim, likewise orthogonal to port number and STARTTLS vs. on-connect. So that's a full triple of "the independents". -- Cheers, Jeremy From nobody Sat Mar 26 13:19:08 2022 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 7E63E3A137C for ; Sat, 26 Mar 2022 13:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 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, T_SCC_BODY_TEXT_LINE=-0.01, 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=WnBP/w1h; dkim=pass (2048-bit key) header.d=taugh.com header.b=IO5Hy9n+ 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 kMXvOwHmtSzR for ; Sat, 26 Mar 2022 13:19:00 -0700 (PDT) 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 7E00B3A1384 for ; Sat, 26 Mar 2022 13:19:00 -0700 (PDT) Received: (qmail 37536 invoked from network); 26 Mar 2022 20:18:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=929d.623f7531.k2203; bh=FPL3soRJol27nBkJl7bi7P2sNPye2HBwrxRAd8AMa1g=; b=WnBP/w1h8Im0TbJftm1Q2t/COh1MZNR80XznVIboGIF/cI5rO19ylFK0jRTDS5sOv3ay1Jc4NnkOMymtYO+QZGkKZSB46yngQKmolam7Md/s3hmG4rt7Z3DEjQcViRwFJRV6TYKSQGw3i3SIrQ2Zbx38fORW1gDNFxcxeCppWhySGTUUwQIMsEhfGNYq7duhRlVX5cajou6p/rAb/fh8bHycWQDgWPlnqUqGm5m7H0Tbc1J2e4qgyqmnihVY2mlEPvHGsNnJlWF9GQbkvVZCT3esoJqvXo1y7xZJU7W7TfUG5lXFxaaPeZX8P2pfiRZJbJcMmudNBWgUgVuCqcmWjQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=929d.623f7531.k2203; bh=FPL3soRJol27nBkJl7bi7P2sNPye2HBwrxRAd8AMa1g=; b=IO5Hy9n+tBQ0YLpop461ZR3uu0bPxWo/u5oFs+s4GbB2QNw630DvGSdIJIZESA/0ei+NtAR1Cb6tGBBIu8T7niVk0R5XTf6ueJRbqOxu4y51KBbq5XGFmg0a/WtmZLaZ8RsV/LmGM8EW+tQ4BAr5FWWXH8CNi3QMPTk1RwzNbOtKa6ZEhPncapON0yF8lBJrHuyd0/QbcDHMdhK3i77FnIfRKLFrGYCKoWP09LRfrv6FCNc5hWxH2SFJ4yaWjXQzqh8tNIt19G1kupQD0a7Ycg3Hg1H+7G6MJqe8/32nthV+RyB6pry7Huy/o6RQEnr6nRqMBAskXfJThKBy0wBDEw== 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; 26 Mar 2022 20:18:56 -0000 Received: by ary.qy (Postfix, from userid 501) id 5981639D1283; Sat, 26 Mar 2022 16:18:54 -0400 (EDT) Date: 26 Mar 2022 16:18:54 -0400 Message-Id: <20220326201856.5981639D1283@ary.qy> From: "John Levine" To: emailcore@ietf.org In-Reply-To: <20220326192521.GA3224@veps.esmtp.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] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 26 Mar 2022 20:19:06 -0000 It appears that Claus Assmann said: >On Sat, Mar 26, 2022, John R Levine wrote: > >> I have seen code that does client authentication with client certs, but to >> the extent it even exists, it's definitely submission, not SMTP. > >sendmail can enforce client authentication via certs in SMTP >and it is being used as such (based on data I've seen). I believe the code is there and someone is using it, but I'm having trouble figuring out how one would use it for SMTP rather than submission. If you only accept mail from hosts that provide certs that you like, you're not much of an SMTP server. (Note that you can do submission on port 25.) R's, John From nobody Sat Mar 26 13:29:34 2022 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 5F6703A13F0 for ; Sat, 26 Mar 2022 13:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 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, T_SCC_BODY_TEXT_LINE=-0.01, 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=wBkBNjVE; dkim=pass (2048-bit key) header.d=wizmail.org header.b=nmkeCaJv 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 ImbcWUCMelkj for ; Sat, 26 Mar 2022 13:29:26 -0700 (PDT) Received: from wizmail.org (wizmail.org [217.146.107.12]) (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 9E22A3A13CA for ; Sat, 26 Mar 2022 13:29:26 -0700 (PDT) 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:From:References:To:Subject:MIME-Version:Date:Message-ID: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=VayY1WYMEFG5uTE5lLSB6SWl1IgyJnpU1NCKrYLGTU0=; b=wBkBNjVEsW7Wq8w7pjA1fd8L3f Z1h3MoxbXK/RnGlOWuz0PK25lvrCtPjgiDz7LC/ilgKU4OMP5kpXlVCBPRCQ==; 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:From: References:To:Subject:MIME-Version:Date:Message-ID: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=VayY1WYMEFG5uTE5lLSB6SWl1IgyJnpU1NCKrYLGTU0=; b=nmkeCaJvaFJus+OgQHypWSBB+S rX43KsHP6wOj012PDV/sb53pVvhFXMsh4a6Tlkt0cCHzpRAaruJjG3i4y8hhO4oA/YQhFA8/iK4k/ UsZ+2Tcr17Fck7prYbs2/1KEbdaZZFpMlSLSD+dHUmwH//hkTmf0DuUtRBXfW8wEGnN2grI4wNxNs IG0PB0OumFlgHrJ+/Wfuu5C7YadiG2qZAQ9Z4pHAapxY9BwOzjGfMkR3F4J6LEHj0inhUUXW0xZh6 XLhSn2PW4WodG6xhuDXdF9YkapiRcGVh9FumFyOezPmdcwXeVGyGODEnvcwB1nPaP/nJUNcHTZiOa UbhTFvgw==; 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=[IPV6:2a00:1940:107:1194::1000]) by wizmail.org (Exim 4.95.113) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1nYD2H-0074Io-1C for emailcore@ietf.org (return-path ); Sat, 26 Mar 2022 20:29:21 +0000 Message-ID: Date: Sat, 26 Mar 2022 20:29:17 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-GB To: emailcore@ietf.org References: <20220326201856.5981639D1283@ary.qy> From: Jeremy Harris In-Reply-To: <20220326201856.5981639D1283@ary.qy> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=[IPV6:2a00:1940:107:1194::1000]) with esmtpsa Archived-At: Subject: Re: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 26 Mar 2022 20:29:32 -0000 On 26/03/2022 20:18, John Levine wrote: > If you only > accept mail from hosts that provide certs that you like, you're not much of an > SMTP server. Maybe you do both forwarding (for a limited set of authenticating senders) and reception-and-delivery (from anywhere)? But perhaps you want to declare that the former is submission. I don't have the energy to argue. -- Cheers, Jeremy From nobody Sat Mar 26 13:41:40 2022 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 7AF733A14FB for ; Sat, 26 Mar 2022 13:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 FR_XP6XEbbXr for ; Sat, 26 Mar 2022 13:41:34 -0700 (PDT) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 166603A14F6 for ; Sat, 26 Mar 2022 13:41:33 -0700 (PDT) Received: from kent.sdaoden.eu (kent.sdaoden.eu [192.0.2.2]) by sdaoden.eu (Postfix) with ESMTPS id DFE7616059; Sat, 26 Mar 2022 21:41:30 +0100 (CET) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id CD6296C053; Sat, 26 Mar 2022 21:41:29 +0100 (CET) Date: Sat, 26 Mar 2022 21:41:29 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Jeremy Harris Cc: emailcore@ietf.org Message-ID: <20220326204129.z5xYV%steffen@sdaoden.eu> In-Reply-To: References: <20220326201856.5981639D1283@ary.qy> Mail-Followup-To: Jeremy Harris , emailcore@ietf.org User-Agent: s-nail v14.9.23-255-gdafaa09dd5 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Archived-At: Subject: Re: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 26 Mar 2022 20:41:39 -0000 Jeremy Harris wrote in : |On 26/03/2022 20:18, John Levine wrote: |> If you only |> accept mail from hosts that provide certs that you like, you're not \ |> much of an |> SMTP server. | |Maybe you do both forwarding (for a limited set of authenticating senders) The postfix camp says relay policy. |and reception-and-delivery (from anywhere)? | |But perhaps you want to declare that the former is submission. I don't |have the energy to argue. Aye. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Sat Mar 26 17:18:36 2022 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 BA3113A1026 for ; Sat, 26 Mar 2022 17:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 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, T_SCC_BODY_TEXT_LINE=-0.01, 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=pC2dXEkG; dkim=pass (2048-bit key) header.d=taugh.com header.b=g04Ywp5B 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 18KFicc_SJzz for ; Sat, 26 Mar 2022 17:18:29 -0700 (PDT) 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 C03F73A101F for ; Sat, 26 Mar 2022 17:18:28 -0700 (PDT) Received: (qmail 73758 invoked from network); 27 Mar 2022 00:18:25 -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=1201c.623fad51.k2203; bh=gYVC4XIEB3Dx335pU8Sbt8ye0p7nHoWiIyoZxEEpNwU=; b=pC2dXEkGJXfHBqcPYCHxvv0s1hLhi1bhAs7/O5LSCEYpMwqJ49eA6lSfJSGESbXMpHpAPffQMrQiEUThlxClW0HZMtyFSTKor56NaJoP5gsRN/tR6r6Z+Fb8M7NBQwZk660iwFkfvjxDVSoI34hKNV7E6u4nZXrMWjKEK6Ki61XqX7YOrUrFBSMfadVrUbQgtqC/HzeyU3obMLo1Jjwb1OkRq0KqUJgmCvMqfPg5k5pGzvp2vNIlKmulBSy+9pcKsonLDgpmjo/ROBBEZhChAYuMQhrqXHUuebXiHMNEkOSCM67eH5qgDvITEhgsWSJvKZJq+p8s2fclvXlD0M/1QA== 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=1201c.623fad51.k2203; bh=gYVC4XIEB3Dx335pU8Sbt8ye0p7nHoWiIyoZxEEpNwU=; b=g04Ywp5BT8QA782idXBJygxLb81tr3eQ78olQUTOWaOpkyczBH7rNltd0DDAn9DzrNwdYLgwiWqsPM6jc6k6e1IB7RPlSaoZGjQndYYWQco/DLrSTjt1JpXU2n4/DmOjePOU3Y+EaZP9iIsxwTlfn1Igm3i0YdCLbSjbVws+rAD6AQhQpidfVUVF8YHwOGsNr9g0cxZ2xJ5+Ert4nqRaTxpkUhYVCWuFN6StFXS4qIYpqsg4btVfmntcNDEWjXHnY198JOE0ElLcWupBlfwi6vwVSKzAJGXnlrLDmC4twUIf2puK2KqqzxF2mmvbqd54p0i9Y8BTBYm2xT1vM2PiaA== 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; 27 Mar 2022 00:18:25 -0000 Received: by ary.qy (Postfix, from userid 501) id BC27F39D39D6; Sat, 26 Mar 2022 20:18:23 -0400 (EDT) Date: 26 Mar 2022 20:18:23 -0400 Message-Id: <20220327001824.BC27F39D39D6@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] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 27 Mar 2022 00:18:34 -0000 It appears that Jeremy Harris said: >On 26/03/2022 20:18, John Levine wrote: >> If you only >> accept mail from hosts that provide certs that you like, you're not much of an SMTP server. > >Maybe you do both forwarding (for a limited set of authenticating senders) >and reception-and-delivery (from anywhere)? Good point. This gets us into nitipicky arguments about submission vs smarthost vs SMTP, which I think are best discussed not very much. R's, John From nobody Sat Mar 26 18:28:44 2022 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 173463A176E for ; Sat, 26 Mar 2022 18:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.907 X-Spam-Level: X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 36OnvBLU23gX for ; Sat, 26 Mar 2022 18:28:37 -0700 (PDT) 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 3F8A73A176C for ; Sat, 26 Mar 2022 18:28:36 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nYHhp-000Jw2-PB; Sat, 26 Mar 2022 21:28:33 -0400 Date: Sat, 26 Mar 2022 21:28:27 -0400 From: John C Klensin To: Jeremy Harris , emailcore@ietf.org Message-ID: <9073ABE04A07BECBB4E2C5F4@PSB> In-Reply-To: References: <20220326201856.5981639D1283@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] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 27 Mar 2022 01:28:42 -0000 --On Saturday, March 26, 2022 20:29 +0000 Jeremy Harris wrote: > On 26/03/2022 20:18, John Levine wrote: >> If you only >> accept mail from hosts that provide certs that you like, >> you're not much of an SMTP server. > > Maybe you do both forwarding (for a limited set of > authenticating senders) > and reception-and-delivery (from anywhere)? > > But perhaps you want to declare that the former is submission. > I don't have the energy to argue. Jeremy, Not to argue (but perhaps to agree instead)... The problem is that, if the former (or a bunch of other odd cases) are submission, then we open a can of something nastier than worms. As you know, issues about port selection, whatever one thinks of RFC 8314 [1], and other small details aside, the key difference between submission and "normal" SMTP is that we allow (and encourage) submission servers to do all sorts of things to fix up whatever garbage MUAs send them and make the messages fit for sending across the public Internet... even including potentially applying S/MIME or PGP. We forbid all of that to normal SMTP MTAs, so declaring the kind of forwarding you describe as submission would be really bad news. John Levine and others, One thing that tends to get lost in these discussions is that there are many uses of SMTP for special applications, even when those applications run over the public Internet. If the operators of a receiver-SMTP (delivery server or not), knows that it should be receiving traffic only from a restricted set of sender-SMTP systems and consider the traffic or its possible consequences at all sensitive, it becomes reasonable and appropriate for them to insist on more or less strong authentication of either the sending user (S/MIME or PGP cases, but they require accepting the message and looking at its content) or the previous-hop sender-SMTP. Over the years I've seen efforts at authentication of the former using many options including checking the connection attempt against a list of permitted IP addresses, magic cookies in the HELO/EHLO command or tricks with the MAIL command (most often involving use of trick local-parts), requiring that SMTP run over SSH and doing some handshaking before the actual mail session is established, and client cert checking. I think it would be unnecessary and unwise for the A/S to explain those cases in any detail or spend non-trivial time on them more generally. But I think it is important that it be written with enough awareness of them that we do not accidentally prohibit, or even say nasty things about, cases that are perfectly reasonable under the right circumstances. And, repeating something I've tried to say before in the last 48 hours, it is extremely important that the document be very clear about what it is talking about and, in particular, avoid talking about authentication without being clear who or what is being authenticated and to what or who. best, john [1] Translation of the implicit snarky comment, noting that Submission being out of scope for the WG takes 8314 out of scope too (and IMAP, POP, etc., are even more so): When the Submission Server is being run by a conventional MSP on the public Internet and separated from and serving multiple MUAs, 8314 makes perfect sense. However, when the two are both operating on a well-secured enterprise LAN or the connection between the two is being run over a well-secured connection (e.g., SSH or even IPv6 link encryption with the server refusing to accept unencrypted connections), the MSA server sees only cleartext but forcing running TLS over such connections is almost certainly going to be a waste of time and energy with nearly zero improved security. Similar comments can be made on the Mail Access (POP/IMAP) side of things. I'm mentioning this only because it is another case of assuming that the most common cases are the only ones and then writing specifications accordingly. We really need to be more careful about that. From nobody Sat Mar 26 22:57:07 2022 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 DA6273A16CD for ; Sat, 26 Mar 2022 22:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 CCHs1oxKlWQT for ; Sat, 26 Mar 2022 22:57:01 -0700 (PDT) Received: from veps.esmtp.org (veps.esmtp.org [155.138.203.148]) (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 2D6683A16BE for ; Sat, 26 Mar 2022 22:57:00 -0700 (PDT) Received: from veps.esmtp.org (localhost. [127.0.0.1]) by veps.esmtp.org (MeTA1-1.1.Alpha17.1) with ESMTPS (TLS=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256, verify=OK) id S0000000000027C6800; Sun, 27 Mar 2022 05:56:58 +0000 Received: (from ca@localhost) by veps.esmtp.org (8.16.1/8.12.10.Beta0/Submit) id 22R5ut3f026783 for emailcore@ietf.org; Sun, 27 Mar 2022 05:56:55 GMT Date: Sun, 27 Mar 2022 05:56:55 +0000 From: Claus Assmann To: emailcore@ietf.org Message-ID: <20220327055655.GA58451@veps.esmtp.org> Reply-To: emailcore@ietf.org Mail-Followup-To: emailcore@ietf.org References: <20220326192521.GA3224@veps.esmtp.org> <20220326201856.5981639D1283@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220326201856.5981639D1283@ary.qy> Archived-At: Subject: Re: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 27 Mar 2022 05:57:05 -0000 On Sat, Mar 26, 2022, John Levine wrote: > figuring out how one would use it for SMTP rather than submission. If you only By selectively enforcing it for "well known" hosts (or even domains). There are different "levels" of requirements, so admins can decide whether to require a cert that can be "verified", a specific cert issuer, or even stronger restrictions. -- Address is valid for this mailing list only, please do not reply to it directly, but to the list. From nobody Wed Mar 30 18:45:12 2022 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 14A5F3A0BE3 for ; Wed, 30 Mar 2022 18:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.111 X-Spam-Level: X-Spam-Status: No, score=-7.111 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_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 kvoqJ09lT78I for ; Wed, 30 Mar 2022 18:45:04 -0700 (PDT) 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 F398F3A0C35 for ; Wed, 30 Mar 2022 18:45:03 -0700 (PDT) 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 4DE018138E; Thu, 31 Mar 2022 01:45:02 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (unknown [127.0.0.6]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 84A02812B7; Thu, 31 Mar 2022 01:45:01 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1648691101; a=rsa-sha256; cv=none; b=IvFPqKgH9hi6KQxARHWnP3A4V1sfcio0RTPYNIpNzGBG981I16rPeYzcvhDTlYbgdEoWPX uRoeYVjPPe+ir7/tK2UU8B0jxFXL7bvT6G9Q2jGrYy48AehmITpiTZb3B2bcHdTtbvFT2d P7SOnuGn1S+fnd6YrNOURGxmKJ56okSFGs32em66CmIuhcH+FgzcstXokMducGNjfeJ7AX 8qkZ6fuCojxIdoq2rE7aZGfGNdj3DFuC7U1RxzkOwaWKvoqoOYpvyvq1+9WGscAxgtufsa 7RUsXio22E6YuYOf1lYREgKTESD894oQtQzvymcxcDI0DX6M1liZDK0fV6mezw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1648691101; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=q9Exgfk8C4vm6pHxqRXBAau5vhgAh37g2W/Iwo2fyAk=; b=m6wX5rDC+MYCyOjaKR6jOuF+DfNSLIHLUXikFB3NL70exLtOPABmK4ll6aHqtCRKd9J2oY WGw92ZHXQSRCx1I17K4YjvfWZLM9SvDHPotFtt9PRu3BxPVVyxqhCnazbFYqgyHygflGbg 6Sz/VajtAB1Pc1a0BzY57gMOfnq88cgLwG9faKWvfGlhwFnR1oPFYuy3Ng/NJozZjUX+CN FMrJwLh0HZhJFjM4L8WSJZHrpoN4Z6BP1zntEWdle+5ibvx6ChMjGc3N+T652gZ65opCc/ De2iCb0m3w09TwNKMYi03l2yeaMvnenexbs8As8Xu0NHCZ1R31jQOl5Ys5RWdg== ARC-Authentication-Results: i=1; rspamd-5d5f5ff57c-7fw4z; auth=pass smtp.auth=hostingeremail smtp.mailfrom=dhc@dcrocker.net X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (gcp-us-central1-a-smtpout2.hostinger.io [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.127.95.89 (trex/6.5.3); Thu, 31 Mar 2022 01:45:02 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Harbor-Tart: 225bc2bd5d297012_1648691101988_2512039270 X-MC-Loop-Signature: 1648691101988:1306305086 X-MC-Ingress-Time: 1648691101988 Received: from [192.168.0.112] (c-73-170-122-71.hsd1.ca.comcast.net [73.170.122.71]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 4KTR224Trgz7bbbD; Thu, 31 Mar 2022 01:44:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1648691100; bh=yXswGrb+KkqlhNy+JOr2H3jXdNBdAWvGoHIwD8f+5bE=; h=Date:Subject:To:Cc:References:From:Reply-To:In-Reply-To; b=V8gCQbJT6/jOT0T0DYMh+sZTemotviTPPCK/QaPr5GQOFIO9/2aEt6ciYKqHV4k5P fkaCbleFBWLgQOS071DlUnZhSmW3I4l23M2PnEiZNYfyjVvrZPY2WGIV9o0dP8AFh0 QUV3zlofNQiPVsq1g8vcIIGGDRccRrO0Z+Pe6qta8LT6hTnbgr76GT+IDQ2JAjwTFT KpHEK4B+H1Kyp3f1MfVQjSsQCls2ym6TCbJMPIr00mErN6uGUHRvalMsh77Vbvipq6 lOAbF15DXHC7O5wjFKHqzEr7Kic8ouoarzKyXTEGuV+1uvGLjJ76vCLou0vquUhUqL wL7D59INHACaA== Message-ID: <507c10a5-b9e2-688f-4cf6-8f70ab31aa0b@dcrocker.net> Date: Wed, 30 Mar 2022 18:44:57 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Pete Resnick Cc: emailcore@ietf.org, Todd Herr References: <867f9c68-1f1b-a170-ad5c-36631f6c701d@dcrocker.net> <1AEF385E-EDFC-46A5-830C-6F235758D6B1@episteme.net> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking In-Reply-To: <1AEF385E-EDFC-46A5-830C-6F235758D6B1@episteme.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 4 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, 31 Mar 2022 01:45:10 -0000 On 3/25/2022 12:26 PM, Pete Resnick wrote: > On 25 Mar 2022, at 14:04, Dave Crocker wrote: > >> Further, 'opportunistic' use of TLS offers a somewhat fragile form of >> authentication. > > I don't think that's quite correct. In one set of cases, opportunistic > TLS provides absolutely no form of authentication (as the text Todd > provided explains). So, this prompted some exploration, which mostly created more confusion. My comment came from an extended wg discussion which, I think, produced RC 7435 (Opportunistic Security: Some Protection Most of the Time). I took the goal of such work to be finding ways to get encryption, without needing a global cert system. This would seem to support the view that opportunistic encryption, such as with TLS, doesn't do authentication. Opportunistic TLS appears to have two different goals. One is to invoke TLS after the start of the application session, via starttls. The second is the one that lets encryption work without a global cert. This latter one is what my comment was intended to refer to. And sure, in the abstract, encryption requires a public key for the target, not an authenticated identity. However consider that servers often provide self-signed certs. These are the cases I intended in my comment. They are offering an identifier and they are self-authenticating it. That is, in practice, my understanding is that TLS provides encryption by anchoring it to a proffered identifier. Even an ad hoc one. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net