From nobody Sat Jan 1 09:35:56 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 AFFE73A1512 for ; Sat, 1 Jan 2022 09:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.912 X-Spam-Level: X-Spam-Status: No, score=-0.912 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=EZYfWBwq; dkim=pass (1152-bit key) header.d=tana.it header.b=AC5YokNF 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 tu_zwaJx9Onm for ; Sat, 1 Jan 2022 09:35:48 -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 C80F43A150F for ; Sat, 1 Jan 2022 09:35:46 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1641058542; bh=sawHbdM+b+OM9m0OzCJnaORhEgm5KH5To9KN4chNruo=; h=Subject:To:References:From:Date:In-Reply-To; b=EZYfWBwqssVatbuvUwpvNd9Z9YAE6Bt2Bga9rGqbze+q7ji9PYcKTRLA9OmCdQpVZ 7qvPjFbJJ03bLY0uKpTCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1641058542; bh=sawHbdM+b+OM9m0OzCJnaORhEgm5KH5To9KN4chNruo=; h=To:References:From:Date:In-Reply-To; b=AC5YokNFXq9VFpJwTawwSZv3rWEUwKWsOjVKpg6ympaE6PiwXZhSA9jcECJWQPZVG XM1llFc7iwmz2o+VXWn0vX3iQR8/c1LTsJwpB/ILD72IOuRk6zSvZv+ApWCekwVgds ryUDXfvtqUHm81fWkQB/DT4CJE1W4hMdcCOvsULekuW/B7xfQ5lglGx3X5Bxj Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0D3.0000000061D090ED.00002FE6; Sat, 01 Jan 2022 18:35:41 +0100 To: emailcore@ietf.org References: From: Alessandro Vesely Message-ID: Date: Sat, 1 Jan 2022 18:35:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] 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: Sat, 01 Jan 2022 17:35:55 -0000 Happy new year to all participants! On Fri 31/Dec/2021 21:01:40 +0100 John C Klensin wrote: > > (2) Section 2.3.11 says "address normally consists of user and > domain specifications". Given other things we have tightened > up and the submission server cases, "normally" may be a source > of confusion. Should it be dropped or the phrase changed to > "except in the special case of 'postmaster' (Section 2.3.5) an > address consists of user and domain specifications..." ? IMHO Section 2.3.11 is good as is. However, a paragraph recalling that postmaster has to be accepted by the MTA software and its actual mailbox defined as an alias would be a cool improvement. Perhaps, some subsection of Section 3.4 is a better place than 2.3.11 for that. > (4) While Section 5.1 has been fairly significantly overhauled, > it may still be confusing and may need more work. Maybe it's me, but the following sentence seems to be wrong. Its meaning is clear (to me) but the language sounds lacking: If there are no records left at that point, it is an error condition, and a 5yz reply code generated (terminating the mail transaction) or the message MUST be returned as undeliverable. Best Ale -- From nobody Sat Jan 1 13:16: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 DB5BC3A1808 for ; Sat, 1 Jan 2022 13:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yGeLWCoshtJ for ; Sat, 1 Jan 2022 13:16:22 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767CB3A1809 for ; Sat, 1 Jan 2022 13:16:21 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1n3lje-00038V-JC; Sat, 01 Jan 2022 16:16:18 -0500 Date: Sat, 01 Jan 2022 16:16:12 -0500 From: John C Klensin To: Alessandro Vesely , emailcore@ietf.org Message-ID: <4A44B1751CD8AD1E7CB6257A@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] 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: Sat, 01 Jan 2022 21:16:27 -0000 --On Saturday, January 1, 2022 18:35 +0100 Alessandro Vesely wrote: > Happy new year to all participants! Happy new year to you and others too. > On Fri 31/Dec/2021 21:01:40 +0100 John C Klensin wrote: >> >> (2) Section 2.3.11 says "address normally consists of user and >> domain specifications". Given other things we have tightened >> up and the submission server cases, "normally" may be a source >> of confusion. Should it be dropped or the phrase changed to >> "except in the special case of 'postmaster' (Section 2.3.5) an >> address consists of user and domain specifications..." ? > IMHO Section 2.3.11 is good as is. However, a paragraph > recalling that postmaster has to be accepted by the MTA > software and its actual mailbox defined as an alias would be a > cool improvement. Perhaps, some subsection of Section 3.4 is > a better place than 2.3.11 for that. That becomes a question of how often we should say it and when repeating it becomes irritating noise. Section 2.3.5 does mention it, 4.1.1.3 talks about it again, and there is an extended discussion along with an explicit "MUST be supported" in 4.5.1. Personal opinion: if we don't drop "normally", we are covered. If we remove "normally", maybe we should mention the "postmaster" case as I suggested in my note (maybe with additional references to 4.1.1.3 and 4.5.1 but that could also be getting tedious). But going as far as adding a paragraph to 2.3.11 seems repetitive to me. As to 3.4, I was already concerned when I rearranged it that things were creeping in there that don't belong. While one could configure a local system to treat "postmaster" or "postmaster@local-domain.example" as an alias for some local user/administrator or set of them, there is nothing in the spec, and probably should not be, that requires it to treated as anything but the name of a local mailbox. So, if more is needed, not in 3.4. >> (4) While Section 5.1 has been fairly significantly >> overhauled, it may still be confusing and may need more work. > > > Maybe it's me, but the following sentence seems to be wrong. > Its meaning is clear (to me) but the language sounds lacking: > > If there are no records left at that > point, it is an > error condition, and a 5yz reply code generated > (terminating the mail > transaction) or the message MUST be returned as > undeliverable. It was moved from somewhere else and slightly enhanced. The text was awkward in its original form and location, but is, IMO, no worse in the current ones. I considered some alternatives, but they got a lot longer. On the other hand, that might have just been my lack of imagination when I was working on those sections. Suggestions of replacement text welcome. best, john From nobody Sat Jan 1 14:07: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 409E93A18BA for ; Sat, 1 Jan 2022 14:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.45 X-Spam-Level: X-Spam-Status: No, score=-0.45 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=xz3YM27h; dkim=pass (2048-bit key) header.d=taugh.com header.b=2m0tlMBg 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 fJyKf6BD5598 for ; Sat, 1 Jan 2022 14:07:40 -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 CEBD03A18B8 for ; Sat, 1 Jan 2022 14:07:39 -0800 (PST) Received: (qmail 26299 invoked from network); 1 Jan 2022 22:07: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=66b8.61d0d0a8.k2201; bh=/v02awc6b3OD9vsY3+p7PkHKq83pVnhAvuRc4MZADAY=; b=xz3YM27hP2OdW3xydO+osKAR8EvsrnRjlz3aegkuzl7IHHz8oYBJsYSctz8RpUZHHJSCcljq8+y/uPQhdzj6mR9830i0aW8egzTeGKH78pDwxXymFtYVI36V4CRiqn+vFFsjXR37YMm2iErwnvsld6+ezkOQoyw8rJ57KPB4lT/7+/7mV7QscLwUmhiA78IR23o61tCByu/TPv3DgCuLSTwgi5tF3nRaGfuzup1qQg1jKLzNmA/+2drzGUTZAEkSCQkmG2A1kgi4poMQRylQT+JtCr5Vvz+dnUNPztxzkuustqFbgkdSEI2xSO4Oh1jS6uGO/dRLAl9QH7Uwnj+ooQ== 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=66b8.61d0d0a8.k2201; bh=/v02awc6b3OD9vsY3+p7PkHKq83pVnhAvuRc4MZADAY=; b=2m0tlMBgtIaC5Vso0Q75bUYO53MK3bltlCKEggbzlYN1VJhD3MikIsPVx3gRYNzgtmXNb53CUQB5e8H6HKhszEu0u7LMmyDA/ATCf/2QhUW1x4ejQL+Jsl5BomRy0XJDFvH07XrDYSKBpcqcNgZLTa9uo48NYJRz6ftobJvcbMpDsfJYizW2jFZSFM8K0ITYJu03XV5lni9+mXbqgxoZOlm+04Glkl+3WHsRMcN3Nugdk8AWaN5pok9ySF4VaGcAJqKG6v5F8mGDnjQEsMbevpImGnPNNisQAQ2vSDeRIjPt7H33i/0DbXUbyCIjfuLp3tCDSQemqxtAY5E8gemCrg== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 01 Jan 2022 22:07:36 -0000 Received: by ary.qy (Postfix, from userid 501) id 9C40E341A904; Sat, 1 Jan 2022 17:07:35 -0500 (EST) Date: 1 Jan 2022 17:07:35 -0500 Message-Id: <20220101220735.9C40E341A904@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: klensin@jck.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] 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: Sat, 01 Jan 2022 22:07:45 -0000 It appears that John C Klensin said: >(1) This is mostly just a heads-up for people suggesting new >text, but "host name" (with "primary" in front of, whatever that >means, is [still] defined in Section 2.3.5 as "a domain name >that resolves to an address RR". As I have understood it, that >means no labels with CNAME records and no labels with only MX >and no A RRs. I fear that the least bad thing we can do is to leave host names alone and say you can in principle send mail to any LDH domain that has an address or MX or a CNAME that resolves to one. This does not make me happy but I can't think of any alternatives that don't make me even less happy. >Section 2.3.5 clearly says "one or more components" and then >goes on to say > "This makes the requirement, described in more detail > below, that only fully-qualified domain names appear in > SMTP transactions on the public Internet, particularly > important where top-level domains are involved." > >but does not spell out any issues with those names -- the >sentence was apparently intended to avoid a historical problem >in which single-label FQDNs have been confused with abbreviated >names Yeah, that was the .CS problem (which 5321bis no longer addresses). They have also, IIR, >caused considerable discussion within ICANN as to whether they >should be permitted in the root. No contracted TLDs have an A or MX and I am pretty sure that none of them are asking for an exception. As we reported eight years ago in RFC 7085, a fair number of ccTLDs do have an A or an MX but as far as I can tell none of them actually accept mail except perhaps .AI for the address n@ai. Some are just strange, notably that .GT and .TT had MX's pointed at Gmail for nearly a decade, without as far as I can tell ever asking Google if that was a good idea. Can 5321bis just say that the domain must always be a FQDN and an applicability statement say that single-component domains don't work reliably in mail addresses? R's, John From nobody Sat Jan 1 14:39:37 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 D1F7C3A190C for ; Sat, 1 Jan 2022 14:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tstEIIlUZJs for ; Sat, 1 Jan 2022 14:39:31 -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 D3AEA3A190B for ; Sat, 1 Jan 2022 14:39:29 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1n3n28-0003DB-Cu; Sat, 01 Jan 2022 17:39:28 -0500 Date: Sat, 01 Jan 2022 17:39:22 -0500 From: John C Klensin To: John Levine , emailcore@ietf.org Message-ID: <3B7DB783DF2F43E918CA9AAA@PSB> In-Reply-To: <20220101220735.9C40E341A904@ary.qy> References: <20220101220735.9C40E341A904@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] 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: Sat, 01 Jan 2022 22:39:36 -0000 --On Saturday, January 1, 2022 17:07 -0500 John Levine wrote: > It appears that John C Klensin said: >> (1) This is mostly just a heads-up for people suggesting new >> text, but "host name" (with "primary" in front of, whatever >> that means, is [still] defined in Section 2.3.5 as "a domain >> name that resolves to an address RR". As I have understood >> it, that means no labels with CNAME records and no labels >> with only MX and no A RRs. > > I fear that the least bad thing we can do is to leave host > names alone and say you can in principle send mail to any LDH > domain that has an address or MX or a CNAME that resolves to > one. This does not make me happy but I can't think of any > alternatives that don't make me even less happy. AFAICT, that is what the spec says now, the little peculiarity that seems to ban single-label names notwithstanding. >> Section 2.3.5 clearly says "one or more components" and then >> goes on to say >> "This makes the requirement, described in more detail >> below, that only fully-qualified domain names appear in >> SMTP transactions on the public Internet, particularly >> important where top-level domains are involved." >> >> but does not spell out any issues with those names -- the >> sentence was apparently intended to avoid a historical problem >> in which single-label FQDNs have been confused with >> abbreviated names > > Yeah, that was the .CS problem Not quite. The CS problem, at least as I saw it play out, had to do with abbreviating tom.cs.univ.edu, dick.cs.univ.edu, etc., as "tom.cs" and "dick.cs" to distinguish them from tom.phy.univ.edu and dick.math.univ.edu. When "CS" became a valid TLD, the systems within that university that were calmly mapping tom.cs to tom.cs.univ.edu prevented access to, e.g., jakub.cs. >> (which 5321bis no longer addresses). They have also, IIR, >> caused considerable discussion within ICANN as to whether they >> should be permitted in the root. > > No contracted TLDs have an A or MX and I am pretty sure that > none of them are asking for an exception. As we reported > eight years ago in RFC 7085, a fair number of ccTLDs do have > an A or an MX but as far as I can tell none of them actually > accept mail except perhaps .AI for the address n@ai. Some are > just strange, notably that .GT and .TT had MX's pointed at > Gmail for nearly a decade, without as far as I can tell ever > asking Google if that was a good idea. > > Can 5321bis just say that the domain must always be a FQDN and > an applicability statement say that single-component domains > don't work reliably in mail addresses? 5321bis says that now. And I agree that the A/S the right place to address "don't work reliably". thanks, john From nobody Thu Jan 6 12:29: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 6FCDB3A1607 for ; Thu, 6 Jan 2022 12:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAnMmjoc1a8C for ; Thu, 6 Jan 2022 12:29:11 -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 2AA183A1604 for ; Thu, 6 Jan 2022 12:29:10 -0800 (PST) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id 266CF16057; Thu, 6 Jan 2022 21:29:03 +0100 (CET) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id D42C72B60; Thu, 6 Jan 2022 21:29:00 +0100 (CET) Date: Thu, 06 Jan 2022 21:29:00 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: emailcore@ietf.org Message-ID: <20220106202900.brX3K%steffen@sdaoden.eu> Mail-Followup-To: emailcore@ietf.org User-Agent: s-nail v14.9.23-206-gfff8ce373d 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: [Emailcore] Status of Greylisting (i'd wish MessageID were part of SMTP prologue) 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, 06 Jan 2022 20:29:13 -0000 Hello. It is not only IPv6, it also cloud services. And it is that ever changing TTL in times of DNS responsibility indirection a.k.a. content delivery. Worse, if i bypass my local DNS cache and for example say "dig XXX @8.8.8.8" then for the same host i do get the same IP, but the TTL is 159, 208, 134. These rotations surely have an impact on RFC 6647, 5., 1. Implement greylisting based on a tuple consisting of (IP address, RFC5321.MailFrom, and the first RFC5321.RcptTo). that was not forseeable to this extent in 2012? It seems greylisting now mask /8 for IPv4 and /64 for IPv6. It seems to me when generating X different messages in the delay/retry time frame Y, the message X+1 "unlocks" sent before. As i am in the process of writing a greylisting policy server (for postfix policy protocol) i wonder how future proof this can be, without adding more identification tokens to early stages of the SMTP protocol? With the caveat that i (am) personally (not an administrator and) sit in a small corner of the internet with only a *very* limited view onto the overall SMTP traffic. How useful is greylisting on overall and/or on this scale today, and tomorrow? --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 Thu Jan 6 12:58: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 0798D3A166C for ; Thu, 6 Jan 2022 12:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVG-y4B8dJRP for ; Thu, 6 Jan 2022 12:58:52 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E063A166A for ; Thu, 6 Jan 2022 12:58:51 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1n5ZqT-000E2w-FO; Thu, 06 Jan 2022 15:58:49 -0500 Date: Thu, 06 Jan 2022 15:58:43 -0500 From: John C Klensin To: Steffen Nurpmeso , emailcore@ietf.org Message-ID: <001C904B1B67B2632182BF8D@PSB> In-Reply-To: <20220106202900.brX3K%steffen@sdaoden.eu> References: <20220106202900.brX3K%steffen@sdaoden.eu> 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] Status of Greylisting (i'd wish MessageID were part of SMTP prologue) 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, 06 Jan 2022 20:58:56 -0000 --On Thursday, January 6, 2022 21:29 +0100 Steffen Nurpmeso wrote: > Hello. > > It is not only IPv6, it also cloud services. > And it is that ever changing TTL in times of DNS responsibility > indirection a.k.a. content delivery. Worse, if i bypass my > local DNS cache and for example say "dig XXX @8.8.8.8" then > for the same host i do get the same IP, but the TTL is 159, > 208, 134. These rotations surely have an impact on RFC 6647, > 5., > > 1. Implement greylisting based on a tuple consisting of > (IP address, RFC5321.MailFrom, and the first > RFC5321.RcptTo). > > that was not forseeable to this extent in 2012? > It seems greylisting now mask /8 for IPv4 and /64 for IPv6. > It seems to me when generating X different messages in the > delay/retry time frame Y, the message X+1 "unlocks" sent > before. > > As i am in the process of writing a greylisting policy server > (for postfix policy protocol) i wonder how future proof this > can be, without adding more identification tokens to early > stages of the SMTP protocol? > With the caveat that i (am) personally (not an administrator > and) sit in a small corner of the internet with only a *very* > limited view onto the overall SMTP traffic. How useful is > greylisting on overall and/or on this scale today, and > tomorrow? Steffen, Am I correct to suggest that this is a topic for either a 6647bis or for comments on the subject in the developing EMAILCORE A/S that might update 6647bis -- neither of which is obviously in scope with this WG at the moment-- and not something you believe should be addressed in 5321bis? thanks, john From nobody Thu Jan 6 14:07: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 67F5C3A00AE for ; Thu, 6 Jan 2022 14:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Njt8lTQ6; dkim=pass (2048-bit key) header.d=taugh.com header.b=2Jm/8p/4 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 5WF7TfmcNTai for ; Thu, 6 Jan 2022 14:07:03 -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 8B9D33A00AF for ; Thu, 6 Jan 2022 14:07:03 -0800 (PST) Received: (qmail 93504 invoked from network); 6 Jan 2022 22:07:00 -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=16d3d.61d76804.k2201; bh=PLhBIeRPgVBJ5PAh02tpFLNOx3cvvL4Knaql3vRfeaA=; b=Njt8lTQ6tvDm8SDQDDzIKI0fJBGgfya55R1v0cm6jKCC/9CJkfevDbqbYJfAt3n5YFFaf0xkG76MbZ8lMA6JkBzgF4Btk2glGzD34q6Ve2mAao9InaavkpzwXuH3mmuBKz2TRTrIfHf9YVAqKw2FBobW7KZg2lk7peO7dFNDCtSU5MFv3ssZErt+H8NPECksc4AO2VStIWpaUONg4wZ6Mjyg/vSvaKJ7yuqhXtuN5kSfFqHFPpjSrjzeMlcrdBuat1Ik1ttckofj7jEx8s7GrON1pP1psWCpcM6fIDo1KRuNrj5OUdf6G3FxasxTgE3g1Mqn6whdM9KQRc50KcU7yQ== 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=16d3d.61d76804.k2201; bh=PLhBIeRPgVBJ5PAh02tpFLNOx3cvvL4Knaql3vRfeaA=; b=2Jm/8p/4nhTHH+SXlzntQrJihthpO1rrFsW6uOChHhC1PCYdj66NOxNYw4bvtIn5qg/97zAPobcSlizS5LK6g/wAV4xV0mhcvgyqBi5PPXpKhErx0WefJ7ebqfsgDjcQABOdW2scEqKoTeT1LQqOnrFokDfm6ld58A6QZeDyMTS1P5ZJz266tKWhjyHLjjLmLFcdcb5GQ74YhlaQYWJcxv9B+CbiZdbFGE/r5MhMQGiJjIv3zo9OQQ1V7/DlNtLLPbxt5OJBt0zz2tafMWCdPP9g3m3ILhN1tJsprUqRQbck/fI8y297UuTRmaXsMNx+lBKwY/63HyRKvilM4p8VpQ== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 06 Jan 2022 22:06:59 -0000 Received: by ary.qy (Postfix, from userid 501) id 70ABD345A0EF; Thu, 6 Jan 2022 17:06:59 -0500 (EST) Date: 6 Jan 2022 17:06:59 -0500 Message-Id: <20220106220659.70ABD345A0EF@ary.qy> From: "John Levine" Reply-To: ietf-smtp@ietf.org To: emailcore@ietf.org, ietf-smtp@ietf.org In-Reply-To: <20220106202900.brX3K%steffen@sdaoden.eu> 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] Status of Greylisting (i'd wish MessageID were part of SMTP prologue) 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, 06 Jan 2022 22:07:09 -0000 It appears that Steffen Nurpmeso said: >These rotations surely have an impact on RFC 6647, 5., > > 1. Implement greylisting based on a tuple consisting of (IP address, > RFC5321.MailFrom, and the first RFC5321.RcptTo). > >that was not forseeable to this extent in 2012? Item 5 in section 5 says: To accommodate those senders that have clusters of outgoing mail servers, greylisting servers MAY track CIDR blocks of a size of its own choosing, such as /24, rather than the full IPv4 address. (Note, however, that this heuristic will not work for clusters having machines on different networks.) A similar grouping capability MAY be established based on the domain name of the mail server if one can be determined. Is this the problem you are encountering or something else? In my experience, allowing matches within a /24 in IPv4 or a /64 in IPv6 largely addresses this problem. >How useful is greylisting on >overall and/or on this scale today, and tomorrow? My small system recently greylisted 21238 sending hosts of which 12745 retried and 8770 didn't. Once a host retries, it isn't greylisted again unless it hasn't sent any mail for over a month. Spot checks show that the 40% of hosts that don't retry are almost all spambots, so it's useful, but not so much we'd change the protocol. Apropos jck's question, while we might consider revising 6447, this has nothing to do with 5321 so replies are directed to the ietf-smtp list. R's, John From nobody Thu Jan 6 15:23:09 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 833CF3A073E for ; Thu, 6 Jan 2022 15:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKDe-nFvDQ1D for ; Thu, 6 Jan 2022 15:23:03 -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 039893A067B for ; Thu, 6 Jan 2022 15:23:02 -0800 (PST) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id 5FC3716057; Fri, 7 Jan 2022 00:22:58 +0100 (CET) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 203572B67; Fri, 7 Jan 2022 00:22:54 +0100 (CET) Date: Fri, 07 Jan 2022 00:22:54 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: John C Klensin Cc: emailcore@ietf.org Message-ID: <20220106232254.0y1Oz%steffen@sdaoden.eu> In-Reply-To: <001C904B1B67B2632182BF8D@PSB> References: <20220106202900.brX3K%steffen@sdaoden.eu> <001C904B1B67B2632182BF8D@PSB> Mail-Followup-To: John C Klensin , emailcore@ietf.org User-Agent: s-nail v14.9.23-206-gfff8ce373d 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] Status of Greylisting (i'd wish MessageID were part of SMTP prologue) 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, 06 Jan 2022 23:23:09 -0000 John C Klensin wrote in <001C904B1B67B2632182BF8D@PSB>: |--On Thursday, January 6, 2022 21:29 +0100 Steffen Nurpmeso | wrote: .. |> 208, 134. These rotations surely have an impact on RFC 6647, |> 5., ... |Steffen, | |Am I correct to suggest that this is a topic for either a |6647bis or for comments on the subject in the developing |EMAILCORE A/S that might update 6647bis -- neither of which is |obviously in scope with this WG at the moment-- and not |something you believe should be addressed in 5321bis? I well heared the respect from everyone that you managed to publish draft 8 with all the formal bells and whistles that IETF imposes before new year's eve, i am too much living on a sideshow to have even considered to say "Congratulations" or "Thank you" (though especially the latter would really be due). (It was just that idea to "throw a problem into a forum".) --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 Fri Jan 7 12:45: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 1A95A3A1491 for ; Fri, 7 Jan 2022 12:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 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.714, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=thedave.ca header.b=z13zFkQ0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=B++P44GE 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 AfFfy6-Effr5 for ; Fri, 7 Jan 2022 12:45:28 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919313A148F for ; Fri, 7 Jan 2022 12:45:28 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id D7F623201F80 for ; Fri, 7 Jan 2022 15:45:25 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Fri, 07 Jan 2022 15:45:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thedave.ca; h= message-id:date:mime-version:subject:to:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm2; bh=m iYmdPNz3SsKTQkrpjdlJMFjFe0qDtfuat0ArZ6bkSw=; b=z13zFkQ0B08JEmMCz NkFqzocPC+n9IyO96lNVXm33Uh65Q/wJ+zHOdunn7O/JD3xOsbp4i0UyWOdiZIDP oixpbiM40OusCuJRr8e0SyA6O08+t8vQbtJBgbwSHLImh4t/oagNuHWWZ0kniGVw EzWYpSj0NGy+koWTZfpsHlQIW5mdGTpg/p4G2TXImN53AdH39lSpJPPtOy52ZsJn NoabMxrdl+r2b0w6C8nBZcjuex0TfunVWr2WIMluFtyrLwOH/VGPT9QTPKsdrE08 a1X8BQrueIJ9fs1eJ/mkHro7lrHtaYW/78yjN12BIPy7Ogup1J+W9XJM6e8rjL32 5muuQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=miYmdPNz3SsKTQkrpjdlJMFjFe0qDtfuat0ArZ6bk Sw=; b=B++P44GE2dVk6jYCDN8Wlah7lQzP/Ql03eBM/iUlpQcgsg4hOb04RKasb iVKTvj5IfsR7WVgv2nfI5Rv95nhl3ecdPacOB3yjC5o3qQOpk8OD4a0ANKf63RUk JdkNDvzPlZwtYR4DURldArvziZyFR2kdIng8l2u6mK71b3qA5Rq8MTUHqhTWTlXa Pq1/TmhBuw39zpxrb2vBy4EqVNZdKd83pNSE9lMEUCPEVuKbk0+yOGE6xpndCWT7 t0luvHjdWtDkJporsY4P+YYh0y6tTjHyNPfd8l8Rh0RsuYXo+QL4cPnkbfqEtKQp p4CHYG08YHTWfrSRwW/Lqom+/eanw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudegvddgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvfhfhjggtgfesth ejredttdefjeenucfhrhhomhepffgrvhgvucghrghrrhgvnhcuoegufiesthhhvggurghv vgdrtggrqeenucggtffrrghtthgvrhhnpeefffffffevhfeguedugeejheffkedvuddtke egueevgeevheeufeeiveeludegudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpegufiesthhhvggurghvvgdrtggr X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 7 Jan 2022 15:45:24 -0500 (EST) Message-ID: Date: Fri, 7 Jan 2022 13:45:23 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Thunderbird/96.0 Content-Language: en-US To: emailcore@ietf.org References: <20220106220659.70ABD345A0EF@ary.qy> From: Dave Warren In-Reply-To: <20220106220659.70ABD345A0EF@ary.qy> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Status of Greylisting (i'd wish MessageID were part of SMTP prologue) 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, 07 Jan 2022 20:45:33 -0000 On 2022-01-06 15:06, John Levine wrote: > It appears that Steffen Nurpmeso said: >> These rotations surely have an impact on RFC 6647, 5., >> >> 1. Implement greylisting based on a tuple consisting of (IP address, >> RFC5321.MailFrom, and the first RFC5321.RcptTo). >> >> that was not forseeable to this extent in 2012? > Item 5 in section 5 says: > > To accommodate those senders that have clusters of outgoing mail > servers, greylisting servers MAY track CIDR blocks of a size of > its own choosing, such as /24, rather than the full IPv4 address. > (Note, however, that this heuristic will not work for clusters > having machines on different networks.) A similar grouping > capability MAY be established based on the domain name of the > mail server if one can be determined. > > Is this the problem you are encountering or something else? > > In my experience, allowing matches within a /24 in IPv4 or a /64 > in IPv6 largely addresses this problem. > In my experience, SPF is really useful too as you can treat multiple delivery attempts that achieve a SPF:PASS to be identical, such that I don't have to care whether the sender uses a cluster across multiple IP Addresses. This would seem to be a handy way to identify a "similar grouping capability" for senders that use SPF without manual effort. From nobody Thu Jan 13 07:48:38 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 791453A1401 for ; Thu, 13 Jan 2022 07:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 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.714, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=JlOwhpI3; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=nvHRfTBf 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 8MiFLmgQzWHF for ; Thu, 13 Jan 2022 07:48:31 -0800 (PST) Received: from mail.winserver.com (ntbbs.winserver.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E823A112D for ; Thu, 13 Jan 2022 07:48:31 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2495; t=1642088906; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=gf7fPdxPySzObDAZ4IxRmNot67SN UB8K+nVrMsc/4Iw=; b=JlOwhpI3CzAMbUDFbrwwzp18jkrafPVDbIY4CyjNRkQn g64+xp679pOFO13RT8T9wXEYTVNHe2AcHZ/hmH0HEiM2/crKcx+ANFGCG2NxvFKW pOmo3vLC3d7QqV53EC5kvcdZ5h2BJnc+ivcsMm8bROB27zOM/IhVsetN4Yk2+Gk= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.12) for emailcore@ietf.org; Thu, 13 Jan 2022 10:48:26 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.12) with ESMTP id 2886330688.1.464; Thu, 13 Jan 2022 10:48:26 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2495; t=1642088713; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=gf7fPdx PySzObDAZ4IxRmNot67SNUB8K+nVrMsc/4Iw=; b=nvHRfTBfNjdoQ+fDIvioZs3 Kmna71F3nz/t4IKJz0weJTPOSfK4IwREcKqdQtDOGl4Cxd8V/boCkLClA5k/Xo4o Mie0y2420UtQmjlh8eIF5BtxFXmRHNVr/IBwyL/d6zHExjiS61QxNPPNTCFctOSz hbQfatDPVwfW01XrSHKQ= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.12) for emailcore@ietf.org; Thu, 13 Jan 2022 10:45:13 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.12) with ESMTP id 3137129641.1.35076; Thu, 13 Jan 2022 10:45:12 -0500 Message-ID: <61E049C9.3070906@isdg.net> Date: Thu, 13 Jan 2022 10:48:25 -0500 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: emailcore@ietf.org References: <20220106202900.brX3K%steffen@sdaoden.eu> <001C904B1B67B2632182BF8D@PSB> In-Reply-To: <001C904B1B67B2632182BF8D@PSB> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Status of Greylisting (i'd wish MessageID were part of SMTP prologue) 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, 13 Jan 2022 15:48:36 -0000 On 1/6/2022 3:58 PM, John C Klensin wrote: > > Steffen, > > Am I correct to suggest that this is a topic for either a > 6647bis or for comments on the subject in the developing > EMAILCORE A/S that might update 6647bis -- neither of which is > obviously in scope with this WG at the moment-- and not > something you believe should be addressed in 5321bis? > From a technical standpoint, RFC5321bis should take into account basic implementation considerations used in the "pseudo-standard" greylist protocol that are at least 19+ years old showing two essential SMTP ideas: - Timely delivery with minimal delays, - Meaningful structured retry responses to advance intelligent SMTP clients. The draft SMTP GreyList extension addresses these two basic SMTP advancement ideas: https://tools.ietf.org/id/draft-santos-smtpgrey-02.html GREYLIST is a SMTP extension to formalize the widely supported Greylisting mail filtering method and to help support SMTP rejected transports by following a new formal structured 4yz server temporary rejection response by including a "retry=time-delay" tag string which SMTP clients can use to optimize the rescheduling of the mail delivery attempts. With adoption, network overhead reduction in wasteful mail delivery attempts will be realized. Perhaps updating RFC5321bis examples showing real responses that exist in the market that include include "Retry Hints" as outlined in the draft. There is running code that use the GreyList SMTP Extension retry hints. Note: The informational RFC6647 was being drafted at the time the SMTP GreyList extension draft was being written. I took it as a rebuttal against my greylisting work and in fact, it provided an opinion (without any stats to back it up) that "Retry Hints" presented a security risk to DoS attacks. There was no evidence of this then, nor is there any evidence of this today. But the damage was done for any further IETF work for the proposed SMTP extension to help formalized Greylisting. All responsible systems, regardless of GreyListing, is already handling DoS attacks in some secured fashion. Whether the improved RFC5321bis "SMTP Handbook" should codify important modern SMTP transport implementation ideas used in practice, I leave to others to decide. I do agree, 100%, RFC6647bis should remove its guidance against structured Greylist reply text. -- Hector Santos, https://winserver.com/public/spamstats.wct From nobody Sat Jan 15 06:17:58 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 7D6D43A143D for ; Sat, 15 Jan 2022 06:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQJdvW7AEfxB for ; Sat, 15 Jan 2022 06:17:53 -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 53B0E3A143C for ; Sat, 15 Jan 2022 06:17:52 -0800 (PST) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id B98B916059; Sat, 15 Jan 2022 15:17:48 +0100 (CET) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 860D52E0F; Sat, 15 Jan 2022 15:17:47 +0100 (CET) Date: Sat, 15 Jan 2022 15:17:47 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: emailcore@ietf.org Message-ID: <20220115141747.TCQwU%steffen@sdaoden.eu> In-Reply-To: <61E049C9.3070906@isdg.net> References: <20220106202900.brX3K%steffen@sdaoden.eu> <001C904B1B67B2632182BF8D@PSB> <61E049C9.3070906@isdg.net> Mail-Followup-To: emailcore@ietf.org User-Agent: s-nail v14.9.23-217-g95280174f9 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] Status of Greylisting (i'd wish MessageID were part of SMTP prologue) 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, 15 Jan 2022 14:17:57 -0000 Hello. Sorry for the late reply, i wanted to read the draft first. (The thread continued on ietf-smtp@ due to request.) Hector Santos wrote in <61E049C9.3070906@isdg.net>: |On 1/6/2022 3:58 PM, John C Klensin wrote: |> Am I correct to suggest that this is a topic for either a |> 6647bis or for comments on the subject in the developing |> EMAILCORE A/S that might update 6647bis -- neither of which is |> obviously in scope with this WG at the moment-- and not |> something you believe should be addressed in 5321bis? | | From a technical standpoint, RFC5321bis should take into account |basic implementation considerations used in the "pseudo-standard" |greylist protocol that are at least 19+ years old showing two |essential SMTP ideas: | |- Timely delivery with minimal delays, |- Meaningful structured retry responses to advance intelligent SMTP |clients. | |The draft SMTP GreyList extension addresses these two basic SMTP |advancement ideas: | | https://tools.ietf.org/id/draft-santos-smtpgrey-02.html I think the idea of a retry=[MIN:]SEC member in the deferral response is interesting, even though i do not know how MTAs manage their queues .. but likely they could adapt to this easily. It could be used to avoid useless traffic, which in today's greylisting practice as i experience it happens, even multiple times, before the message gets through. | GREYLIST is a SMTP extension to formalize the widely supported | Greylisting mail filtering method and to help support SMTP rejected | transports by following a new formal structured 4yz server temporary | rejection response by including a "retry=time-delay" tag string which | SMTP clients can use to optimize the rescheduling of the mail | delivery attempts. With adoption, network overhead reduction in | wasteful mail delivery attempts will be realized. | |Perhaps updating RFC5321bis examples showing real responses that exist |in the market that include include "Retry Hints" as outlined in the |draft. | |There is running code that use the GreyList SMTP Extension retry hints. | |Note: The informational RFC6647 was being drafted at the time the SMTP |GreyList extension draft was being written. I took it as a rebuttal |against my greylisting work and in fact, it provided an opinion |(without any stats to back it up) that "Retry Hints" presented a |security risk to DoS attacks. There was no evidence of this then, nor |is there any evidence of this today. But the damage was done for any |further IETF work for the proposed SMTP extension to help formalized |Greylisting. All responsible systems, regardless of GreyListing, is |already handling DoS attacks in some secured fashion. | |Whether the improved RFC5321bis "SMTP Handbook" should codify |important modern SMTP transport implementation ideas used in practice, |I leave to others to decide. | |I do agree, 100%, RFC6647bis should remove its guidance against |structured Greylist reply text. --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 Jan 15 10:27: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 2C3A93A08FD; Sat, 15 Jan 2022 10:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aM9KliyWBqEc; Sat, 15 Jan 2022 10:27: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 40BAD3A08F2; Sat, 15 Jan 2022 10:27:36 -0800 (PST) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id 51B9516059; Sat, 15 Jan 2022 19:27:33 +0100 (CET) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 392CC2E4F; Sat, 15 Jan 2022 19:27:31 +0100 (CET) Date: Sat, 15 Jan 2022 19:27:31 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: ietf-smtp@ietf.org Cc: Emailcore@ietf.org Message-ID: <20220115182731.zIGo-%steffen@sdaoden.eu> In-Reply-To: <20220115180055.E4C0634FF1B1@ary.qy> References: <20220115180055.E4C0634FF1B1@ary.qy> Mail-Followup-To: ietf-smtp@ietf.org, Emailcore@ietf.org User-Agent: s-nail v14.9.23-217-g95280174f9 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] [ietf-smtp] Status of Greylisting (i'd wish MessageID were part of SMTP prologue) 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, 15 Jan 2022 18:27:45 -0000 John Levine wrote in <20220115180055.E4C0634FF1B1@ary.qy>: |It appears that Steffen Nurpmeso said: |>I think the idea of a retry=[MIN:]SEC member in the deferral |>response is interesting, even though i do not know how MTAs manage |>their queues .. but likely they could adapt to this easily. | |This is not a new suggestion, and nobody I know has ever implemented it |other than as small scale experiments. The point of greylisting is to |test the retry logic that every real MTA already has, not to invent |yet another hack on the client side. I think that "Free at last! Free at last!" is still current, yes. |MTAs run their own retry schedules and it would generally not be easy |to have special schedules for specific messages. Well like i said, i do not know. Every MTA needs to have a per-cache-entry notion and likely a per-receiver one, too. It should thus naturally be capable to skip over one or multiple deliveries, if the retry= suggests that it is useless to try earlier. Noone said it must try exactly after the "retry" duration, only that it does not make sense to try earlier. So if that would be implemented, why not? Of course admins may then decide to greylist multiple times nonetheless. And it all does not help to be able to "exactly" identify a message in order to perform real greylisting. --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 Jan 15 12:11: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 555283A11C6 for ; Sat, 15 Jan 2022 12:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, 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 QzOgBu_t9_V3 for ; Sat, 15 Jan 2022 12:11:08 -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 E3F223A11C4 for ; Sat, 15 Jan 2022 12:11:05 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1n8pO8-000Bmi-9p; Sat, 15 Jan 2022 15:11:00 -0500 Date: Sat, 15 Jan 2022 15:10:53 -0500 From: John C Klensin To: Steffen Nurpmeso , emailcore@ietf.org Message-ID: In-Reply-To: <20220115141747.TCQwU%steffen@sdaoden.eu> References: <20220106202900.brX3K%steffen@sdaoden.eu> <001C904B1B67B2632182BF8D@PSB> <61E049C9.3070906@isdg.net> <20220115141747.TCQwU%steffen@sdaoden.eu> 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] New idea postings to this list (was: Re: Status of Greylisting (i'd wish MessageID were part of SMTP prologue)) 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, 15 Jan 2022 20:11:12 -0000 Steffen (and Hector), I don't mean to pick on you and hope this note is not taken as doing that, but... Unless one of you, or someone else, wants to make a strong case for discussing Greylisting in 5321bis (or 5322bis) I hope there are no further discussions on this list. Procedurally, discussing it in either of those documents would require either: * Publishing one or both of them at Proposed Standard, countering the main justification for this WG. or * Pausing the WG's work while an updated, preferably Standards Track, version of RFC 6647 is written, works its way through the system and then, IIR no less that six months after publication, an implementation report is generated that justifies moving it to full standard. Or new specifications, documenting new ideas, are moved through the system on the same basis. I would not feel so strongly about this except that, with a grand total of zero comments on the changes and questions raised in draft-ietf-emailcore-rfc5321bis-08 since it was posted two weeks ago, I am feeling very concerned that, except for discussions on new ideas like these or arguments about document organization, the WG is running out of energy already and, more important, that there may not be sufficient energy to do the comprehensive reviews that Internet Standard Versions of these documents should have. I hope I'm wrong, but would feel a lot better if the WG's mailing list delivered a posting that started "I have carefully read all the way through draft-ietf-emailcore-rfc5321bis-08 and..." Just my opinion of course but I am at the point where I almost wish the co-chairs would treat starting this type of thread or responding to it as disruptive. john --On Saturday, January 15, 2022 15:17 +0100 Steffen Nurpmeso wrote: > Hello. > > Sorry for the late reply, i wanted to read the draft first. > (The thread continued on ietf-smtp@ due to request.) From nobody Wed Jan 19 03:55: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 92B723A1A96 for ; Wed, 19 Jan 2022 03:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTOeEHsd17t6 for ; Wed, 19 Jan 2022 03:54:56 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 673033A1A93 for ; Wed, 19 Jan 2022 03:54:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1642593294; d=isode.com; s=june2016; i=@isode.com; bh=yIvTOlby7ZWxved/ZpaHzfWcP93U1QXf8A1IKXsyAiM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=rizs0jvrygf+9sBaVf6Gj0FtYNgs+Zmsod6diDHTyp8rPW9mAT1awoVCdkXYpReZjhQtx0 OnfRrMmS3KHVGmCpUo6Zc6ow9wxirRXk0TiQvqQ4Iydxbzzrih8MtDeDQoSeaQKYEmFWVs IHV9r+40lb6iS6o7NWIIDBHCRObb0UY=; Received: from [192.168.1.222] (host31-49-219-36.range31-49.btcentralplus.com [31.49.219.36]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 19 Jan 2022 11:54:54 +0000 Message-ID: Date: Wed, 19 Jan 2022 11:54:53 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 To: emailcore@ietf.org From: Alexey Melnikov MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] Agenda for the EMAILCORE interim this Friday (January 21st) 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, 19 Jan 2022 11:55:01 -0000 Dear WG participants, EMAILCORE chairs are hoping to see you attending our next interim this Friday, at 5pm UTC. Below is our proposed agenda with some comments: > #17 (Deprecated Source Routes) > https://trac.ietf.org/trac/emailcore/ticket/17 John did a good job cleaning this up. There are only some minor questions remaining about strength of some requirements in the new Appendix F.2. Please review the new Appendix F.2 and be ready to discuss: https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis-08#appendix-F.2 > > #9 (G.7.3. Definition of domain name in Section 2.3.5) > https://trac.ietf.org/trac/emailcore/ticket/9 Again, I believe John made some good cleanup of this text, but there are a couple of minor remaining issues related to text about alises (moved from Section 5) and whether DNS resolvability need to be mentioned in Section 2.3.5 > > #4 (Exploders seem to be prohibited from adding List-* header fields) > https://trac.ietf.org/trac/emailcore/ticket/4 We started discussing this at the last interim, but didn't have enough time to make progress on this. I am hoping we can resolve this one. > > #1 (G.1 IP address literals in EHLO) > https://trac.ietf.org/trac/emailcore/ticket/1 > > #47 (Accepting Messages based on EHLO Argument) > https://trac.ietf.org/trac/emailcore/ticket/47 The above 2 tickets were addressed in rfc5321bis, but some text in the Applicability Statement needs confirmation/closure. > > #54 (G.7.17 Hop-by-hop Authentication and/or Encryption) > https://trac.ietf.org/trac/emailcore/ticket/54 This ticket is now about text in the Applicability Statement. Todd will post a separate message on this. > #16 (Review Timeout Specifications) > https://trac.ietf.org/trac/emailcore/ticket/16 Trying to get closure on the old ticket. This is about new text proposed for the Applicability Statement. Todd will post a separate message on this. > #12 (G.7.5. Improve description/definition of mailing lists, aliases, > and forwarding) > https://trac.ietf.org/trac/emailcore/ticket/12 > > #3 (G.3. Meaning of "MTA" and Related Terminolog) > https://trac.ietf.org/trac/emailcore/ticket/3 Discussion about these started at the last interim meeting, but we didn't have time to make significant progress on these. Hopefully we can progress these tickets further this time. Best Regards, Alexey From nobody Wed Jan 19 05:37:10 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 8EB093A1DD1 for ; Wed, 19 Jan 2022 05:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.612 X-Spam-Level: X-Spam-Status: No, score=0.612 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, 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 4YdA_wE106Au for ; Wed, 19 Jan 2022 05:37:03 -0800 (PST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 8FE093A1DD8 for ; Wed, 19 Jan 2022 05:37:03 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id o135so2653579qke.8 for ; Wed, 19 Jan 2022 05:37:03 -0800 (PST) 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=5Qjjf95VFLS33cVkZLUbE3dH3EqJL5AYQQEHepwpCbg=; b=asWdFVLMcNMKR+YdxGmG5mj/Syc0pqKzIATBBrUJZrdq5UwymcW9jz/NFCfvG3qr3I mEYetIpL5Au/kEDhMKZwVVWXfAUxuDhtMjgpv4LKCbjGt4IIbuPlQc8wOdv/jmE+KNra JaOx+xOjzQNReOvbdpuXXosvg/WVIsR7reNW2dZPbi2eE4qtQfnHz1MgqlW/BGqqXUy9 gAiIcIj8FMNb4rFnPjdztGB7rd8UNlgGXAzVTJdFptaXfRbNRcyqgen/fQNAygl4v5v7 a0mOyvfpckoyMXXydxHcMhrLPQwT+g2kEmCvlxKGi1wf778aVk9X/+LUTMHfysgVJDN6 BfHQ== 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=5Qjjf95VFLS33cVkZLUbE3dH3EqJL5AYQQEHepwpCbg=; b=d8gNCMzoT5saOqB9DZO+Bm/CvqlsJ9HIzmKA7BTV1VUw5+WxokrQvDBGVbOJ2C/r9i G8yQEgNkOtQ0AtujC5YacPlX5oVcoel+RH60+qJERBJA9p0OhHxFuaTQ488pAm6qrmlT zlKCYCOIClI0kxyP8rQWnxZYFKzU9HhG7pAJRscsKzoG1j71CivlbWt9QM2CPaQhs+Oa oZKQLQho72mJ/q9gVlCp4ewyEUb/COr2xPAGM4EF3SX5eL5BCj+H32Qm8RwDWIFdUe46 n7c1owzcqMQPK4OxGm4sBYh3T/k0zHS62wTR2HqWT4ElNvUN8WKunEI33GAeqYrpVOUQ /utQ== X-Gm-Message-State: AOAM530F93Wi86HZBYP0rP8Js0MmtHjn8Rnq6GVwtGw5CQJF2ImbVb/6 swVo5Dw9rHgmPxl5Pl/VY1FJbCPMJfKCCZJJBSK8yCnWKqdKuw== X-Google-Smtp-Source: ABdhPJyRV9HSgFsRgMaPQjlDFaDpmfK9dkN2UMzslWsxkxHAL2HI0CdVRAKoZCLUzEYDD5CYDXhk4tjC9tAFabxSi4k= X-Received: by 2002:ae9:c110:: with SMTP id z16mr14132076qki.396.1642599421465; Wed, 19 Jan 2022 05:37:01 -0800 (PST) MIME-Version: 1.0 From: Todd Herr Date: Wed, 19 Jan 2022 08:36:45 -0500 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000066e2805d5ef7b37" Archived-At: Subject: [Emailcore] Ticket #54 - Proposed Text for Applicability Statement 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, 19 Jan 2022 13:37:09 -0000 --000000000000066e2805d5ef7b37 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Greetings. Alexey mentioned in a separate message that I would be posting proposed text for the subject ticket. This is that posting. The ticket is ticket number 54 - https://trac.ietf.org/trac/emailcore/ticket/54 The ticket description reads: Should this document discuss hop-by-hop authentication or, for that matter, encryption? and there is a suggestion that such discussion be done in the Applicability Statement. Here is an initial proposal for text for the Applicability Statement to discuss these topics. =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= =3D=3D=3D 5. Hop-by-hop Authentication and Its Implications Two 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, but users and implementers of SMTP should be aware of them and most critically of the fact that both SPF and DKIM verification checks can produce different results when a message transits multiple hops vice when it goes directly from the sender to the destination, specifically =E2=80=9CFAIL=E2=80=9D res= ults. These unanticipated failures can and do affect DMARC verification results on some messages, and so domain owners should be aware of this when setting DMARC policy for their domains. As for message receivers, the ARC protocol is one attempt to provide evidence of the results of previous authentication checks, and it=E2=80=99s up to the receiver to decide if they trust the res= ults and how those results might impact message handling at their site. 6. Message Encryption and Its Implications The default method for transmitting text using the SMTP protocol is to do so =E2=80=9Cin the clear=E2=80=9D. Years of operational experience have sho= wn that such transmission exposes the message to easy compromise. To mitigate this risk, solutions have been developed to encrypt the message in transit, either just between servers or through the entire path from sender to message store. This section will touch on these methods and the implications of their use. 6.1 Opportunistic Encryption The most common implementation of message encryption is what=E2=80=99s know= n as =E2=80=9Copportunistic encryption=E2=80=9D. With this method, an SMTP serve= r 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 SMTP client then at= tempts to negotiate an encrypted connection, and if successful, transmits the message in encrypted form; there is no guarantee that the message will be stored in encrypted fashion at its destination, and in fact, storage in plain text should be expected. If negotiation fails, the client falls back to sending the message in clear text. Most modern implementations of SMTP support this method, and so the vast majority of email traffic is encrypted during its time transiting from the client to the server. 6.2 Required Encryption Two protocols exist that move server-to-server encryption beyond =E2=80=9Cn= ice to have=E2=80=9D to =E2=80=9Crequired=E2=80=9D - MTA-STS [RFC8461] and DANE fo= r SMTP [RFC7672]. While they differ in their implementation details, SMTP servers relying on either protocol are stating that they only accept mail if the transmission is encrypted with TLS, and a failure to negotiate a secure connection MUST result in the SMTP client refusing to transmit the message. Support for both protocols is widening, but is not yet mandatory. 6.3 Personal Encryption The more sophisticated among the end users of SMTP may take advantage of various third party solutions that are designed to encrypt their message immediately upon leaving the MUA, and to do so in such a way that only the individual message recipient(s) can decrypt the message. The solutions are too numerous to list here, and debugging any issues that may arise in message transmission is likely to be beyond the scope of any MTA administrator=E2=80=99s work, but they=E2=80=99re nonetheless mentioned her= e for the sake of completeness. =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= =3D=3D=3D Please discuss... --=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. --000000000000066e2805d5ef7b37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings.

Alexey mentioned in a separate message that I = would be posting proposed text for the subject ticket. This is that posting= .

The ticket is ticket number 54 -=C2=A0https://trac.ietf.org/trac/ema= ilcore/ticket/54

The ticket description reads:

Should this docume= nt discuss hop-by-hop authentication or, for that
matter, = encryption?

and there is a suggestio= n that such discussion be done in the Applicability Statement.=C2=A0
<= div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif">
Her= e is an initial proposal for text for the Applicability Statement to discus= s these topics.

=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=3D=3D=3D

<= span id=3D"gmail-docs-internal-guid-116a1b75-7fff-2f51-530f-dee9191a3347"><= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:12pt">= 5. Hop-by-hop Authentication and Its Imp= lications

Two protocols exist to allow for a= uthentication of different identities associated with an email message - SP= F [RFC7208] and DKIM [RFC6376]. A third protocol, DMARC [RFC7489], relies o= n SPF and DKIM to allow for validation of the domain in the visible From he= ader, and a fourth, ARC [RFC8617], provides a way for each hop to record re= sults of authentication checks performed at that hop.

All of these are outside the scope of this document, but users and= implementers of SMTP should be aware of them and most critically of the fa= ct that both SPF and DKIM verification checks can produce different results= when a message transits multiple hops vice when it goes directly from the = sender to the destination, specifically =E2=80=9CFAIL=E2=80=9D results. The= se unanticipated failures can and do affect DMARC verification results on s= ome messages, and so domain owners should be aware of this when setting DMA= RC policy for their domains. As for message receivers, the ARC protocol is = one attempt to provide evidence of the results of previous authentication c= hecks, and it=E2=80=99s up to the receiver to decide if they trust the resu= lts and how those results might impact message handling at their site.


6. Message Encryption and Its Implications

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:12pt">= The default method for transmitting text using the SMTP = protocol is to do so =E2=80=9Cin the clear=E2=80=9D. Years of operational e= xperience have shown that such transmission exposes the message to easy com= promise. To mitigate this risk, solutions have been developed to encrypt th= e message in transit, either just between servers or through the entire pat= h from sender to message store. This section will touch on these methods an= d the implications of their use.


6.1 Opportunistic = Encryption

The most common implementation of= message encryption is what=E2=80=99s known as =E2=80=9Copportunistic encry= ption=E2=80=9D. With this method, an SMTP 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 SMTP client then attempts to negot= iate an encrypted connection, and if successful, transmits the message in e= ncrypted form; there is no guarantee that the message will be stored in enc= rypted fashion at its destination, and in fact, storage in plain text shoul= d be expected. If negotiation fails, the client falls back to sending the m= essage in clear text.

Most modern implementat= ions of SMTP support this method, and so the vast majority of email traffic= is encrypted during its time transiting from the client to the server.


6.2 Required Encryption

Two protocols exist that move server-to-server encryption beyond =E2=80=9C= nice to have=E2=80=9D to =E2=80=9Crequired=E2=80=9D - MTA-STS [RFC8461] and= DANE for SMTP [RFC7672]. While they differ in their implementation details= , SMTP servers relying on either protocol are stating that they only accept= mail if the transmission is encrypted with TLS, and a failure to negotiate= a secure connection MUST result in the SMTP client refusing to transmit th= e message. Support for both protocols is widening, but is not yet mandatory= .


6.3 Personal Encryption

The more sophisticated among the end users of SMTP may take advan= tage of various third party solutions that are designed to encrypt their me= ssage immediately upon leaving the MUA, and to do so in such a way that onl= y the individual message recipient(s) can decrypt the message. The solution= s are too numerous to list here, and debugging any issues that may arise in= message transmission is likely to be beyond the scope of any MTA administr= ator=E2=80=99s work, but they=E2=80=99re nonetheless mentioned here for the= sake of completeness.


=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=3D=3D=3D

Please discuss...

--

Todd Herr <= /span> | Technical Director, Standards and Ecosystem
m: 703.220.41= 53

This email and all data transmitted with it contains conf= idential and/or proprietary information intended solely for the use of indi= vidual(s) authorized to receive it. If you are not an intended and authoriz= ed recipient you are hereby notified of any use, disclosure, copying or dis= tribution of the information included in this transmission is prohibited an= d may be unlawful. Please immediately notify the sender by replying to this= email and then delete it from your system.

<= /div> --000000000000066e2805d5ef7b37-- From nobody Wed Jan 19 05:42: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 96B563A1E03 for ; Wed, 19 Jan 2022 05:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, 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 YC2xiC_aUiB3 for ; Wed, 19 Jan 2022 05:42:16 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 786143A1DD0 for ; Wed, 19 Jan 2022 05:42:16 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id t1so2652184qkt.11 for ; Wed, 19 Jan 2022 05:42:16 -0800 (PST) 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=whIw2m4leMkxmo5rlsfyds4+CZn/N7jbAfroApvJA7o=; b=ba6KJ472U5wHLyiDWJ0c7cKh6jvcnycvV5It3r/V6sD+uPcb8y0uXXNBdyi6luVsdm SIVUTnlKqiRB5UoXy0gepL9EqagzdzbkWUZfkq2EzaqXW/WQloO1doPv7bIPdmlYcIAk /+6MZQ4Puze/aGQuaNcdMTrOIGaegKncUoo7BnEHRoGoZAOhxlPFtHAEEXPtZ2nP0x0u wGBxSJgJTVilgYo3NNPAUTZ7pORltV7Pz14CVhxKoFkhjn4ba6GsFdSrjQVXO0OU6hqX E1pbo3cyaUJbqWMzjPzPDfJfpOBcTHdV1OfEmVvH3PnqKeZs9TlyNcGR3HTR+W/h5SpK pKCA== 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=whIw2m4leMkxmo5rlsfyds4+CZn/N7jbAfroApvJA7o=; b=uVgjYNARpW8avedkihEW852MuOPi+sTyUM/UV8SUpheB/T3ijB26djFwPHpQnIHtDz uokY8ALClckrPE+JI1ePy/i4JwmSTvUHTnp4292N5qGbz/npWsB0B/xOPQ3t+EqsmI/E zY1UcjR1zCB8F+iS2WEl82vDiCM/VG4QF63qAFGEEN9BbW46PyNpGXagUdkX5hp5pksc 4TjCkEAGGGgl7vkKXx06HWMnMTvIXLsrTIt6J8YxiIc1+3AJt2HKGZrnmN+qkTdGce7L THKac0786YG6VFhbrUiZMmaLNoO8bp3ApeQRixs1OfSyBSQmOZEQAqwfTJuEjTu5zwsR R/PQ== X-Gm-Message-State: AOAM530db6xYcJcGDrNla4SH5Plis5w2Ek5L4UINRK+PpwvOL0u0P5O6 8v4LNq0Ewub/ohGXnd7RXehpasaKdPr2iTWRTPSf92/dytkegw== X-Google-Smtp-Source: ABdhPJyrQTlj8bPekSa+JZp2TpM3Bt+eO1f7IASnz0UAGJAcpSdQ6LaNmWoSpvrvJjwb5PP/yNg07/XlNKOrQLrcpDU= X-Received: by 2002:ae9:c110:: with SMTP id z16mr14144992qki.396.1642599734673; Wed, 19 Jan 2022 05:42:14 -0800 (PST) MIME-Version: 1.0 From: Todd Herr Date: Wed, 19 Jan 2022 08:41:58 -0500 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000b195a205d5ef8d8f" Archived-At: Subject: [Emailcore] Ticket #16 - Proposed Text for Applicability Statement 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, 19 Jan 2022 13:42:21 -0000 --000000000000b195a205d5ef8d8f Content-Type: text/plain; charset="UTF-8" Greetings. Alexey mentioned in a separate message that I would be posting proposed text for the subject ticket. This is that posting. The ticket is ticket number 16 - https://trac.ietf.org/trac/emailcore/ticket/16 - and the topic is the timeout specifications in RFC 5321, specifically whether or not they might be too generous. Discussion at IETF 110 (https://codimd.ietf.org/notes-ietf-110-emailcore) seemed to land on "Leave 5321 alone, but maybe add something to the Applicability Statement" Here is the initial proposed text for something to add to the Applicability Statement. ===================== cut here ======================== 7. Timeout Specifications The current SMTP specification (5321bis), as well as the two before it (RFC5321 and RFC2821) contain recommendations for minimum timeout values for various operations. Given the age of RFC 2821 (published in April 2001) and advances in networking and computing technology since then, it might seem that these timeout values are far too generous. However, those same advances have been relied on by MTA implementers to add more features and functionality to SMTP transactions. The recommended minimum timeouts are specified as SHOULD, not MUST, and so implementers may choose to use shorter timeouts if operational needs or experience indicate that to be appropriate. ===================== cut here ======================== Please discuss... -- *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. --000000000000b195a205d5ef8d8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings.

=
Alexey= mentioned in a separate message that I would be posting proposed text for = the subject ticket. This is that posting.

The ticket i= s ticket number=C2=A016 -=C2=A0https://trac.ietf.org/trac/emailcore/ticket/16 - and the= topic is the timeout specifications in RFC 5321, specifically=C2=A0whether= or not they might be too generous.

Discussion at IETF 110 (https://= codimd.ietf.org/notes-ietf-110-emailcore) seemed to land on "Leave 5321 alone, but maybe = add something to the Applicability Statement"

Here is the initial proposed text for something t= o add to the Applicability Statement.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D cu= t 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

7. Timeout Specifications

The current SMTP specification (5321bis), as well as= the two before it (RFC5321 and RFC2821) contain recommendations for minimu= m timeout values for various operations. Given the age of RFC 2821 (publish= ed in April 2001) and advances in networking and computing technology since= then, it might seem that these timeout values are far too generous. Howeve= r, those same advances have been relied on by MTA implementers to add more = features and functionality to SMTP transactions.<= br>
The recommended = minimum timeouts are specified as SHOULD, not MUST, and so implementers may= choose to use shorter timeouts if operational needs or experience indicate= that to be appropriate.

=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

Please discuss...
--

Todd Herr | Technical Director, Standards and Ecosyst= em
m: 703.220.4153

This email and all data transmitted w= ith it contains confidential and/or proprietary information intended solely= for the use of individual(s) authorized to receive it. If you are not an i= ntended and authorized recipient you are hereby notified of any use, disclo= sure, copying or distribution of the information included in this transmiss= ion is prohibited and may be unlawful. Please immediately notify the sender= by replying to this email and then delete it from your system.

--000000000000b195a205d5ef8d8f-- From nobody Wed Jan 19 07:46:13 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 823433A10A2 for ; Wed, 19 Jan 2022 07:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=zPkoDPNO; dkim=pass (2048-bit key) header.d=taugh.com header.b=OpoXNatN 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 LAN69080QLKO for ; Wed, 19 Jan 2022 07:46:06 -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 2144E3A10A1 for ; Wed, 19 Jan 2022 07:46:05 -0800 (PST) Received: (qmail 40458 invoked from network); 19 Jan 2022 15:46:03 -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=9e06.61e8323b.k2201; bh=fwabNnLoHUL3/lKplx1ZQIVDg9cHuxKz2c+mb5y6F5I=; b=zPkoDPNO+nUDc9Ste7cyENdQyhhOXqbgti5DVIkx4L2Efz7tlNFgG/cxzdiD/v0GLtllPF6O8N5roW6uXAQAWKW4J+Dedj+uwXUIzSwvH5RIDXqpugVkM9UqlG0h2ZA+16yKFL7riAt5L7HF26bxDI1jKhAT7/3zvLKoDGRpHxhp2pTzyTWM/EMuRcb1FZRJQdtQmv0OYaYiuk2KKUTcbh+ngaF4R9h96ZtmL10PxbgKJSu5B8wdKp8owbQoRYR71L+2zSlbFfDjVMTpQHeWEzXFP8pEUzP/sQ/+VvijNRhyY1k9AKRnZFM7ZOPH/YmHLR0y8s/uF+mB0nK4vW0fFw== 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=9e06.61e8323b.k2201; bh=fwabNnLoHUL3/lKplx1ZQIVDg9cHuxKz2c+mb5y6F5I=; b=OpoXNatNyF9OtE0HYM5mH0tJtu/SG/7i5rpxsXeRQkZUfocweMvM+lNJ4GREKNOzinPOrv6NuxLBTGE9P3YSg3Ns6C5EhgGXM4HLN43/AgmVDVTRd/0L2KZeIV3E8wIcPfDhyBF13fZSCJgppJX0QcC/zLF2sr8CdBKu5N9PKFLQZMqbdXsMbw2CZ3RwJVZuWscWA4b9q9Vr8yhvUi3Se+vYlBLrtZLXS4latr+nowloito7Jv82JaTcNoZQaosUn8a+huxN18WeQZ8EfB41N1AN15DiNpDKhOvhqska9TblKMRBeMS6zoeTEkOuRPNhIkBsjAqWNBG+I2hoHhrfZQ== 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; 19 Jan 2022 15:46:03 -0000 Received: by ary.qy (Postfix, from userid 501) id DAC4C3536EC3; Wed, 19 Jan 2022 10:46:02 -0500 (EST) Date: 19 Jan 2022 10:46:02 -0500 Message-Id: <20220119154602.DAC4C3536EC3@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: todd.herr@valimail.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] Ticket #54 - Proposed Text for Applicability Statement 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, 19 Jan 2022 15:46:12 -0000 It appears that Todd Herr said: >-=-=-=-=-=- > >Greetings. > >Alexey mentioned in a separate message that I would be posting proposed >text for the subject ticket. This is that posting. > >The ticket is ticket number 54 - >https://trac.ietf.org/trac/emailcore/ticket/54 > >The ticket description reads: > >Should this document discuss hop-by-hop authentication or, for that >matter, encryption? DKIM and DMARC are end to end, SPF is hop by hop, but when I think of hop-by-hop authentication and encryption, I think of mta-sts and STARTTLS. R's, John From nobody Wed Jan 19 08:02: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 847B93A12B0 for ; Wed, 19 Jan 2022 08:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.021 X-Spam-Level: X-Spam-Status: No, score=-7.021 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.714, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=VLLJHVr4; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=KKHkkSkt 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 wAdHfEiIgOHW for ; Wed, 19 Jan 2022 08:02:31 -0800 (PST) Received: from mail.winserver.com (unknown [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF67B3A1220 for ; Wed, 19 Jan 2022 08:02:20 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1524; t=1642608132; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=xu+R2d7sQAe33wXVlWJ+lDm1JdrN oUfIJsnyiEJhH04=; b=VLLJHVr4FVhTtAbUE9p8wqF6Q+qcmu+nGPCQxPipyF02 xro53Mj+ULJ37yGmOixW2SPbiEthgDwznjr5W4IBuAsz7rfujSzbpnaA2CiGi9H6 ghd/+yObfqGLIZNHZ+LnEgWcDtlfCVb1QDqrRzaJzFci2Mywc/ogK6ZpfzAXgxk= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.12) for emailcore@ietf.org; Wed, 19 Jan 2022 11:02:12 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.12) with ESMTP id 237828719.1.2588; Wed, 19 Jan 2022 11:02:12 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1524; t=1642607932; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=xu+R2d7 sQAe33wXVlWJ+lDm1JdrNoUfIJsnyiEJhH04=; b=KKHkkSktEAkwMNxOaecNgwa qp7CzxM6YK1Ad3x3aic+Pp/+uJe+rBLtFjWmXN+UpVa4iuhgaxqEdYJLO9pWz9n9 PgmH73McrcsWTUOwiBH6tl0CsrrYGe3pXu7Cxa51cY7ijS7E15uEEcAXH3DpUeBY OnB/S/hcCohML7HnhJBM= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.12) for emailcore@ietf.org; Wed, 19 Jan 2022 10:58:52 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.12) with ESMTP id 3656348547.1.31712; Wed, 19 Jan 2022 10:58:51 -0500 Message-ID: <61E83606.4000809@isdg.net> Date: Wed, 19 Jan 2022 11:02:14 -0500 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Todd Herr , emailcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #16 - Proposed Text for Applicability Statement 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, 19 Jan 2022 16:02:43 -0000 On 1/19/2022 8:41 AM, Todd Herr wrote: > ===================== cut here ======================== > > 7. Timeout Specifications > > The current SMTP specification (5321bis), as well as the two before > it (RFC5321 and RFC2821) contain recommendations for minimum timeout > values for various operations. Given the age of RFC 2821 (published > in April 2001) and advances in networking and computing technology > since then, it might seem that these timeout values are far too > generous. However, those same advances have been relied on by MTA > implementers to add more features and functionality to SMTP > transactions. > > The recommended minimum timeouts are specified as SHOULD, not MUST, > and so implementers may choose to use shorter timeouts if > operational needs or experience indicate that to be appropriate. > > ===================== cut here ======================== > > Please discuss... > +1. I believe this is closer to modern receiver behavior (SHOULD use, may reduce). With senders, I don't believe we have reduced the timeouts - only on the server side are the options available (to revert back to std). I like the text you have but I would also consider the sender is a MUST to be protocol correct with "standard" receiver logic. MTA MUST use but be aware of MDA, MSA. ALWAYS be ready for drops no matter what. MDA SHOULD use, may reduce. MSA SHOULD use, may reduce. Thanks -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Thu Jan 20 20:32: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 0D80C3A1957 for ; Thu, 20 Jan 2022 20:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=HSDarhbu; dkim=pass (2048-bit key) header.d=taugh.com header.b=batNkg4I 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 8q31KlwD13wf for ; Thu, 20 Jan 2022 20:32:39 -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 D8C203A1956 for ; Thu, 20 Jan 2022 20:32:38 -0800 (PST) Received: (qmail 46233 invoked from network); 21 Jan 2022 04:32: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=b497.61ea3764.k2201; bh=x52O3erGiEB+qTH/SWBK2txAsQOwrBxWvyKumvj147g=; b=HSDarhbutFEfbNH335wY8Cy0jZn4Ume3VF4gg9vcR5Jq9zR79i4rRM34duTiIQzfOV+X+dVodlGROHU2kM8yOiz1lS4gQfD8Zqqb/vNHeyyXz8IwoyEC/6nByvIXKQvPXr0Rg0nzm+QaMQBwRlVA4ZUntSfqNnJtbtqaM5/crSNHIzH4BJM+MsXTe/Rf9KAvku3+YgKARdAuW5eltSaoOey+TiZY/NncpRjULAtExVtfHPnz+3BG+E95N/vkB+btj+VQkr5qB3KFMZKN/QaJnU1zSr6iFNe8mj3gDJJSyTCu5v1PrLVcQb+zcA/3vBg5gcof3+1m3TAk8Fob4oK4OQ== 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=b497.61ea3764.k2201; bh=x52O3erGiEB+qTH/SWBK2txAsQOwrBxWvyKumvj147g=; b=batNkg4IlNGd4cmx7OQvWMWNpIjB/2Xbs77lKear3FmwZdbh2VjIJXlaXRHeTC7wyU0xkp6AX75WrdAETf6fqjuBg5B00cK8B4jnHiFo6REWC4K4Cor7T/28m7+7LYd4ucLxBy0yvnfJXKhCVj4aNtKPglAOh5Jn7T8SVv4sdumjl+SpOQ3zUrtpfQfkINny8889GtQn1tjoJ6b9h5WxFTvwpJDGE1G75IP2BCj3m5Bepa/2GRzvvYuBAGDV/wfrzfdx/WnNPAD8P2PjVXJKDLCt9uylO7jx12Yt7BbN0CtvAfUZ4cPd4KXCmcMe0T1L02ZUvKow3FNKGJxDB4lksQ== 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; 21 Jan 2022 04:32:36 -0000 Received: by ary.qy (Postfix, from userid 501) id 6EC3D354FF64; Thu, 20 Jan 2022 23:32:34 -0500 (EST) Date: 20 Jan 2022 23:32:34 -0500 Message-Id: <20220121043235.6EC3D354FF64@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: john-ietf@jck.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] writing drafts is hard 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, 21 Jan 2022 04:32:44 -0000 It appears that John C Klensin said: >I would not feel so strongly about this except that, with a >grand total of zero comments on the changes and questions raised >in draft-ietf-emailcore-rfc5321bis-08 since it was posted two >weeks ago, ... FWIW, I've been going through the draft and so far haven't found anything that I'd want to change. In this case (albeit not in general I realize) silence actually does mean consent. R's, John From nobody Thu Jan 20 21:18:37 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 BA7C53A00E1 for ; Thu, 20 Jan 2022 21:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqUV5CxG65Fh for ; Thu, 20 Jan 2022 21:18:31 -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 9662A3A00E0 for ; Thu, 20 Jan 2022 21:18:31 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nAmJi-000MVr-8K; Fri, 21 Jan 2022 00:18:30 -0500 Date: Fri, 21 Jan 2022 00:18:25 -0500 From: John C Klensin To: John Levine , emailcore@ietf.org Message-ID: <07953168C1FC2D3CD81FACDD@PSB> In-Reply-To: <20220121043235.6EC3D354FF64@ary.qy> References: <20220121043235.6EC3D354FF64@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] writing drafts is hard 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, 21 Jan 2022 05:18:36 -0000 --On Thursday, January 20, 2022 23:32 -0500 John Levine wrote: > It appears that John C Klensin said: >> I would not feel so strongly about this except that, with a >> grand total of zero comments on the changes and questions >> raised in draft-ietf-emailcore-rfc5321bis-08 since it was >> posted two weeks ago, ... > > FWIW, I've been going through the draft and so far haven't > found anything that I'd want to change. > > In this case (albeit not in general I realize) silence > actually does mean consent. John, The effort and calibration are very much appreciated. And I appreciate your speaking up. Talk with you (and I hope everyone else) tomorrow. For everyone else, and with a bit under twelve hours to go before the interim, I'd strongly encourage people to take a careful look at Section 2.3.5 and Section 5. I've moved some material between the two sections and done some rewriting but concluded I need feedback from the WG before either stopping or going further, remembering that such rewrites risk introducing errors. Those two sections are on the agenda, but doubt that it is possible to understand enough about what is going on by looking at them in real time during the meeting. thanks, john From nobody Fri Jan 21 08:39:56 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 1A1E23A0A70 for ; Fri, 21 Jan 2022 08:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a1keASyUqMb for ; Fri, 21 Jan 2022 08:39:48 -0800 (PST) Received: from bumble.maple.relay.mailchannels.net (bumble.maple.relay.mailchannels.net [23.83.214.25]) (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 0A7883A0A82 for ; Fri, 21 Jan 2022 08:39:46 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id ACB802A1680 for ; Fri, 21 Jan 2022 16:39:44 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (unknown [127.0.0.6]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id F39272A0E0A for ; Fri, 21 Jan 2022 16:39:43 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (gcp-us-central1-a-smtpout1.hostinger.io [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.114.70.224 (trex/6.4.3); Fri, 21 Jan 2022 16:39:44 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Keen-Attack: 72b06c634e9eab9a_1642783184443_3702976894 X-MC-Loop-Signature: 1642783184442:15715262 X-MC-Ingress-Time: 1642783184442 Received: from [192.168.0.107] (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 4JgQ8H1BW7z2d9Ct for ; Fri, 21 Jan 2022 16:39:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1642783183; bh=bH5IR6frpxKctlCqlPLwrFV+MNXvJQOi4S+H3csRQco=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To; b=Rr61jfNhQoc5rwlBxRfbfbJ4j0IkWOw9J6cnpOFY4yQCGKsCvlS17V4nrX6pBYe8x Nar8gQl72mWfsyySHnJvsVbic4ZQrEDDyHL4qurv2gXPfxINqrE/uNBM/7dTaCsu6N 01sV4NNZEfGmr+P3Eqm594933Hu5irZbUj7HuxO2gaw+kIPxgMb03SRMTjevGqwQXx rzVlIDL6McOl64UVH0yT6Gjj3ODdwUrIbW/PmKEKvz9TdWc470qikkHMiJlr80QYnA enwz2Vbao8S3FVWThxh6L9TMch7uhlPRpeJvYHdx/InpnCQ2oUVqMSkcuPNij9ksUw AddbhGzJPRWAg== Message-ID: <42c05468-a1e0-d963-06e7-b38c8ff64fa9@dcrocker.net> Date: Fri, 21 Jan 2022 08:39:40 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Reply-To: dcrocker@bbiw.net Content-Language: en-US To: 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: [Emailcore] Scope (was: Re: Agenda for the EMAILCORE interim) 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, 21 Jan 2022 16:39:54 -0000 On 1/19/2022 3:54 AM, Alexey Melnikov wrote: > #9 (G.7.3. Definition of domain name in Section 2.3.5) > https://trac.ietf.org/trac/emailcore/ticket/9 Using this section *merely as an example*, I'd like to (re-)raise a question about criteria for this version of the document. For reference, the charter's guidance is: > This working group will conduct a limited review and revision to the base > email specifications, and will publish new versions of these documents at > Internet Standard status, per RFC 6410. 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. In addition to processing existing, verified errata and > errata marked as "held for document update", the WG may address > newly-offered errata. However, no new protocol extensions or amendments > will be considered for inclusion into 5321bis and 5322bis documents, > unless they are already published as IETF Stream RFCs and are at > sufficient maturity level to move to Internet Standard. "corrections and clarifications" "no new protocol extensions or amendments...unless they are already published as IETF Stream RFCs and are at sufficient maturity level to move to Internet Standard." The Domain Name System is separate from email and now has extensive documentation of specs and use. This was not true in 1982, when SMTP and the DNS were in parallel development. The SMTP specification has no authority of any aspect of the DNS -- except SMTP's /use/ of it. Therefore, any text in the SMTP specification that provides specification of DNS syntax or semantics is, at best, wholly redundant with the authoritative specification(s). The 'at best' is because redundant specification always invites /divergent/ specification. * This raises the question of why the current effort seeks to modify text that does specify Domain Name syntax or semantics, rather than simply having the document cite authoritative sources? A concern that it regularly raised about such a change to this document is that it might disrupt existing use of SMTP. I suggest that if that were a real danger, it would mean that there is use of the DNS in SMTP that does not conform to the authoritative DNS documents. I'd be quite surprised to see any support for actual non-conformance. Hence the fear has a logic that is presumably not matched by practice. Scope: Another distinction for the current work is normative specification vs. pedagogy and commentary. * Obviously, the current effort /must/ repair any normative errors in the SMTP protocol specification. * Presumably it also should improve on SMTP protocol pedagogy or commentary that is now known to be incorrect. * What is not at all clear is why the current document should include commentary or guidance about anything over which it has no normative control and is, again, likely to be incomplete and/or divergent from documents that do have normative control? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jan 21 20:17:45 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 1B47A3A2099 for ; Fri, 21 Jan 2022 20:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbPgNCQBiBlA for ; Fri, 21 Jan 2022 20:17:39 -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 239C33A2097 for ; Fri, 21 Jan 2022 20:17:35 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nB7qH-000OMu-5z for emailcore@ietf.org; Fri, 21 Jan 2022 23:17:33 -0500 Date: Fri, 21 Jan 2022 23:17:28 -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] 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: Sat, 22 Jan 2022 04:17:43 -0000 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. So, IMO, we should remove that text iff people are convinced that potential for confusion has vanished in the last 20 years. Otherwise, it should be retained in some form. So this is a request for mailing list discussion on that specific topic before I take the conclusion of the Interim as definitive and change the text. thanks, john From nobody Fri Jan 21 20:30:01 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 68A273A20FB for ; Fri, 21 Jan 2022 20:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=OObt5JCu; dkim=pass (2048-bit key) header.d=taugh.com header.b=Go+lu0f3 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 55w35t97d68G for ; Fri, 21 Jan 2022 20:29:54 -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 7AA183A20F8 for ; Fri, 21 Jan 2022 20:29:54 -0800 (PST) Received: (qmail 42159 invoked from network); 22 Jan 2022 04:29:52 -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=a4a9.61eb8840.k2201; bh=TNuKkfHGT93ONeHc7qGJTZcLhONUNBVqo3+UbP1TxA4=; b=OObt5JCut6n3S8t8lalU2/Aa+L0yrX05B33DiwxttBwb4YqWvUN4d/aVSW21s8LAleBfAPoyH5mb0F0qcEjVVhwQS5cSZNg4THqE00NavRE6qLQgr+Rn48fiIRJyiCInlNeE2zc16KBgUVmCVlTHDCPxbgzu6leUzOdBEAIAtM0u6BM8aNaLSVVkGlJC9gfHvyNd6sCTFB5T2No8H8xIHl7jlp+chVN6JutM82hEiEVhmzz8XcG1YUM5jzooIA8LC8CYzZNAdakY2D9Bju2Ctl+TixDwJZdNXcp0NvdKvC6aXeP97vbGxvh3WujJpFygiqReDsUA+KHA0DDlZHulJg== 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=a4a9.61eb8840.k2201; bh=TNuKkfHGT93ONeHc7qGJTZcLhONUNBVqo3+UbP1TxA4=; b=Go+lu0f33X6O1PAT7jwCAhXilu+MJcJxnTnF1hjn5u9ZUWnub+FQW88j4ck5sln+eAWWvXTgs5zMYsXrZi8mbtpBPp8QozaEteleQKBrMqiU8HOSOixyoGoQ7n/R9beLhPWuFZ0GnbvAYj6WPY16rQaiiBhZhhtYVfjFN5cyxBqouuoSe2Mo1w0oQrIwl3TZir8lhqJ4OpZI4+pT2EWxl/yb/oq0N2lrZqY2isHdseczXGr+9po0XHw0pEDsdenakskphBzG6ObDC3exLMSqE9nS0QR8ABMGAfQeY662PuvWmpg+/FNsyZB8J8leCUXRpnowj1xf9ASTlE5SxH+ElA== 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 Jan 2022 04:29:51 -0000 Received: by ary.qy (Postfix, from userid 501) id 379BB355E84F; Fri, 21 Jan 2022 23:29:49 -0500 (EST) Date: 21 Jan 2022 23:29:49 -0500 Message-Id: <20220122042951.379BB355E84F@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: john-ietf@jck.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] 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: Sat, 22 Jan 2022 04:29:59 -0000 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. 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. R's, John From nobody Fri Jan 21 21:47: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 A405B3A1AA4 for ; Fri, 21 Jan 2022 21:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnjoYVtbHJd9 for ; Fri, 21 Jan 2022 21:47:34 -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 E61E13A1051 for ; Fri, 21 Jan 2022 21:47:33 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nB9FL-000OSq-NG; Sat, 22 Jan 2022 00:47:31 -0500 Date: Sat, 22 Jan 2022 00:47:26 -0500 From: John C Klensin To: John Levine , emailcore@ietf.org Message-ID: In-Reply-To: <20220122042951.379BB355E84F@ary.qy> References: <20220122042951.379BB355E84F@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] 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: Sat, 22 Jan 2022 05:47:39 -0000 --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? thanks, john From nobody Sat Jan 22 07:22: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 4D2FB3A1F89 for ; Sat, 22 Jan 2022 07:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=GJSd6oNV; dkim=pass (2048-bit key) header.d=taugh.com header.b=bZ+TcIGX 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 sHuWnCQXPCav for ; Sat, 22 Jan 2022 07:22: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 3363C3A1F8A for ; Sat, 22 Jan 2022 07:22:21 -0800 (PST) Received: (qmail 41181 invoked from network); 22 Jan 2022 15:22:18 -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=a0d5.61ec212a.k2201; bh=Vlwd3kgWHkqwmur++BCj5A4QWyqQPu9cBL75loavEXY=; b=GJSd6oNVX/8xUsFvRiTRfApM80jRSdRYEV27icXsqj/9fqtyxHLaV2WjJqvsIg2z421DbcNhBxlH/pUi7pxUV/rcI9Ugxg+n0M00kou4Q4aZo4ngNA0HEjqv3t04RQgEHMplXH5KkKvjqa3x4rAG0K53C3seNdp2L0piULjp4tSBnmeIVFdY5DqAbYc7oJ3ci1w+GxuPgVIYu21waADYhwK+WVQCKNiUoBIisj8skfADb0C08oSZsZs5gVWz927AJk+QT6sxcs9OI7f84IjynFzuvik+jgFrngabXwyv/7GcMlnYvCFDqV9BBx/lQw2ydYB+oTN+aJFkohCbP0e6BA== 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=a0d5.61ec212a.k2201; bh=Vlwd3kgWHkqwmur++BCj5A4QWyqQPu9cBL75loavEXY=; b=bZ+TcIGXt2mYUiUPnxwyKjmYCnexS+m8kpRJkQvg+JHxZkyd7/+jvEI8q5Aq/t2GfXP30G1EdY8wDTgP9Q7RVfqMMD/SGBEvO2zpWoxtIhFQFFIba1I+9OzVysYEsnY0XGoPMIpA4GvL0J4etzGaqZEjoVPULG0rgk0cevf2EvB66E56Kex6q0anIO1QrNjciV54WkPLxHpmNMk1iBqsvTlE7WWKfB7/8MVM+sBpRC6revUZlIj3ew7DuQ2fkj0fGxwFbC+HNFX/J1frb3pAode8cE+xb7KTW8QnNnt/d9GPALizHrljhas1OcWBJ3f6cJD6SGmes65QBVGHKrLiXg== 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 Jan 2022 15:22:18 -0000 Received: by ary.qy (Postfix, from userid 501) id EF31B356389F; Sat, 22 Jan 2022 10:22:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 64D633563878; Sat, 22 Jan 2022 10:22:16 -0500 (EST) Date: 22 Jan 2022 10:22:16 -0500 Message-ID: From: "John R Levine" To: "John C Klensin" , emailcore@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: References: <20220122042951.379BB355E84F@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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: Sat, 22 Jan 2022 15:22:27 -0000 >> 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. As a general rule, it seems to me that if you're rewriting headers, you're doing submission, which is fine but it's not SMTP. We might put something in the A/S along the lines of the point of the bounce address is send failure notifications to someone who can do something about it. When an MTA changes the destination address, the decision whether to change the bounce address is an administrative one, not a technical one, to get the bounces to the appropriate party, 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 Jan 22 10:40: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 2CAE13A268E for ; Sat, 22 Jan 2022 10:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.813 X-Spam-Level: X-Spam-Status: No, score=-2.813 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.714, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZPyDNnnEGjE for ; Sat, 22 Jan 2022 10:39:59 -0800 (PST) Received: from olivedrab.birch.relay.mailchannels.net (olivedrab.birch.relay.mailchannels.net [23.83.209.135]) (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 CD7423A268C for ; Sat, 22 Jan 2022 10:39:58 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 20E5C2A0B72 for ; Sat, 22 Jan 2022 18:39:57 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (unknown [127.0.0.6]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 726292A0B1F for ; Sat, 22 Jan 2022 18:39:56 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (gcp-us-central1-a-smtpout1.hostinger.io [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.112.55.234 (trex/6.4.3); Sat, 22 Jan 2022 18:39:57 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Harmony-Illustrious: 1dc006373620c578_1642876796798_887208602 X-MC-Loop-Signature: 1642876796798:3942154657 X-MC-Ingress-Time: 1642876796798 Received: from [192.168.0.107] (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 4Jh4mW4SKrz2cFZJ for ; Sat, 22 Jan 2022 18:39:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1642876795; bh=Yr9lYGOmXvXTV2bJqzBGJU2GU8XML/V8r+yaPPx5xBE=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To; b=eMnUY6WS1fHOp6QOdhhFrbx4Z0fKe4RUocFXDxLr9eVDc8cv67VvfibUhrIBhnm4w kMKyeDEwZVNGAH/V/fzI9sSCCj+GOY8fq/q8UbfFg/9YWscik0z8xZxS3NBsPgUj39 g4JZZW/JR1Kz8jG62dX2YuY14iuXY0+rEdTe37ymz1MXR9zKjtdoBJyaLpn3PE1utL C14D/miw46+bljtmTZEJZT/slas/s2zGW7yUGMU2bf8moJUGa2+PtKd20JpxqBbluU pwebt6gF6lUvGSppDJS8QK64qHk9S3FSPpvumPWsuQ9RoHbWB5BupiS0VmQ231Kehp qeYK0x7ZefCMQ== Message-ID: Date: Sat, 22 Jan 2022 10:39:55 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Reply-To: dcrocker@bbiw.net Content-Language: en-US To: emailcore@ietf.org References: <20220122042951.379BB355E84F@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Sat, 22 Jan 2022 18:40:04 -0000 > As a general rule, it seems to me that if you're rewriting headers, > you're doing submission, which is fine but it's not SMTP. > > We might put something in the A/S along the lines of the point of the > bounce address is send failure notifications to someone who can do > something about it.  When an MTA changes the destination address, the > decision whether to change the bounce address is an administrative one, > not a technical one, to get the bounces to the appropriate party, +1 This probably aids the distinction between 'protocol spec' and 'service spec', where a service is one or more protocols and the relevant operational guidance. An A/S seems more in line with a role as service specification. Yes? SMTP is only a component of an email service. So it is problematic to have it give guidance about activities beyond its scope. (That the protocol/service conflation dates back to RFC 821 doesn't change the nature of the issue, just makes its genesis more understandable and, arguably, excusable. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jan 24 02:22:56 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 B70813A0A40; Mon, 24 Jan 2022 02:22:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: alexey.melnikov@isode.com, emailcore-chairs@ietf.org, emailcore@ietf.org, superuser@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164301977364.3146.12254015643353022630@ietfa.amsl.com> Date: Mon, 24 Jan 2022 02:22:53 -0800 Archived-At: Subject: [Emailcore] emailcore - New Meeting Session Request for IETF 113 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, 24 Jan 2022 10:22:54 -0000 A new meeting session request has just been submitted by Alexey Melnikov, a Chair of the emailcore working group. --------------------------------------------------------- Working Group Name: Revision of core Email specifications Area Name: Applications and Real-Time Area Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: Chair conflict: extra jmap dmarc uta cfrg Technology overlap: calext dispatch secdispatch Key participant conflict: gendispatch wpack Can't meet: Monday morning, Monday early afternoon, Tuesday morning, Tuesday early afternoon, Wednesday morning, Wednesday early afternoon, Thursday morning, Thursday early afternoon, Friday morning, Friday early afternoon People who must be present: Pete Resnick Alexey Melnikov Murray Kucherawy Dr. John C. Klensin Todd Herr Resources Requested: Special Requests: Late afternoon slot on any day, if possible --------------------------------------------------------- From nobody Mon Jan 24 15:19: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 659B33A1668 for ; Mon, 24 Jan 2022 15:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.098 X-Spam-Level: X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 IH90xYCnzEIw for ; Mon, 24 Jan 2022 15:18:53 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 EAD193A1667 for ; Mon, 24 Jan 2022 15:18:43 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id c15so9016679qtv.1 for ; Mon, 24 Jan 2022 15:18:43 -0800 (PST) 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=9AATDkhdJygjEQL/rzdghqqSv2NMIyKMWj69XcVorMw=; b=MrDWF9wNcU2bzbStjjfqLqOlPrJ8HdcJhRIJFrbPlXkWM6vxG/k+97ljrCLQOKItR7 XsCST5rZo4/pi2kQShv0+mM0+zi0xmpLGw6V4Nom1sztASC8WSUbadPpwm9xj2WdQnUi /DUkvuqBYA7RIjAgRmRcjU5q0XdDTq3fcxPMAo+qA8ECmr+E5b+7kPt9PMg0p+6jDIBg EdGthLvZi2mB8Cf7wP8d/W+OWpcqI2DZvRax9ww9Z3PwHkDN89bkxBgjQb01OibInzY1 l2gDJBA3YSlR09N7LpvNEJC+kje0l5ZYCdLNw3JBQls8cVu0MoGjinnr7DZMtxr6Edpy reww== 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=9AATDkhdJygjEQL/rzdghqqSv2NMIyKMWj69XcVorMw=; b=5mO2OSvjExd7EAbMMekkI0KrTDKNRVesu/FtShsveMQ4p7j0mtOy61V9QVHQx67G/R futF3PhCo4Sg1n/naUnqADChPZ8YgQILljTWPyhxuSLRmgOJgPSXnfmGCQi+sOX5sZUs MWiDBTtaku+wzqhJ3Q3gjriUR09Y4dihUzV83VNM4/i6GaoCwiPkwBc0T4Q8wpKzuf79 BX1vGfj1GfP98ZXtjd95zEfo6pqQIel+3F2Pwz+JZB3PGmTKVo6YMHedTLGInHbvbk80 UqxKDHzsCH87XD6HMeKGbyOthR/uRHxQgOSYTvorm1iLHdorqr+XEA5676d7vfPYzhW3 ZA/Q== X-Gm-Message-State: AOAM53005o1BlwEnre6QJI4jq38KDhsm/FF+VlyjKltLmK5VChX55Rlv bKsw2laWIc0he6saBXsqUOe95xSx3QFgiDtUyFv1ti+E0FTYhg== X-Google-Smtp-Source: ABdhPJxiix1PlVL5yGmP3oUY0syz7ymyvGQdn9mTN6a7UlgqDzWsbnjsKsC07DQBP3nHBo0FpjahRDijiSy01jJaTIc= X-Received: by 2002:a05:622a:120a:: with SMTP id y10mr14628799qtx.619.1643066322214; Mon, 24 Jan 2022 15:18:42 -0800 (PST) MIME-Version: 1.0 From: Todd Herr Date: Mon, 24 Jan 2022 18:18:26 -0500 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="0000000000007a77a405d65c3034" Archived-At: Subject: [Emailcore] Ticket #54 - Take Two - Authentication and Encryption for A/S 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, 24 Jan 2022 23:18:59 -0000 --0000000000007a77a405d65c3034 Content-Type: text/plain; charset="UTF-8" Greetings. Thanks to all who attended the interim on January 21. I've listened to the recording a couple of times and reviewed the notes ( https://notes.ietf.org/notes-emailcore-interim-jan-2022) in an effort to propose better text for the subject topic. Before I really start writing, though, I want to throw the following outline to the group to see if it's directionally correct. - Define encryption (transmitting messages in ciphertext, rather than in the clear, to provide privacy of communication) and authentication (establishing the identity of the hosts involved in the transaction), both done using TLS. - Discuss opportunistic TLS (sometimes called opportunistic encryption) and mention that it's encryption without authentication. - Discuss MTA-STS and DANE for SMTP, which are both encryption with authentication. - Mention SPF, DKIM, DMARC, and ARC, which are authentication protocols, but not the kind of authentication we're talking about here. - Mention private use message encryption (e.g., PGP) but only for the purposes of mentioning that it's out of scope for the A/S Appreciate your collective feedback, to include suggested text for the definitions of encryption and authentication. -- *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. --0000000000007a77a405d65c3034 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings.

Thanks to all who attended the i= nterim on January 21.

I've listened to the recording a couple of tim= es and reviewed the notes (https://notes.ietf.org/notes-emailcore-interim-jan-2022= ) in an effort to propose better text for the subject topic. Before I r= eally start writing, though, I want to throw the following outline to the g= roup to see if it's directionally correct.
  • Define encryption (tr= ansmitting messages in ciphertext, rather than in the clear, to provide pri= vacy of communication) and authentication (establishing the identity of the= hosts involved in the transaction), both done using TLS.
  • Discuss o= pportunistic TLS (sometimes called opportunistic encryption) and mention th= at it's encryption without authentication.
  • Discuss MTA-STS and = DANE for SMTP, which are both encryption=C2=A0with authentication.
  • = Mention SPF, DKIM, DMARC, and ARC, which are authentication protocols, but = not the kind of authentication we're talking about here.
  • Mentio= n private use message encryption=C2=A0(e.g., PGP) but only for the purposes= of mentioning that it's out of scope for the A/S
Appreci= ate your collective feedback, to include suggested text for the definitions= of encryption and authentication.

--

Todd Herr = | Technical Director, Standards and Ecosystem
m: 703.220.41= 53

This email and all data transmitted with it contains conf= idential and/or proprietary information intended solely for the use of indi= vidual(s) authorized to receive it. If you are not an intended and authoriz= ed recipient you are hereby notified of any use, disclosure, copying or dis= tribution of the information included in this transmission is prohibited an= d may be unlawful. Please immediately notify the sender by replying to this= email and then delete it from your system.

<= /div> --0000000000007a77a405d65c3034-- From nobody Mon Jan 24 19:00:06 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 6E4E63A0EC7 for ; Mon, 24 Jan 2022 19:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=d1qylNAV; dkim=pass (2048-bit key) header.d=taugh.com header.b=llNxGHhn 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 ueOXdixrkw_t for ; Mon, 24 Jan 2022 18:59:59 -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 4AF4B3A0EC5 for ; Mon, 24 Jan 2022 18:59:59 -0800 (PST) Received: (qmail 80789 invoked from network); 25 Jan 2022 02:59:55 -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=13b90.61ef67ab.k2201; bh=szc+PtZTj8bJCA4Lhu3HaxJnIn0Ez2+LSjv6NPOh4us=; b=d1qylNAVlYvCmiFOn0s83QLoHrdC5dCoebCZax2Vs+R9N3azikwyHNs7XN6BTzZ0u6dIK6gDwWS35cPHe/N8RBWmYZPC2Gw7tZq0NVq9fSutCHveUPcBkGtVwm6d8NpJjEpE2aG6922lZpFqOgTzWRSMwMdqogIMXA1vusg7y1qXb1/Q0vf/81ahi5rpB6rFO0HfBj5wft+1z1cRjixEKMKOA4nm9M/lBBrUyD4JetawWQ8BRPYyh4BK9qmil32tknXp3TEV5isuyLB2Cis1xyUsYBIg4h1fC0jQr/dSzV4v2cMzspSRO+f9Odv2Vd9jLbZ8dgN1LpLRz/PyArZ3Mw== 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=13b90.61ef67ab.k2201; bh=szc+PtZTj8bJCA4Lhu3HaxJnIn0Ez2+LSjv6NPOh4us=; b=llNxGHhnnNWVwRgTGP69Q8gZzGJJvfcVMT4bVkwh3G2CIrExgkPFfTzahwwIBTzP8e2R4/G4y7upbTsnR6JeOcw1Y3Rn5rEZjy+42RVSmWUISoIiuX1BCK6kkA9+iPci7LdtLIJtaTo9ZdVE99Aef6Ie/1WFiUQGk91819704fjh6Z3p5XnB6N0cQAwKvDCUEpuzefXCQy9rAwpHEn0/M5wvwcwHAverGH3pc8KAsmL8gwPo5YBIelOtg3LUqNA1IyKUGM/7RBL6M/RqFZdUCXv5NPT5hLNkUtrb2963kb0oqxV9DVUFkSeYD/tFKXwmNlvgmac4gvXzPy3esvbVhA== 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 Jan 2022 02:59:55 -0000 Received: by ary.qy (Postfix, from userid 501) id B6B463581EB3; Mon, 24 Jan 2022 21:59:54 -0500 (EST) Date: 24 Jan 2022 21:59:54 -0500 Message-Id: <20220125025954.B6B463581EB3@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: todd.herr@valimail.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] Ticket #54 - Take Two - Authentication and Encryption for A/S 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, 25 Jan 2022 03:00:04 -0000 It appears that Todd Herr said: > - Define encryption (transmitting messages in ciphertext, rather than in > the clear, to provide privacy of communication) and authentication > (establishing the identity of the hosts involved in the transaction), both > done using TLS. > - Discuss opportunistic TLS (sometimes called opportunistic encryption) > and mention that it's encryption without authentication. > - Discuss MTA-STS and DANE for SMTP, which are both encryption with > authentication. > - Mention SPF, DKIM, DMARC, and ARC, which are authentication protocols, > but not the kind of authentication we're talking about here. > - Mention private use message encryption (e.g., PGP) but only for the > purposes of mentioning that it's out of scope for the A/S Seems reasonable. >Appreciate your collective feedback, to include suggested text for the >definitions of encryption and authentication. You would think we would have standard text for those by now. Since we use TLS, the encryption and authentication for mail servers is the same as for web servers, so that might be a good place to look. R's, John From nobody Tue Jan 25 13:21:56 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 DBF1A3A09DC for ; Tue, 25 Jan 2022 13:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ad4h1EWkmyNc for ; Tue, 25 Jan 2022 13:21:50 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 22C523A09D8 for ; Tue, 25 Jan 2022 13:21:50 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id c15so12573642qtv.1 for ; Tue, 25 Jan 2022 13:21:50 -0800 (PST) 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=f3+visllfvBVchN4PvwFMCCOKFqMMQzpT1aV+KGCDgw=; b=gTmol2C0SiV4osjNvln64OQVnWYb1aWWBOF+3Gd8qVnZfGO4BdHRsLX5t50G75C7qP dC1jLsQoUQ0mVz3qhVml5hCQMB2+Kd3dIoRo5DhZENqW5Gv3JLcL8Ulxeakjr+FXjihw tgFvgkkpFQjdnX63yMrq1NvhKTEjwWj8fCUgeOD+rIFXVHujEenBYkMi11wWd8bzneRY 1tDdGIegjlu6RZ1DWSR9N5OkGoQqgdNMWAHD59WbBUagEqPWggbJCSOQzIBt9bwuqg2y RJrikwCOCxdcbFtILUi86aX/g4ZCVWwkJnrvGerhrRPru8++M3Gx12giNucwKhFHkOYs Iw+w== 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=f3+visllfvBVchN4PvwFMCCOKFqMMQzpT1aV+KGCDgw=; b=eCMASgULW9LFSZKaVcv/5x6ZXg15dRwJAZROHkUsX/hduTVxUqEpb6dQKc0ywWDL03 wILKtVyTmJew5rTUfCuhOVKmJgeK8WDxYbE1FkSk+YjGddtMPQiniCx6n0TgKZcs6TyX IgEaosSmUUU7NUfwStIFFsTLbEaNLRnGWyLq7VyjaDxIOp1YUapjCy3lXSvNcCbmfGy9 /A7FEJMvC+khc6DMXN+ZXPp8UoXTxXzgLRlQSaefDeuDvR2vpo7vFsWf6t01ygHVMyR0 l1P7W8ito3HWq6lENm0Bjo1MQi4FZva9YVFABkQ+UWYQiHUZubNOuk0pRCXRYzqLB9ju d3kA== X-Gm-Message-State: AOAM532AZiT6xKEMi0yET4j1wyh1MPUnEsODpHm0OSJXPMUVLgZ3pNCy uk1Jrk+bhOsVkYhXsckoKZB8mQDUziSOCc0vcxzpRkpkP7/1aA== X-Google-Smtp-Source: ABdhPJyK+W2+aIlGooDX256XxIpch15f/6nwkEULB27Xg03eOiCtuPG9i71JcwigFCA1DHZYcAz8vfKLFH4512XLGeU= X-Received: by 2002:a05:622a:95:: with SMTP id o21mr6468152qtw.254.1643145708291; Tue, 25 Jan 2022 13:21:48 -0800 (PST) MIME-Version: 1.0 References: <20220125025954.B6B463581EB3@ary.qy> In-Reply-To: <20220125025954.B6B463581EB3@ary.qy> From: Todd Herr Date: Tue, 25 Jan 2022 16:21:32 -0500 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="00000000000041dfa105d66eace8" Archived-At: Subject: Re: [Emailcore] Ticket #54 - Take Two - Authentication and Encryption for A/S 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, 25 Jan 2022 21:21:55 -0000 --00000000000041dfa105d66eace8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here is my post-interim suggestion for text to use in the A/S to cover the topics of Confidentiality and Authentication =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=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=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5. Confidentiality and Authentication with SMTP The default method for transmitting text using the SMTP protocol is to do so =E2=80=9Cin the clear=E2=80=9D. Years of operational experience have sho= wn that such transmission exposes the message to easy compromise. To mitigate this risk, SMTP has evolved over the years to allow for easy integration and support of Transport Layer Security (TLS - RFC8446) to provide both confidentiality and authentication in the transmission of messages. This section will discuss those topics and their most common uses. It is important that the reader understands 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 the endpoints (e.g., the hosts) of the SMTP transaction - 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. 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. 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, an SMTP server announces in its gree= ting that it is capable of supporting TLS encryption through the presence of the =E2=80=9CSTARTTLS=E2=80=9D keyword. The SMTP client then attempts to negoti= ate an encrypted connection, and if successful, transmits the message in encrypted form; there is no guarantee that the message will be stored in encrypted fashion at its destination, and in fact, storage in plain text should be expected. 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 endpoints of the transmission, 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 the SMTP protocol 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. 5.2 Required Confidentiality, with Authentication Two protocols exist that move message confidentiality from optional to required - MTA-STS [RFC8461] and DANE for SMTP [RFC7672]. While they differ in their implementation details, SMTP 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 SMTP client refusing to transmit the message. Support for both protocols is widening, but is not yet mandatory. These two protocols differ from Opportunistic TLS not only because they require message confidentiality, but also because they require authentication. 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 the SMTP protocol. They deal with authentication of the message, not the endpoints. 5.4 Message-Level Confidentiality The more sophisticated among the end users of SMTP may take advantage of various third party solutions that are designed to encrypt their message immediately upon leaving the MUA, and to do so in such a way that only the individual message recipient(s) can decrypt the message. The solutions (e.g., PGP) are too numerous to list here, and as they operate at the message level rather than the SMTP protocol level, 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=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=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Have at it... --=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. --00000000000041dfa105d66eace8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here is my post-interim suggestion for text to = use in the A/S to cover the topics of Confidentiality and Authentication
=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

5. Confidentiality and Authentication with SMTP

The default method for transmitting text using the = SMTP protocol is to do so =E2=80=9Cin the clear=E2=80=9D. Years of operatio= nal experience have shown that such transmission exposes the message to eas= y compromise. To mitigate this risk, SMTP has evolved over the years to all= ow for easy integration and support of Transport Layer Security (TLS - RFC8= 446) to provide both confidentiality and authentication in the transmission= of messages. This section will discuss those topics and their most common = uses.

It is important that the r= eader understands 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 dire= ctly from RFC8446.

  • Authentication is the process of establishing the identity of the en= dpoints (e.g., the hosts) of the SMTP transaction

    • The t= erm =E2=80=9Cconfidentiality=E2=80=9D describes a state where the data (i.e= ., the message) is transmitted in a way that it is only visible to the endp= oints.

It is not uncom= mon 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 achie= ved with SMTP, but that does not mean that future methods might not be deve= loped.

5.1 Optio= nal Confidentiality

The most com= mon 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, an SMTP server a= nnounces in its greeting that it is capable of supporting TLS encryption th= rough the presence of the =E2=80=9CSTARTTLS=E2=80=9D keyword. The SMTP clie= nt then attempts to negotiate an encrypted connection, and if successful, t= ransmits the message in encrypted form; there is no guarantee that the mess= age will be stored in encrypted fashion at its destination, and in fact, st= orage in plain text should be expected. If negotiation fails, the client fa= lls back to sending the message in clear text.

Opportunistic TLS is confidentiality without authentication,= because no effort is made to authenticate the endpoints of the transmissio= n, and it is optional confidentiality due to the ability to fall back to tr= ansmission in the clear if a secure connection cannot be established. That = said, most modern implementations of the SMTP protocol support this method,= especially at the largest mailbox providers, and so the vast majority of e= mail traffic is encrypted during its time transiting from the client to the= server.=C2=A0

5= .2 Required Confidentiality, with Authentication

Two protocols exist that move message confidentiality from= optional to required - MTA-STS [RFC8461] and DANE for SMTP [RFC7672]. Whil= e they differ in their implementation details, SMTP servers relying on eith= er 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 SMTP client refusing to transmit the message. Support for bot= h protocols is widening, but is not yet mandatory.

These two protocols differ from Opportunistic TLS not o= nly because they require message confidentiality, but also because they req= uire authentication.

5.3 Message-Level Authentication

Protocols exist to allow for authentication of different identities a= ssociated 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], prov= ides a way for each hop to record results of authentication checks performe= d at that hop.

All of these are = outside the scope of this document, as they are outside the scope of the SM= TP protocol. They deal with authentication of the message, not the endpoint= s.

5.4 Message-L= evel Confidentiality

= The more sophisticated among the end users of SMTP may take advantage of va= rious third party solutions that are designed to encrypt their message imme= diately upon leaving the MUA, and to do so in such a way that only the indi= vidual message recipient(s) can decrypt the message. The solutions (e.g., P= GP) are too numerous to list here, and as they operate at the message level= rather than the SMTP protocol level, they are out of scope for this docume= nt.

=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

Have at it...


--

Todd H= err | Technical Director, Standards and Ecosystem
m: 703= .220.4153

This email and all data transmitted with it co= ntains confidential and/or proprietary information intended solely for the = use of individual(s) authorized to receive it. If you are not an intended a= nd authorized recipient you are hereby notified of any use, disclosure, cop= ying or distribution of the information included in this transmission is pr= ohibited and may be unlawful. Please immediately notify the sender by reply= ing to this email and then delete it from your system.

--00000000000041dfa105d66eace8-- From nobody Tue Jan 25 15:28: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 DCB243A15C7 for ; Tue, 25 Jan 2022 15:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.813 X-Spam-Level: X-Spam-Status: No, score=-7.813 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.714, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R61Uzp0_WLx3 for ; Tue, 25 Jan 2022 15:27:55 -0800 (PST) Received: from dog.elm.relay.mailchannels.net (dog.elm.relay.mailchannels.net [23.83.212.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76673A15C5 for ; Tue, 25 Jan 2022 15:27:55 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D3AEA46160A; Tue, 25 Jan 2022 23:27:53 +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 0D7C94616C1; Tue, 25 Jan 2022 23:27:52 +0000 (UTC) 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.103.158.127 (trex/6.4.3); Tue, 25 Jan 2022 23:27:53 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Lonely-Reign: 522273a07617b1c9_1643153273558_3385898749 X-MC-Loop-Signature: 1643153273558:4204664064 X-MC-Ingress-Time: 1643153273558 Received: from [192.168.0.107] (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 4Jk31L74LRz7X4wm; Tue, 25 Jan 2022 23:27:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1643153272; bh=g+bwsZlEiA0ukhmV6BPfSQGCr6/O17E1Ur48ufWBYXs=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To; b=IKIAlNPZc0D66XJ0S9CUEkz/QU+SVmTJHyHiCXQCTo+SVO03M66fHF+oa+odKu92Z RlvvLOjkonrbtZsMDA6xW/RRoXFib6Ue3Pvg2AEl/zb6b/NqemtaxkPCCiy3w6J0Fp W3ohGy3zoAnqe2wLYRXIomiK2HiHtqWzA8JfurKQ7Cq/yQj7Vl+2zyU4KdKphtludz HJAIqkLu+y0Py/ydda4whPg00AE1ragfXb3hK7kfH4AKuuxMkcXmwqVFdPdNVq30vx JxYySPwfxfLgkqLpd1gFLs1f6ezrGBWS53I5gWaB9+1hBDOvrOlQ78Mh5CaGmKlvT7 et2hy0grwReAw== Message-ID: <7596dd3e-0317-4670-0c1a-a2375dcd32cf@dcrocker.net> Date: Tue, 25 Jan 2022 15:27:49 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Reply-To: dcrocker@bbiw.net Content-Language: en-US To: Todd Herr , emailcore@ietf.org References: <20220125025954.B6B463581EB3@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #54 - Take Two - Authentication and Encryption for A/S 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, 25 Jan 2022 23:28:01 -0000 On 1/25/2022 1:21 PM, Todd Herr wrote: > Here is my post-interim suggestion for text to use in the A/S to cover > the topics of Confidentiality and Authentication > > =================================================== cut here > =============================================== > > 5. Confidentiality and Authentication with SMTP > > The default method for transmitting text using the SMTP protocol is to > do so “in the clear”. I suggest not casting it as the default. It's not that the statement is wrong, but I think it sets the stage in a way that casts the protection mechanisms as exception. So, perhaps: 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. ... comprise, including wiretapping and spoofing. > To mitigate > this risk, these risks SMTP has evolved over the years to allow for easy integration > and support of Transport Layer Security (TLS - RFC8446) to provide both > confidentiality and authentication in the transmission of messages. Hmmmm. I think SMTP has not evolved at all. What has evolved is the operational choice to run it over TLS. Have I missed changes to SMTP, itself? If my understanding is correct, then perhaps: Operation of SMTP has evolved over the years, so that it is used with the benefit of Transport Layer... > This > section will discuss those topics and their most common uses. will discuss -> discusses > > It is important that the reader understands what is meant by the terms understands -> understand > “Authentication” and “Confidentiality”, and for that we will borrow > directly from RFC8446. > > * > > Authentication is the process of establishing the identity of the > endpoints (e.g., the hosts) of the SMTP transaction > > * > > 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. > > 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. nicely written! A point of clarification worth adding, especially since it is usually missed but is extremely important: Note: With typical email use of TLS, authentication only is performed for the target receiving server and is not done for the sending client. That is, it serves to validate that the connection has been made to the intended server, but does not validate who initiated it. It's probably worth hammering this point a bit, such as changing any reference to authentication to be "receiving server authentication" or somesuch. > > 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, an SMTP server announces > in its greeting that it is capable of supporting TLS encryption through > the presence of the “STARTTLS” keyword. The SMTP client then attempts to > negotiate an encrypted connection, and if successful, transmits the > message in encrypted form; there is no guarantee that the message will > be stored in encrypted fashion at its destination, and in fact, storage > in plain text should be expected. If negotiation fails, the client falls > back to sending the message in clear text. Since I think this needs very strong emphasis, perhaps breaking out and indenting the 'no guarantee' text, such : Note: TLS provide protection while mail is in transit, but it does NOT mean that there is any mail encryption while the message is stored in a sever. In fact, storage in plan text should be expected! > Opportunistic TLS is confidentiality without authentication, because no > effort is made to authenticate the endpoints of the transmission, 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 the SMTP protocol 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. > > 5.2 Required Confidentiality, with Authentication > > Two protocols exist that move message confidentiality from optional to > required - MTA-STS [RFC8461] and DANE for SMTP [RFC7672]. While they > differ in their implementation details, SMTP 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 SMTP client refusing to transmit the message. Support > for both protocols is widening, but is not yet mandatory. widening -> increasing > > These two protocols differ from Opportunistic TLS not only because they > require message confidentiality, but also because they require > authentication. since TLS provides confidentiality, I think the requirement for authentication is the only difference. > > 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 the SMTP protocol. They deal with authentication of the > message, not the endpoints. the SMTP protocol -> SMTP (the P in SMTP stands for "protocol"...) > > 5.4 Message-Level Confidentiality > > The more sophisticated among the end users of SMTP may take advantage of > various third party solutions that are designed to encrypt their message > immediately upon leaving the MUA, and to do so in such a way that only > the individual message recipient(s) can decrypt the message. The > solutions (e.g., PGP) are too numerous to list here, and as they operate > at the message level rather than the SMTP protocol level, they are out > of scope for this document. Since S/MIME and OpenPGP have RFCs, I suggest citing them, though noting that there are many proprietary solutions in use is reasonable, of course. > > =================================================== cut here > =============================================== > > Have at it... yum... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jan 25 15:39:38 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 0FD6E3A1637 for ; Tue, 25 Jan 2022 15:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.82 X-Spam-Level: X-Spam-Status: No, score=-6.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtFiqVOzs6jM for ; Tue, 25 Jan 2022 15:39:32 -0800 (PST) Received: from mail-ob3.cityemail.com (unknown [104.128.152.20]) (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 51FAE3A1635 for ; Tue, 25 Jan 2022 15:39:32 -0800 (PST) Received: (qmail 647928 invoked from network); 25 Jan 2022 23:39:31 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe3.cityemail.com with (TLS_AES_128_GCM_SHA256 encrypted) SMTP (0b57d4a6-7e38-11ec-a942-4b4f9bf7d58c); Tue, 25 Jan 2022 15:39:31 -0800 To: emailcore@ietf.org References: <20220125025954.B6B463581EB3@ary.qy> <7596dd3e-0317-4670-0c1a-a2375dcd32cf@dcrocker.net> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: Date: Tue, 25 Jan 2022 15:39:31 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <7596dd3e-0317-4670-0c1a-a2375dcd32cf@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 2.2.x-3.x X-MagicMail-UUID: 0b57d4a6-7e38-11ec-a942-4b4f9bf7d58c X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [Emailcore] Ticket #54 - Take Two - Authentication and Encryption for A/S 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, 25 Jan 2022 23:39:37 -0000 On 2022-01-25 3:27 p.m., Dave Crocker wrote: > On 1/25/2022 1:21 PM, Todd Herr wrote: >> Here is my post-interim suggestion for text to use in the A/S to cover >> the topics of Confidentiality and Authentication >> >> =================================================== cut here >> =============================================== >> >> 5. Confidentiality and Authentication with SMTP >> >> The default method for transmitting text using the SMTP protocol is to >> do so “in the clear”. > > I suggest not casting it as the default.  It's not that the statement is > wrong, but I think it sets the stage in a way that casts the protection > mechanisms as exception. > > So, perhaps: > > SMTP is specified without embedded mechanisms for authentication or > confidentiality.  Its traffic is therefore "in the clear". "The original SMTP specification was created before embedded mechanisms for authentication or confidentiality became the norm. As such, it's traffic can be transmitted "in the clear", with the accompanying risk of exposing sensitive information, including passwords." Does that sound better? It's a clear indication that it's time to do things differently than the original specifications. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Tue Jan 25 15:45:52 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 0DA943A1697 for ; Tue, 25 Jan 2022 15:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.813 X-Spam-Level: X-Spam-Status: No, score=-7.813 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.714, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kLT7HmOqK8S for ; Tue, 25 Jan 2022 15:45:45 -0800 (PST) Received: from bumble.maple.relay.mailchannels.net (bumble.maple.relay.mailchannels.net [23.83.214.25]) (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 9A4173A168C for ; Tue, 25 Jan 2022 15:45:45 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 81D17821383; Tue, 25 Jan 2022 23:45:44 +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 DA6B98213DB; Tue, 25 Jan 2022 23:45:43 +0000 (UTC) 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.114.196.241 (trex/6.4.3); Tue, 25 Jan 2022 23:45:44 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Decisive-Soft: 34ae31ee54f0a916_1643154344294_520323022 X-MC-Loop-Signature: 1643154344294:3698871092 X-MC-Ingress-Time: 1643154344294 Received: from [192.168.0.107] (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 4Jk3Px6prSz7X4wv; Tue, 25 Jan 2022 23:45:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1643154343; bh=fmTnwu7v8o3jD/mMZrVHqAq8cfUwHz3ygw5lPOpuhMs=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To; b=m3BjAAjA+37aLIABr5P2ZxpIwWTn9gCQzFNXounTk+9GKr6/w+W2VPsmk9jlaTCr1 D2Fr0Pky3WQx3+n43qiyPB5mHwojCOV2eeGemJiEzNkWeQvZJ/rdVNMZnXJKVi2JFu oet5Ihm6xqZweY0LZ5LSFDOYd/K0eFqz47P99wDmbbkotbvXR6nVknZ+rdL0l6QLeZ fZqWNHFjVKviTgCgd3+fANY1mnfiDVz0nT50WY15JD7QYyBv2WAtN3tk9UwoKUa4v0 j6PGdgLI/d8FvxJOtwz37zCexSkhJ9ZRhOaLSYTzDvtbo3Cp+3kQnLzEVp0V+PC5QB /5Y28sR9F+J5g== Message-ID: Date: Tue, 25 Jan 2022 15:45:41 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Reply-To: dcrocker@bbiw.net Content-Language: en-US To: Michael Peddemors , emailcore@ietf.org References: <20220125025954.B6B463581EB3@ary.qy> <7596dd3e-0317-4670-0c1a-a2375dcd32cf@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] Ticket #54 - Take Two - Authentication and Encryption for A/S 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, 25 Jan 2022 23:45:51 -0000 On 1/25/2022 3:39 PM, Michael Peddemors wrote: > "The original SMTP specification was created before embedded mechanisms > for authentication or confidentiality became the norm. As such, it's > traffic can be transmitted "in the clear", with the accompanying risk of > exposing sensitive information, including passwords." > > Does that sound better? It's a clear indication that it's time to do > things differently than the original specifications. First, nothing being done now changes SMTP. It changes packaging around SMTP. This is not a minor point. This is, therefore, a matter of changes to the 'service' rather than to the 'protocol', and certainly not to the specification of the protocol. Second, the historical perspective is interesting briefly, perhaps, but is not interesting or useful for the long term. That's why the phrasing I chose focuses on simple technical differences and does not have to tone of judgement about deficiencies in the past or superiority of the present. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jan 25 15:58: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 A56B03A1708 for ; Tue, 25 Jan 2022 15:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.613 X-Spam-Level: X-Spam-Status: No, score=-7.613 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2PVcOLP4HiA for ; Tue, 25 Jan 2022 15:58:30 -0800 (PST) Received: from mail-ob.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) (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 D016D3A1707 for ; Tue, 25 Jan 2022 15:58:29 -0800 (PST) Received: (qmail 711828 invoked from network); 25 Jan 2022 23:58:28 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (TLS_AES_128_GCM_SHA256 encrypted) SMTP (b0d68b00-7e3a-11ec-b52b-1fcb71beafc6); Tue, 25 Jan 2022 15:58:28 -0800 To: emailcore@ietf.org References: <20220125025954.B6B463581EB3@ary.qy> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: Date: Tue, 25 Jan 2022 15:58:28 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-MagicMail-OS: Linux 2.2.x-3.x X-MagicMail-UUID: b0d68b00-7e3a-11ec-b52b-1fcb71beafc6 X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [Emailcore] Ticket #54 - Take Two - Authentication and Encryption for A/S 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, 25 Jan 2022 23:58:35 -0000 On 2022-01-25 1:21 p.m., Todd Herr wrote: > 5.2 Required Confidentiality, with Authentication > > Two protocols exist that move message confidentiality from optional to > required - MTA-STS [RFC8461] and DANE for SMTP [RFC7672]. While they > differ in their implementation details, SMTP 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 SMTP client refusing to transmit the message. Support > for both protocols is widening, but is not yet mandatory. > > These two protocols differ from Opportunistic TLS not only because they > require message confidentiality, but also because they require > authentication. > Sorry, won't make any suggestions on this section, but do want to point out this is unclear, as it makes a statement about server-server communication, and then speaks about the SMTP client which is confusing. Are we missing something here as well? Another example of 'Required Confidentiality' is when a server does not allow authentication without SSL or TLS encryption for sending. Is there something you can reference, that speaks directly to supporting plain text authentication is no longer recommended? -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Wed Jan 26 05:56: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 088723A1042; Wed, 26 Jan 2022 05:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 KxA_t5w1uy-T; Wed, 26 Jan 2022 05:56:11 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 D0AFD3A1041; Wed, 26 Jan 2022 05:56:07 -0800 (PST) Received: from pps.filterd (m0184893.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 20QCuMrT017580; Wed, 26 Jan 2022 08:56:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=20190412; bh=XbqZKTLYkrCh6lm1nGegFGoC2bzdNTf+bK0HOC+FZpw=; b=H9vg+AWINXvfO5HHmF2AZPYbcEM7q/t+vbK7qAuupfowjKXgsKS9LaCeRZK5QbBC2FgV HhC8woxbYx9tQfJcGdXD3a5j76fyFRmex6Sob9dwg9f1rzoXTXh4DICs0BItVSveJvKp mjWVOBbTaKm9/OZp1WNEFKyaoJ648dNrNcfPuQ6SErVaCpdz9f+XbmyoT4Pfc2hmVKZa /iDLseLEJSvnhP9RDAVBzPV4kUKOH/7FHANNAPeTdTb/ds7VyNsXUQWpVP95iUZeSKDR bGZGy8SkBywXNrkkt6+DE9H5Ce0yqP6a9PfWu6RntiNVldW4tPH+WuYUIZ6jF0fz4f57 Tg== Received: from pacdcexop01.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0a-00143702.pphosted.com (PPS) with ESMTPS id 3dtkdkft70-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 26 Jan 2022 08:56:04 -0500 Received: from PACDCEXOP01.cable.comcast.com (24.40.1.148) by PACDCEXOP01.cable.comcast.com (24.40.1.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 26 Jan 2022 08:55:51 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEXOP01.cable.comcast.com (24.40.1.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.986.14 via Frontend Transport; Wed, 26 Jan 2022 08:55:51 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.108) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Wed, 26 Jan 2022 08:55:36 -0500 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by SN6PR11MB3007.namprd11.prod.outlook.com (2603:10b6:805:d6::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4909.13; Wed, 26 Jan 2022 13:55:33 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::e06d:3a54:f250:f2c6]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::e06d:3a54:f250:f2c6%4]) with mapi id 15.20.4930.015; Wed, 26 Jan 2022 13:55:33 +0000 From: "Brotman, Alex" To: Todd Herr , "emailcore@ietf.org" Thread-Topic: [Emailcore] Ticket #54 - Take Two - Authentication and Encryption for A/S Thread-Index: AQHYEXjKNebi2VmHOEyHBH59/n6YlKxzDE8AgAEzywCAAROdAA== Date: Wed, 26 Jan 2022 13:55:33 +0000 Message-ID: References: <20220125025954.B6B463581EB3@ary.qy> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 71c8ba15-258f-459c-f0b2-08d9e0d38580 x-ms-traffictypediagnostic: SN6PR11MB3007:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TeL+Sr/CdtBZVVNGYpKR3TfhguwcbKbcaIiUz1Qg6jO9QanO6/g8JkQ+p6CXML33LLvzURqp15ZniJmOs35foTizr4wSCgu+sdsIlO0jPYfYwl73vIVUyeaXL/Yq4SkE/RO/DB6sCMVELDj9w2Ic+PhQrMBxK+5sTl0wEfcNnzMRQJhIY+uAlRTgbvRJcx8mUtUkmnwR87k4RUYATNH38eLZmCXnWrjyVZifreqpUlqxATSUT8nK4mico0/fvZjm1Kr1V18Er/shW35blDf6xI2zvf6fRVu0gJdgR26iUrDd/QLhYF7Ggp0bctmmKxaEuinL7tuRBzD0tuf1my7203m94btbTVfCceODV2IiTw4a2WD3JdSw7W/+02oQ6mEm+0Z1OX82UBUoBmdfSPOYHIMRHpZ/VR2NqKxPJtFfU7uKb2iuLM7hOPW2RCy4SmUs+V7OkcqrIWDVkyUPqo6r5LHtLMkvmE3BEa+IczxbyKml4lxCz/07mA5bAeqayh+JHheQnxBI6TGf7KC+scUqFXuVpMAnyJTP32GfUC+baATWEHJjJw5LZYWkV0cgYYysLxr4S3Mzx0WcE+JrDPWQhy5A3Z8Z76uPajecqB/WrqEvc1880HDFVp8ZfqUkQoJMNXH3zFARPJlpIcuhT3O8uRSiBUOKMuCGQyYgW+a9P+ZNrk/NHdu/+1zUvbkiF2x/RbPgErd2HKfmwfYdf8t2VQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(84050400002)(508600001)(186003)(86362001)(64756008)(6506007)(66476007)(66556008)(110136005)(55016003)(71200400001)(33656002)(66446008)(38070700005)(8676002)(7696005)(40140700001)(83380400001)(9686003)(52536014)(2906002)(76116006)(38100700002)(5660300002)(122000001)(8936002)(66946007)(53546011)(316002)(82960400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MDlVeC9VMlJtcUdoSjc5b2QvbG1SSllER1RycVRmZDhOaUJ0aDI2VWJzVFZk?= =?utf-8?B?c1dicTlLdVc1aWU5UVJrc1FtWDVxUjMyWkNJTEYwdTJZakxpTzdvY0d1cnc1?= =?utf-8?B?MUp0K0o2dkRDd043aStKZ1BHVWQrYitQdm5YZXFXbk03MlRCRHlCODNocFZw?= =?utf-8?B?TUU4UFYzb1I1T0JoeGVFQ1hVR05ZcmZ2Tm1rYXU5SDhkdWdSOEo3TktRS2Rm?= =?utf-8?B?anUyQ3lzM2ZkWTZ5R2ZSa3ZPUzBmQlFzM2REM21LR1pMemFUYi85NjBsVXZM?= =?utf-8?B?Y0lhTVJaNTdPQmNqMzFsbjM4QzNCMGZuZW1tZ0NXSlNIOENWTEU3VEM4TEFN?= =?utf-8?B?dWJDSWFWWDVYV0JHU0VjakR3YkNqbWYvZFpDRkRVSkI2Qk1XVHI1Q2FhekFY?= =?utf-8?B?UitPVk5nb05sbFdWcGFoUnNONk84UWpnSmNYUXM1b01RTGgvRjdnbGQ5L0Ji?= =?utf-8?B?RXU4ZGlPdmVNWHdvOEtveEVObkdoMmpVUzMrMkZBbDRZenQ1VUVCWnNiZStQ?= =?utf-8?B?OHdWRFFLVXZlanlQSEhKUXNwaHlXSWdRWC9uZ3czVDBRbUtGNXlERkk0ZG9J?= =?utf-8?B?UHFDeTNiK3BUd2VXdEpBcnpMTGhIUDloQnorVEgvbUxJQ1NqZ0tSMHdEM1hC?= =?utf-8?B?WWRrNDRnYm12N3k3eGo5dGZVN2hpbGY4M3FFYjFlNzFxN3YraVVYL2JzMHoz?= =?utf-8?B?d2wzRU8rU3JHbzdBTkFwWlBIdWlaQWhoT3o0bzNiajVGa3g1eDl4bEY2bmh2?= =?utf-8?B?QnBaTnora2p3eFZZelduQ3ozTHNRWHRZbnJOd0hhR1Y0Z2ZVY1NYZ1p5TUxV?= =?utf-8?B?Mm8wTzBaODZyNXEyaXdXbU4xcWxKdDh4SG1nc3B3WllxSElUbTB2ZTladUVN?= =?utf-8?B?UDZuUk83UTFLSmFOK0Myd0pGVytCbjlKN1RIZXdHdnpMKzRmN1JCaTU4TURp?= =?utf-8?B?S1FKZ1VYOGlqaWI5aXhBbk8wZ0x3cGlOTWQzTmVuRk04QkE5azIxQUtYZWRK?= =?utf-8?B?aUYrVjNEcXNVelpuVjYwOU04S2hTcTdHZng0Wk9sRUtmN0lzQ2trKzEzeU51?= =?utf-8?B?MWdFQ0hxcHJZOGJoVEd1RmYyVVlQY0ZMUE42TFRtbGRrUDdXRTUra2FlTTNu?= =?utf-8?B?L1krOTIyUUFwRjNiREIyN3hTTmhvOWJmMGtKaHBaYXRMY0hiN0JVejZ3Zm1t?= =?utf-8?B?UVRPNG40ZUltUXprUU4vS2V3ZnJjZlp3U1B5UkV1V1NRZzZiQVdpUUk4L1pH?= =?utf-8?B?RTdXZW9iNThlWmdrTFkyTS9VL1E3QmQwRzZKd3p1YTdYeDNZZ2RwWjh6eDBi?= =?utf-8?B?dmlEekRJUVplTmYxb2pENVByWkRIWkF2VzlQSE1PcFBPZ0IxUU15Ylo2ZzUy?= =?utf-8?B?T2VqeG5Gdnk0MmtEZnphU1dOenFYSnJwSktZNVUyVHMydmZNZFRXb25DOHJr?= =?utf-8?B?RlRZRDlNNzZlUnNWU1ppdHJjcmM2VHA5K1NvbVhJdnhQZDJzS3ZkaTlQNjFJ?= =?utf-8?B?QVZGeG0wZnFBZ2tuQk0yK2FNUHdKaVJUYUJveUtpWURocjI0YW0xT1czOFgw?= =?utf-8?B?aDE4OU5TUll0V1Ewd0ZIbDNOLzU2TUd3eE1uZml1UW1CSW9lYURielJMSTNt?= =?utf-8?B?RVBGeGZyVHUrRnFWOUlVWDRwd0F0N1RKVk9HUHI2d0hNNkR0VWNkdk5Hb282?= =?utf-8?B?Vm9sV2N5UTBHQVppNVVUREp1RGxncnRjQXlZMSs2cEs3NFRhMml0Z0UvV2JS?= =?utf-8?B?M3lpeS9kWktMZDcyOGhRUTYzU1JaM1FsSFNoZGR2ci9ZWVNFK3RBYlEySE5a?= =?utf-8?B?OWR4SytaOGJETHFIeUdhUE5RVE9mdkpMaGpVSzZDdUpMQnFKN2JDbEFYcG9w?= =?utf-8?B?S0dhQXI1eFdWaFFOOVJQOUNCZitjUFZlZGhHZ2dzbDh6KzBGMjRwRkZQZFh4?= =?utf-8?B?d2RVOXRZR3ozSGJwK0FHYVVKR2hsNURQMnNpcnpISVlVZU9XQU5sVS9sVGdQ?= =?utf-8?B?Y2ltc25xcmJieEJ3VTFZT01ZQ2pVSWtlUnp3Z05zWTB2dG0xUEcvUXR6Rk8w?= =?utf-8?B?UmZyU0hJSzM3YWRYVUxXem1NRXN4Tlp3TVNSVEVIV1dta3hqUlBVWGs5L3pU?= =?utf-8?B?LzZ1YnF1d0U2YTBHOTZmWW1KQm9oRlVHcE9HQ1hWWU9tU3d3Tk1WMVBIMWds?= =?utf-8?B?RlAvdkhTTEdSZFRJaUd1UDFacXZhVVY2Ti9kRm8wbU1MQmxFQmZjK29ZdmZt?= =?utf-8?B?RVFubkh5NmZBQ0R0QXZkTzRFeEJZZUN0ZVRkUjBJNUY3RURNR2U5TjROSXFH?= =?utf-8?B?ZThlaUcvRXo2NFUwQVdVRkZLeHhXTmtpalJ5eDhtS2lCbi92aXk3QT09?= arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HE3xQbttId6D/UOSEs6nH5FFLv4Hh65qu7X/gJ08AGy0mJ1PrPWkLQEEeG1Dpe3ns5g547vhjSvfoYe0DDxOrgLgBWbYLpUs5SMmUIkIchXqIcf4LTRL9rwQgNgBuFLMagJUO+eelTxbWZjDrDJWYCygCPRp6ZpeF1P0rkvn6Op69YZAvnYWWSHFcDyIxC5Ki9wzwvx0PPj2/LjxG290XeCxzWpI4U9rw7qP749Ry6aG7V05J8T3qDZBM7yC0PPLyQHPkJ5EKg46gAG6un6DS14osE7YXhCxI/gtLXvSZgdQJXMT/WJHCLWxnkWV/g2jLklGj/m85/Jj2TTY83f+yA== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SfJk9yyA0FGFYnyIhnjWXQcZ5B+URWK6BRhEfnB2Krg=; b=CoF+KH5FBdRUsHFmD8Vgl72tlks/Oq/qXMLqqa7pImZ5D54hOSFcSrMS+ciQRQ9yj9/VmU37/jUMepphcjEtoptLpFaqmyem2kNPQvnuT6NLMKEWwXiRIYqimRKI4w/LoYABbvpUvT1F0yZ43hGb7i9IQfirZZeAGouPo/AoQGPxjiFUTJAszK7G3Cv0DuFkLtWMnyifTGtsz9FdHK5ByaXqZgCLCZTMfj5GPoFyxuwdoscWcWU5IUiFzoA78CFdEXTZ7GNXCmVbjEWrunTRoFNuInwV6PXpg1vAuYdmPNuK170eRNtVw+lVImDdclTi6J6UElTdiCAo37qt+3H2dA== arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 71c8ba15-258f-459c-f0b2-08d9e0d38580 x-ms-exchange-crosstenant-originalarrivaltime: 26 Jan 2022 13:55:33.0770 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: fCvD04hM07tHMRYkmjOuftQw6zJN/zbbd17B13Il2PRFpyhNlFmSxbL5xtHyAkColwRwaXVlfXpEfLO8WuUg2eosZJ2+Vd8LES6fBeW4b4g= x-ms-exchange-transport-crosstenantheadersstamped: SN6PR11MB3007 x-originatororg: comcast.com Content-Type: multipart/alternative; boundary="_000_MN2PR11MB435163904FA5E4ECD9336CBBF7209MN2PR11MB4351namp_" MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWZ X-Proofpoint-GUID: 6srPEIlH1xy9ggG7TSw1GGmi_ndDiuad X-Proofpoint-ORIG-GUID: 6srPEIlH1xy9ggG7TSw1GGmi_ndDiuad X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-01-26_04,2022-01-26_01,2021-12-02_01 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Emailcore] Ticket #54 - Take Two - Authentication and Encryption for A/S 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, 26 Jan 2022 13:56:16 -0000 --_000_MN2PR11MB435163904FA5E4ECD9336CBBF7209MN2PR11MB4351namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UG90ZW50aWFsIG51YW5jZSB3aXRoIE1UQS1TVFMsIHRoZXJlIGlzIGEg4oCcdGVzdGluZ+KAnSBt b2RlIHdoaWNoIGRvZXMgYWxsb3cgZm9yIHNlbmRlcnMgdG8gaWdub3JlIFRMUyB2YWxpZGF0aW9u IGVycm9ycyBhbmQgY29udGludWUgd2l0aCBtZXNzYWdlIHRyYW5zbWlzc2lvbi4gSeKAmW0gbm90 IHN1cmUgaWYgdGhhdCBzaG91bGQgYmUgbm90ZWQgaGVyZSwgb3IgbGVmdCB0byB0aGUgcmVhZGVy IHRvIGdsZWFuIGZyb20gUkZDODQ2MS4NCg0KSeKAmW0gbm90IHN1cmUgaG93IHRvIGZyYW1lIHRo aXMgaW4gdGhlIHBhcmFncmFwaCBiZWxvdywgYnV0IHdoZW4gYSBzZXJ2ZXIgZGVwbG95cyBNVEEt U1RTL0RBTkUsIHRoZSBtZWNoYW5pc21zIGFyZSBzdGlsbCBkZXBlbmRlbnQgb24gdGhlIGNsaWVu dCBpbXBsZW1lbnRpbmcgb25lL2JvdGggb2YgdGhlc2UgdG8gZW5zdXJlIHRoZSBwcm9wZXIgcHJv dGVjdGlvbnMgYXJlIGluIHBsYWNlLiAgSWYgdGhlIGNsaWVudCBkb2VzIG5vdCB1bmRlcnN0YW5k IE1UQS1TVFMvREFORSwgdGhleeKAmWxsIHVzZSBPcHBvcnR1bmlzdGljIFRMUyAob3IgY2xlYXIt dGV4dCBpZiB0aGF0IGZhaWxzKSB3aGVuIHRyYW5zbWl0dGluZyB0aGUgbWVzc2FnZS4NCg0KLS0N CkFsZXggQnJvdG1hbg0KU3IuIEVuZ2luZWVyLCBBbnRpLUFidXNlICYgTWVzc2FnaW5nIFBvbGlj eQ0KQ29tY2FzdA0KDQpGcm9tOiBFbWFpbGNvcmUgPGVtYWlsY29yZS1ib3VuY2VzQGlldGYub3Jn PiBPbiBCZWhhbGYgT2YgVG9kZCBIZXJyDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI1LCAyMDIy IDQ6MjIgUE0NClRvOiBlbWFpbGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRW1haWxjb3Jl XSBUaWNrZXQgIzU0IC0gVGFrZSBUd28gLSBBdXRoZW50aWNhdGlvbiBhbmQgRW5jcnlwdGlvbiBm b3IgQS9TDQoNCkhlcmUgaXMgbXkgcG9zdC1pbnRlcmltIHN1Z2dlc3Rpb24gZm9yIHRleHQgdG8g dXNlIGluIHRoZSBBL1MgdG8gY292ZXIgdGhlIHRvcGljcyBvZiBDb25maWRlbnRpYWxpdHkgYW5k IEF1dGhlbnRpY2F0aW9uDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PSBjdXQgaGVyZSA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KDQoNCjUuIENvbmZpZGVudGlhbGl0eSBhbmQgQXV0aGVudGljYXRpb24g d2l0aCBTTVRQDQoNClRoZSBkZWZhdWx0IG1ldGhvZCBmb3IgdHJhbnNtaXR0aW5nIHRleHQgdXNp bmcgdGhlIFNNVFAgcHJvdG9jb2wgaXMgdG8gZG8gc28g4oCcaW4gdGhlIGNsZWFy4oCdLiBZZWFy cyBvZiBvcGVyYXRpb25hbCBleHBlcmllbmNlIGhhdmUgc2hvd24gdGhhdCBzdWNoIHRyYW5zbWlz c2lvbiBleHBvc2VzIHRoZSBtZXNzYWdlIHRvIGVhc3kgY29tcHJvbWlzZS4gVG8gbWl0aWdhdGUg dGhpcyByaXNrLCBTTVRQIGhhcyBldm9sdmVkIG92ZXIgdGhlIHllYXJzIHRvIGFsbG93IGZvciBl YXN5IGludGVncmF0aW9uIGFuZCBzdXBwb3J0IG9mIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAo VExTIC0gUkZDODQ0NikgdG8gcHJvdmlkZSBib3RoIGNvbmZpZGVudGlhbGl0eSBhbmQgYXV0aGVu dGljYXRpb24gaW4gdGhlIHRyYW5zbWlzc2lvbiBvZiBtZXNzYWdlcy4gVGhpcyBzZWN0aW9uIHdp bGwgZGlzY3VzcyB0aG9zZSB0b3BpY3MgYW5kIHRoZWlyIG1vc3QgY29tbW9uIHVzZXMuDQoNCkl0 IGlzIGltcG9ydGFudCB0aGF0IHRoZSByZWFkZXIgdW5kZXJzdGFuZHMgd2hhdCBpcyBtZWFudCBi eSB0aGUgdGVybXMg4oCcQXV0aGVudGljYXRpb27igJ0gYW5kIOKAnENvbmZpZGVudGlhbGl0eeKA nSwgYW5kIGZvciB0aGF0IHdlIHdpbGwgYm9ycm93IGRpcmVjdGx5IGZyb20gUkZDODQ0Ni4NCg0K ICAqICAgQXV0aGVudGljYXRpb24gaXMgdGhlIHByb2Nlc3Mgb2YgZXN0YWJsaXNoaW5nIHRoZSBp ZGVudGl0eSBvZiB0aGUgZW5kcG9pbnRzIChlLmcuLCB0aGUgaG9zdHMpIG9mIHRoZSBTTVRQIHRy YW5zYWN0aW9uDQogICogICBUaGUgdGVybSDigJxjb25maWRlbnRpYWxpdHnigJ0gZGVzY3JpYmVz IGEgc3RhdGUgd2hlcmUgdGhlIGRhdGEgKGkuZS4sIHRoZSBtZXNzYWdlKSBpcyB0cmFuc21pdHRl ZCBpbiBhIHdheSB0aGF0IGl0IGlzIG9ubHkgdmlzaWJsZSB0byB0aGUgZW5kcG9pbnRzLg0KDQpJ dCBpcyBub3QgdW5jb21tb24gZm9yIGltcGxlbWVudGVycyB0byB1c2UgdGhlIHRlcm0g4oCcZW5j cnlwdGlvbuKAnSB0byBtZWFuIOKAnGNvbmZpZGVudGlhbGl0eeKAnSwgYnV0IHRoaXMgaXMgbm90 IHF1aXRlIGNvcnJlY3QuIFJhdGhlciwgZW5jcnlwdGlvbiB1c2luZyBUTFMgaXMgdGhlIGN1cnJl bnQgbWV0aG9kIGJ5IHdoaWNoIGNvbmZpZGVudGlhbGl0eSBpcyBhY2hpZXZlZCB3aXRoIFNNVFAs IGJ1dCB0aGF0IGRvZXMgbm90IG1lYW4gdGhhdCBmdXR1cmUgbWV0aG9kcyBtaWdodCBub3QgYmUg ZGV2ZWxvcGVkLg0KDQo1LjEgT3B0aW9uYWwgQ29uZmlkZW50aWFsaXR5DQoNClRoZSBtb3N0IGNv bW1vbiBpbXBsZW1lbnRhdGlvbiBvZiBtZXNzYWdlIGNvbmZpZGVudGlhbGl0eSBpcyB3aGF04oCZ cyBrbm93biBhcyDigJxvcHBvcnR1bmlzdGljIFRMU+KAnSwgd2hpY2ggaXMgZnJlcXVlbnRseSBy ZWZlcnJlZCB0byBhcyDigJxvcHBvcnR1bmlzdGljIGVuY3J5cHRpb27igJ0uIFdpdGggdGhpcyBt ZXRob2QsIGFuIFNNVFAgc2VydmVyIGFubm91bmNlcyBpbiBpdHMgZ3JlZXRpbmcgdGhhdCBpdCBp cyBjYXBhYmxlIG9mIHN1cHBvcnRpbmcgVExTIGVuY3J5cHRpb24gdGhyb3VnaCB0aGUgcHJlc2Vu Y2Ugb2YgdGhlIOKAnFNUQVJUVExT4oCdIGtleXdvcmQuIFRoZSBTTVRQIGNsaWVudCB0aGVuIGF0 dGVtcHRzIHRvIG5lZ290aWF0ZSBhbiBlbmNyeXB0ZWQgY29ubmVjdGlvbiwgYW5kIGlmIHN1Y2Nl c3NmdWwsIHRyYW5zbWl0cyB0aGUgbWVzc2FnZSBpbiBlbmNyeXB0ZWQgZm9ybTsgdGhlcmUgaXMg bm8gZ3VhcmFudGVlIHRoYXQgdGhlIG1lc3NhZ2Ugd2lsbCBiZSBzdG9yZWQgaW4gZW5jcnlwdGVk IGZhc2hpb24gYXQgaXRzIGRlc3RpbmF0aW9uLCBhbmQgaW4gZmFjdCwgc3RvcmFnZSBpbiBwbGFp biB0ZXh0IHNob3VsZCBiZSBleHBlY3RlZC4gSWYgbmVnb3RpYXRpb24gZmFpbHMsIHRoZSBjbGll bnQgZmFsbHMgYmFjayB0byBzZW5kaW5nIHRoZSBtZXNzYWdlIGluIGNsZWFyIHRleHQuDQoNCk9w cG9ydHVuaXN0aWMgVExTIGlzIGNvbmZpZGVudGlhbGl0eSB3aXRob3V0IGF1dGhlbnRpY2F0aW9u LCBiZWNhdXNlIG5vIGVmZm9ydCBpcyBtYWRlIHRvIGF1dGhlbnRpY2F0ZSB0aGUgZW5kcG9pbnRz IG9mIHRoZSB0cmFuc21pc3Npb24sIGFuZCBpdCBpcyBvcHRpb25hbCBjb25maWRlbnRpYWxpdHkg ZHVlIHRvIHRoZSBhYmlsaXR5IHRvIGZhbGwgYmFjayB0byB0cmFuc21pc3Npb24gaW4gdGhlIGNs ZWFyIGlmIGEgc2VjdXJlIGNvbm5lY3Rpb24gY2Fubm90IGJlIGVzdGFibGlzaGVkLiBUaGF0IHNh aWQsIG1vc3QgbW9kZXJuIGltcGxlbWVudGF0aW9ucyBvZiB0aGUgU01UUCBwcm90b2NvbCBzdXBw b3J0IHRoaXMgbWV0aG9kLCBlc3BlY2lhbGx5IGF0IHRoZSBsYXJnZXN0IG1haWxib3ggcHJvdmlk ZXJzLCBhbmQgc28gdGhlIHZhc3QgbWFqb3JpdHkgb2YgZW1haWwgdHJhZmZpYyBpcyBlbmNyeXB0 ZWQgZHVyaW5nIGl0cyB0aW1lIHRyYW5zaXRpbmcgZnJvbSB0aGUgY2xpZW50IHRvIHRoZSBzZXJ2 ZXIuDQoNCjUuMiBSZXF1aXJlZCBDb25maWRlbnRpYWxpdHksIHdpdGggQXV0aGVudGljYXRpb24N Cg0KVHdvIHByb3RvY29scyBleGlzdCB0aGF0IG1vdmUgbWVzc2FnZSBjb25maWRlbnRpYWxpdHkg ZnJvbSBvcHRpb25hbCB0byByZXF1aXJlZCAtIE1UQS1TVFMgW1JGQzg0NjFdIGFuZCBEQU5FIGZv ciBTTVRQIFtSRkM3NjcyXS4gV2hpbGUgdGhleSBkaWZmZXIgaW4gdGhlaXIgaW1wbGVtZW50YXRp b24gZGV0YWlscywgU01UUCBzZXJ2ZXJzIHJlbHlpbmcgb24gZWl0aGVyIHByb3RvY29sIGFyZSBz dGF0aW5nIHRoYXQgdGhleSBvbmx5IGFjY2VwdCBtYWlsIGlmIHRoZSB0cmFuc21pc3Npb24gY2Fu IGJlIGVuY3J5cHRlZCB3aXRoIFRMUywgYW5kIGEgZmFpbHVyZSB0byBuZWdvdGlhdGUgYSBzZWN1 cmUgY29ubmVjdGlvbiBNVVNUIHJlc3VsdCBpbiB0aGUgU01UUCBjbGllbnQgcmVmdXNpbmcgdG8g dHJhbnNtaXQgdGhlIG1lc3NhZ2UuIFN1cHBvcnQgZm9yIGJvdGggcHJvdG9jb2xzIGlzIHdpZGVu aW5nLCBidXQgaXMgbm90IHlldCBtYW5kYXRvcnkuDQoNClRoZXNlIHR3byBwcm90b2NvbHMgZGlm ZmVyIGZyb20gT3Bwb3J0dW5pc3RpYyBUTFMgbm90IG9ubHkgYmVjYXVzZSB0aGV5IHJlcXVpcmUg bWVzc2FnZSBjb25maWRlbnRpYWxpdHksIGJ1dCBhbHNvIGJlY2F1c2UgdGhleSByZXF1aXJlIGF1 dGhlbnRpY2F0aW9uLg0KDQo1LjMgTWVzc2FnZS1MZXZlbCBBdXRoZW50aWNhdGlvbg0KDQpQcm90 b2NvbHMgZXhpc3QgdG8gYWxsb3cgZm9yIGF1dGhlbnRpY2F0aW9uIG9mIGRpZmZlcmVudCBpZGVu dGl0aWVzIGFzc29jaWF0ZWQgd2l0aCBhbiBlbWFpbCBtZXNzYWdlIC0gU1BGIFtSRkM3MjA4XSBh bmQgREtJTSBbUkZDNjM3Nl0uIEEgdGhpcmQgcHJvdG9jb2wsIERNQVJDIFtSRkM3NDg5XSwgcmVs aWVzIG9uIFNQRiBhbmQgREtJTSB0byBhbGxvdyBmb3IgdmFsaWRhdGlvbiBvZiB0aGUgZG9tYWlu IGluIHRoZSB2aXNpYmxlIEZyb20gaGVhZGVyLCBhbmQgYSBmb3VydGgsIEFSQyBbUkZDODYxN10s IHByb3ZpZGVzIGEgd2F5IGZvciBlYWNoIGhvcCB0byByZWNvcmQgcmVzdWx0cyBvZiBhdXRoZW50 aWNhdGlvbiBjaGVja3MgcGVyZm9ybWVkIGF0IHRoYXQgaG9wLg0KDQpBbGwgb2YgdGhlc2UgYXJl IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQsIGFzIHRoZXkgYXJlIG91dHNpZGUg dGhlIHNjb3BlIG9mIHRoZSBTTVRQIHByb3RvY29sLiBUaGV5IGRlYWwgd2l0aCBhdXRoZW50aWNh dGlvbiBvZiB0aGUgbWVzc2FnZSwgbm90IHRoZSBlbmRwb2ludHMuDQoNCjUuNCBNZXNzYWdlLUxl dmVsIENvbmZpZGVudGlhbGl0eQ0KDQpUaGUgbW9yZSBzb3BoaXN0aWNhdGVkIGFtb25nIHRoZSBl bmQgdXNlcnMgb2YgU01UUCBtYXkgdGFrZSBhZHZhbnRhZ2Ugb2YgdmFyaW91cyB0aGlyZCBwYXJ0 eSBzb2x1dGlvbnMgdGhhdCBhcmUgZGVzaWduZWQgdG8gZW5jcnlwdCB0aGVpciBtZXNzYWdlIGlt bWVkaWF0ZWx5IHVwb24gbGVhdmluZyB0aGUgTVVBLCBhbmQgdG8gZG8gc28gaW4gc3VjaCBhIHdh eSB0aGF0IG9ubHkgdGhlIGluZGl2aWR1YWwgbWVzc2FnZSByZWNpcGllbnQocykgY2FuIGRlY3J5 cHQgdGhlIG1lc3NhZ2UuIFRoZSBzb2x1dGlvbnMgKGUuZy4sIFBHUCkgYXJlIHRvbyBudW1lcm91 cyB0byBsaXN0IGhlcmUsIGFuZCBhcyB0aGV5IG9wZXJhdGUgYXQgdGhlIG1lc3NhZ2UgbGV2ZWwg cmF0aGVyIHRoYW4gdGhlIFNNVFAgcHJvdG9jb2wgbGV2ZWwsIHRoZXkgYXJlIG91dCBvZiBzY29w ZSBmb3IgdGhpcyBkb2N1bWVudC4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PSBjdXQgaGVyZSA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KDQpIYXZlIGF0IGl0Li4uDQoNCg0KLS0NClRvZGQgSGVyciB8IFRl Y2huaWNhbCBEaXJlY3RvciwgU3RhbmRhcmRzIGFuZCBFY29zeXN0ZW0NCmU6IHRvZGQuaGVyckB2 YWxpbWFpbC5jb208bWFpbHRvOnRvZGQuaGVyckB2YWxpbWFpbC5jb20+DQptOiA3MDMuMjIwLjQx NTMNCltodHRwczovL2hvc3RlZC1wYWNrYWdlcy5zMy11cy13ZXN0LTEuYW1hem9uYXdzLmNvbS9W YWxpbWFpbCtMb2dvLnBuZ10NCg0KVGhpcyBlbWFpbCBhbmQgYWxsIGRhdGEgdHJhbnNtaXR0ZWQg d2l0aCBpdCBjb250YWlucyBjb25maWRlbnRpYWwgYW5kL29yIHByb3ByaWV0YXJ5IGluZm9ybWF0 aW9uIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiBpbmRpdmlkdWFsKHMpIGF1dGhvcml6 ZWQgdG8gcmVjZWl2ZSBpdC4gSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgYW5kIGF1dGhvcml6 ZWQgcmVjaXBpZW50IHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIG9mIGFueSB1c2UsIGRpc2Nsb3N1 cmUsIGNvcHlpbmcgb3IgZGlzdHJpYnV0aW9uIG9mIHRoZSBpbmZvcm1hdGlvbiBpbmNsdWRlZCBp biB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIFBs ZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBieSByZXBseWluZyB0byB0aGlzIGVt YWlsIGFuZCB0aGVuIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLg0K --_000_MN2PR11MB435163904FA5E4ECD9336CBBF7209MN2PR11MB4351namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjE5MzY1NDk4MDA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0x MjQ0NDgxMTkyO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3Jk Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qb3Rl bnRpYWwgbnVhbmNlIHdpdGggTVRBLVNUUywgdGhlcmUgaXMgYSDigJx0ZXN0aW5n4oCdIG1vZGUg d2hpY2ggZG9lcyBhbGxvdyBmb3Igc2VuZGVycyB0byBpZ25vcmUgVExTIHZhbGlkYXRpb24gZXJy b3JzIGFuZCBjb250aW51ZSB3aXRoIG1lc3NhZ2UgdHJhbnNtaXNzaW9uLiBJ4oCZbSBub3Qgc3Vy ZSBpZiB0aGF0IHNob3VsZCBiZSBub3RlZCBoZXJlLCBvciBsZWZ0IHRvIHRoZSByZWFkZXIgdG8g Z2xlYW4gZnJvbQ0KIFJGQzg0NjEuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIG5vdCBz dXJlIGhvdyB0byBmcmFtZSB0aGlzIGluIHRoZSBwYXJhZ3JhcGggYmVsb3csIGJ1dCB3aGVuIGEg c2VydmVyIGRlcGxveXMgTVRBLVNUUy9EQU5FLCB0aGUgbWVjaGFuaXNtcyBhcmUgc3RpbGwgZGVw ZW5kZW50IG9uIHRoZSBjbGllbnQgaW1wbGVtZW50aW5nIG9uZS9ib3RoIG9mIHRoZXNlIHRvIGVu c3VyZSB0aGUgcHJvcGVyIHByb3RlY3Rpb25zIGFyZSBpbiBwbGFjZS4mbmJzcDsgSWYgdGhlIGNs aWVudA0KIGRvZXMgbm90IHVuZGVyc3RhbmQgTVRBLVNUUy9EQU5FLCB0aGV54oCZbGwgdXNlIE9w cG9ydHVuaXN0aWMgVExTIChvciBjbGVhci10ZXh0IGlmIHRoYXQgZmFpbHMpIHdoZW4gdHJhbnNt aXR0aW5nIHRoZSBtZXNzYWdlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxleCBCcm90bWFuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Tci4gRW5naW5lZXIsIEFudGktQWJ1c2UgJmFtcDsgTWVzc2Fn aW5nIFBvbGljeTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29tY2FzdDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBFbWFpbGNvcmUgJmx0O2VtYWls Y29yZS1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5Ub2RkIEhlcnI8 YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSmFudWFyeSAyNSwgMjAyMiA0OjIyIFBNPGJyPg0K PGI+VG86PC9iPiBlbWFpbGNvcmVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtF bWFpbGNvcmVdIFRpY2tldCAjNTQgLSBUYWtlIFR3byAtIEF1dGhlbnRpY2F0aW9uIGFuZCBFbmNy eXB0aW9uIGZvciBBL1M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssc2Fucy1zZXJpZiI+SGVyZSBpcyBteSBwb3N0LWludGVyaW0gc3VnZ2VzdGlvbiBmb3Ig dGV4dCB0byB1c2UgaW4gdGhlIEEvUyB0byBjb3ZlciB0aGUgdG9waWNzIG9mIENvbmZpZGVudGlh bGl0eSBhbmQgQXV0aGVudGljYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0gY3V0IGhlcmUgPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBp bjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBpbiI+ DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzU5NTk1OSI+NS4gQ29uZmlkZW50aWFsaXR5IGFuZCBBdXRoZW50aWNhdGlvbiB3 aXRoIFNNVFA8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4t bGVmdDowaW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM1OTU5NTkiPlRoZSBkZWZhdWx0IG1ldGhvZCBmb3IgdHJhbnNtaXR0 aW5nIHRleHQgdXNpbmcgdGhlIFNNVFAgcHJvdG9jb2wgaXMgdG8gZG8gc28g4oCcaW4gdGhlIGNs ZWFy4oCdLiBZZWFycyBvZiBvcGVyYXRpb25hbCBleHBlcmllbmNlIGhhdmUgc2hvd24gdGhhdCBz dWNoIHRyYW5zbWlzc2lvbiBleHBvc2VzIHRoZSBtZXNzYWdlIHRvIGVhc3kgY29tcHJvbWlzZS4N CiBUbyBtaXRpZ2F0ZSB0aGlzIHJpc2ssIFNNVFAgaGFzIGV2b2x2ZWQgb3ZlciB0aGUgeWVhcnMg dG8gYWxsb3cgZm9yIGVhc3kgaW50ZWdyYXRpb24gYW5kIHN1cHBvcnQgb2YgVHJhbnNwb3J0IExh eWVyIFNlY3VyaXR5IChUTFMgLSBSRkM4NDQ2KSB0byBwcm92aWRlIGJvdGggY29uZmlkZW50aWFs aXR5IGFuZCBhdXRoZW50aWNhdGlvbiBpbiB0aGUgdHJhbnNtaXNzaW9uIG9mIG1lc3NhZ2VzLiBU aGlzIHNlY3Rpb24gd2lsbCBkaXNjdXNzIHRob3NlDQogdG9waWNzIGFuZCB0aGVpciBtb3N0IGNv bW1vbiB1c2VzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxl ZnQ6MGluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojNTk1OTU5Ij5JdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgcmVhZGVyIHVu ZGVyc3RhbmRzIHdoYXQgaXMgbWVhbnQgYnkgdGhlIHRlcm1zIOKAnEF1dGhlbnRpY2F0aW9u4oCd IGFuZCDigJxDb25maWRlbnRpYWxpdHnigJ0sIGFuZCBmb3IgdGhhdCB3ZSB3aWxsIGJvcnJvdyBk aXJlY3RseSBmcm9tIFJGQzg0NDYuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgc3R5bGU9ImNvbG9yOiM1OTU5NTk7bWFy Z2luLXRvcDowaW47bWFyZ2luLWJvdHRvbTowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7dmVy dGljYWwtYWxpZ246YmFzZWxpbmU7Zm9udC12YXJpYW50LW51bWVyaWM6bm9ybWFsO2ZvbnQtdmFy aWFudC1lYXN0LWFzaWFuOm5vcm1hbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkF1dGhlbnRpY2F0aW9uIGlzIHRoZSBwcm9jZXNzIG9m IGVzdGFibGlzaGluZyB0aGUgaWRlbnRpdHkgb2YgdGhlIGVuZHBvaW50cyAoZS5nLiwgdGhlIGhv c3RzKSBvZiB0aGUgU01UUCB0cmFuc2FjdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIHN0 eWxlPSJjb2xvcjojNTk1OTU5O21hcmdpbi10b3A6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21z by1saXN0OmwwIGxldmVsMSBsZm8xO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO2ZvbnQtdmFyaWFu dC1udW1lcmljOm5vcm1hbDtmb250LXZhcmlhbnQtZWFzdC1hc2lhbjpub3JtYWwiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgdGVy bSDigJxjb25maWRlbnRpYWxpdHnigJ0gZGVzY3JpYmVzIGEgc3RhdGUgd2hlcmUgdGhlIGRhdGEg KGkuZS4sIHRoZSBtZXNzYWdlKSBpcyB0cmFuc21pdHRlZCBpbiBhIHdheSB0aGF0IGl0IGlzIG9u bHkgdmlzaWJsZSB0byB0aGUgZW5kcG9pbnRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4N CjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MGluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTk1OTU5Ij5JdCBpcyBub3Qg dW5jb21tb24gZm9yIGltcGxlbWVudGVycyB0byB1c2UgdGhlIHRlcm0g4oCcZW5jcnlwdGlvbuKA nSB0byBtZWFuIOKAnGNvbmZpZGVudGlhbGl0eeKAnSwgYnV0IHRoaXMgaXMgbm90IHF1aXRlIGNv cnJlY3QuIFJhdGhlciwgZW5jcnlwdGlvbiB1c2luZyBUTFMgaXMgdGhlIGN1cnJlbnQgbWV0aG9k IGJ5IHdoaWNoIGNvbmZpZGVudGlhbGl0eQ0KIGlzIGFjaGlldmVkIHdpdGggU01UUCwgYnV0IHRo YXQgZG9lcyBub3QgbWVhbiB0aGF0IGZ1dHVyZSBtZXRob2RzIG1pZ2h0IG5vdCBiZSBkZXZlbG9w ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDow aW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW4i Pg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM1OTU5NTkiPjUuMSBPcHRpb25hbCBDb25maWRlbnRpYWxpdHk8L3NwYW4+PC9i PjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW4iPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1 OTU5NTkiPlRoZSBtb3N0IGNvbW1vbiBpbXBsZW1lbnRhdGlvbiBvZiBtZXNzYWdlIGNvbmZpZGVu dGlhbGl0eSBpcyB3aGF04oCZcyBrbm93biBhcyDigJxvcHBvcnR1bmlzdGljIFRMU+KAnSwgd2hp Y2ggaXMgZnJlcXVlbnRseSByZWZlcnJlZCB0byBhcyDigJxvcHBvcnR1bmlzdGljIGVuY3J5cHRp b27igJ0uIFdpdGggdGhpcyBtZXRob2QsIGFuIFNNVFAgc2VydmVyIGFubm91bmNlcw0KIGluIGl0 cyBncmVldGluZyB0aGF0IGl0IGlzIGNhcGFibGUgb2Ygc3VwcG9ydGluZyBUTFMgZW5jcnlwdGlv biB0aHJvdWdoIHRoZSBwcmVzZW5jZSBvZiB0aGUg4oCcU1RBUlRUTFPigJ0ga2V5d29yZC4gVGhl IFNNVFAgY2xpZW50IHRoZW4gYXR0ZW1wdHMgdG8gbmVnb3RpYXRlIGFuIGVuY3J5cHRlZCBjb25u ZWN0aW9uLCBhbmQgaWYgc3VjY2Vzc2Z1bCwgdHJhbnNtaXRzIHRoZSBtZXNzYWdlIGluIGVuY3J5 cHRlZCBmb3JtOyB0aGVyZSBpcyBubyBndWFyYW50ZWUNCiB0aGF0IHRoZSBtZXNzYWdlIHdpbGwg YmUgc3RvcmVkIGluIGVuY3J5cHRlZCBmYXNoaW9uIGF0IGl0cyBkZXN0aW5hdGlvbiwgYW5kIGlu IGZhY3QsIHN0b3JhZ2UgaW4gcGxhaW4gdGV4dCBzaG91bGQgYmUgZXhwZWN0ZWQuIElmIG5lZ290 aWF0aW9uIGZhaWxzLCB0aGUgY2xpZW50IGZhbGxzIGJhY2sgdG8gc2VuZGluZyB0aGUgbWVzc2Fn ZSBpbiBjbGVhciB0ZXh0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFy Z2luLWxlZnQ6MGluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNTk1OTU5Ij5PcHBvcnR1bmlzdGljIFRMUyBpcyBjb25maWRl bnRpYWxpdHkgd2l0aG91dCBhdXRoZW50aWNhdGlvbiwgYmVjYXVzZSBubyBlZmZvcnQgaXMgbWFk ZSB0byBhdXRoZW50aWNhdGUgdGhlIGVuZHBvaW50cyBvZiB0aGUgdHJhbnNtaXNzaW9uLCBhbmQg aXQgaXMgb3B0aW9uYWwgY29uZmlkZW50aWFsaXR5IGR1ZSB0byB0aGUgYWJpbGl0eSB0byBmYWxs DQogYmFjayB0byB0cmFuc21pc3Npb24gaW4gdGhlIGNsZWFyIGlmIGEgc2VjdXJlIGNvbm5lY3Rp b24gY2Fubm90IGJlIGVzdGFibGlzaGVkLiBUaGF0IHNhaWQsIG1vc3QgbW9kZXJuIGltcGxlbWVu dGF0aW9ucyBvZiB0aGUgU01UUCBwcm90b2NvbCBzdXBwb3J0IHRoaXMgbWV0aG9kLCBlc3BlY2lh bGx5IGF0IHRoZSBsYXJnZXN0IG1haWxib3ggcHJvdmlkZXJzLCBhbmQgc28gdGhlIHZhc3QgbWFq b3JpdHkgb2YgZW1haWwgdHJhZmZpYyBpcyBlbmNyeXB0ZWQNCiBkdXJpbmcgaXRzIHRpbWUgdHJh bnNpdGluZyBmcm9tIHRoZSBjbGllbnQgdG8gdGhlIHNlcnZlci4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBpbiI+DQo8Yj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU5NTk1 OSI+NS4yIFJlcXVpcmVkIENvbmZpZGVudGlhbGl0eSwgd2l0aCBBdXRoZW50aWNhdGlvbjwvc3Bh bj48L2I+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBpbiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzU5NTk1OSI+VHdvIHByb3RvY29scyBleGlzdCB0aGF0IG1vdmUgbWVzc2FnZSBjb25maWRl bnRpYWxpdHkgZnJvbSBvcHRpb25hbCB0byByZXF1aXJlZCAtIE1UQS1TVFMgW1JGQzg0NjFdIGFu ZCBEQU5FIGZvciBTTVRQIFtSRkM3NjcyXS4gV2hpbGUgdGhleSBkaWZmZXIgaW4gdGhlaXIgaW1w bGVtZW50YXRpb24gZGV0YWlscywgU01UUCBzZXJ2ZXJzIHJlbHlpbmcNCiBvbiBlaXRoZXIgcHJv dG9jb2wgYXJlIHN0YXRpbmcgdGhhdCB0aGV5IG9ubHkgYWNjZXB0IG1haWwgaWYgdGhlIHRyYW5z bWlzc2lvbiBjYW4gYmUgZW5jcnlwdGVkIHdpdGggVExTLCBhbmQgYSBmYWlsdXJlIHRvIG5lZ290 aWF0ZSBhIHNlY3VyZSBjb25uZWN0aW9uIE1VU1QgcmVzdWx0IGluIHRoZSBTTVRQIGNsaWVudCBy ZWZ1c2luZyB0byB0cmFuc21pdCB0aGUgbWVzc2FnZS4gU3VwcG9ydCBmb3IgYm90aCBwcm90b2Nv bHMgaXMgd2lkZW5pbmcsDQogYnV0IGlzIG5vdCB5ZXQgbWFuZGF0b3J5Ljwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MGluIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTk1OTU5Ij5U aGVzZSB0d28gcHJvdG9jb2xzIGRpZmZlciBmcm9tIE9wcG9ydHVuaXN0aWMgVExTIG5vdCBvbmx5 IGJlY2F1c2UgdGhleSByZXF1aXJlIG1lc3NhZ2UgY29uZmlkZW50aWFsaXR5LCBidXQgYWxzbyBi ZWNhdXNlIHRoZXkgcmVxdWlyZSBhdXRoZW50aWNhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBpbiI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU5NTk1OSI+NS4zIE1l c3NhZ2UtTGV2ZWwgQXV0aGVudGljYXRpb248L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1OTU5NTkiPlByb3RvY29scyBleGlz dCB0byBhbGxvdyBmb3IgYXV0aGVudGljYXRpb24gb2YgZGlmZmVyZW50IGlkZW50aXRpZXMgYXNz b2NpYXRlZCB3aXRoIGFuIGVtYWlsIG1lc3NhZ2UgLSBTUEYgW1JGQzcyMDhdIGFuZCBES0lNIFtS RkM2Mzc2XS4gQSB0aGlyZCBwcm90b2NvbCwgRE1BUkMgW1JGQzc0ODldLCByZWxpZXMgb24gU1BG IGFuZCBES0lNIHRvDQogYWxsb3cgZm9yIHZhbGlkYXRpb24gb2YgdGhlIGRvbWFpbiBpbiB0aGUg dmlzaWJsZSBGcm9tIGhlYWRlciwgYW5kIGEgZm91cnRoLCBBUkMgW1JGQzg2MTddLCBwcm92aWRl cyBhIHdheSBmb3IgZWFjaCBob3AgdG8gcmVjb3JkIHJlc3VsdHMgb2YgYXV0aGVudGljYXRpb24g Y2hlY2tzIHBlcmZvcm1lZCBhdCB0aGF0IGhvcC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0 b206MTIuMHB0O21hcmdpbi1sZWZ0OjBpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU5NTk1OSI+QWxsIG9mIHRoZXNlIGFy ZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LCBhcyB0aGV5IGFyZSBvdXRzaWRl IHRoZSBzY29wZSBvZiB0aGUgU01UUCBwcm90b2NvbC4gVGhleSBkZWFsIHdpdGggYXV0aGVudGlj YXRpb24gb2YgdGhlIG1lc3NhZ2UsIG5vdCB0aGUgZW5kcG9pbnRzLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MGluIj4NCjxiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTk1OTU5Ij41 LjQgTWVzc2FnZS1MZXZlbCBDb25maWRlbnRpYWxpdHk8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1OTU5NTkiPlRoZSBtb3Jl IHNvcGhpc3RpY2F0ZWQgYW1vbmcgdGhlIGVuZCB1c2VycyBvZiBTTVRQIG1heSB0YWtlIGFkdmFu dGFnZSBvZiB2YXJpb3VzIHRoaXJkIHBhcnR5IHNvbHV0aW9ucyB0aGF0IGFyZSBkZXNpZ25lZCB0 byBlbmNyeXB0IHRoZWlyIG1lc3NhZ2UgaW1tZWRpYXRlbHkgdXBvbiBsZWF2aW5nIHRoZSBNVUEs IGFuZCB0byBkbyBzbyBpbiBzdWNoDQogYSB3YXkgdGhhdCBvbmx5IHRoZSBpbmRpdmlkdWFsIG1l c3NhZ2UgcmVjaXBpZW50KHMpIGNhbiBkZWNyeXB0IHRoZSBtZXNzYWdlLiBUaGUgc29sdXRpb25z IChlLmcuLCBQR1ApIGFyZSB0b28gbnVtZXJvdXMgdG8gbGlzdCBoZXJlLCBhbmQgYXMgdGhleSBv cGVyYXRlIGF0IHRoZSBtZXNzYWdlIGxldmVsIHJhdGhlciB0aGFuIHRoZSBTTVRQIHByb3RvY29s IGxldmVsLCB0aGV5IGFyZSBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZG9jdW1lbnQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09IGN1dCBoZXJlID09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5IYXZlIGF0IGl0 Li4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+VG9kZCBIZXJyDQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PnwgVGVjaG5pY2FsIERpcmVjdG9yLCBTdGFuZGFyZHMgYW5kIEVjb3N5c3RlbTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmU6PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj4NCjxhIGhyZWY9Im1haWx0bzp0b2RkLmhlcnJAdmFsaW1h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dG9kZC5oZXJyQHZhbGltYWlsLmNvbTwvYT4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5tOjwvYj4g NzAzLjIyMC40MTUzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMTc1IiBoZWlnaHQ9IjQzIiBzdHlsZT0id2lkdGg6MS44 MjVpbjtoZWlnaHQ6LjQ1aW4iIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iaHR0cHM6Ly9ob3N0ZWQt cGFja2FnZXMuczMtdXMtd2VzdC0xLmFtYXpvbmF3cy5jb20vVmFsaW1haWwmIzQzO0xvZ28ucG5n Ij48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO2JhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5UaGlzIGVtYWlsIGFuZCBhbGwgZGF0YSB0cmFu c21pdHRlZCB3aXRoIGl0IGNvbnRhaW5zIGNvbmZpZGVudGlhbCBhbmQvb3IgcHJvcHJpZXRhcnkg aW5mb3JtYXRpb24gaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIGluZGl2aWR1YWwocykg YXV0aG9yaXplZA0KIHRvIHJlY2VpdmUgaXQuIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIGFu ZCBhdXRob3JpemVkIHJlY2lwaWVudCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCBvZiBhbnkgdXNl LCBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGUgaW5mb3JtYXRpb24g aW5jbHVkZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVu bGF3ZnVsLiBQbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXINCiBieSByZXBseWlu ZyB0byB0aGlzIGVtYWlsIGFuZCB0aGVuIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_MN2PR11MB435163904FA5E4ECD9336CBBF7209MN2PR11MB4351namp_-- From nobody Wed Jan 26 13:49: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 3E8F83A23F7; Wed, 26 Jan 2022 13:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, 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 u89_DrxGAF1r; Wed, 26 Jan 2022 13:49:37 -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 B01673A23C2; Wed, 26 Jan 2022 13:49:26 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nCqAP-000BxI-BX; Wed, 26 Jan 2022 16:49:25 -0500 Date: Wed, 26 Jan 2022 16:49:18 -0500 From: John C Klensin To: Todd Herr , emailcore@ietf.org Message-ID: 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 - Take Two - Authentication and Encryption for A/S 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, 26 Jan 2022 21:49:45 -0000 --On Monday, January 24, 2022 18:18 -0500 Todd Herr wrote: > Greetings. > > Thanks to all who attended the interim on January 21. > > I've listened to the recording a couple of times and reviewed > the notes ( > https://notes.ietf.org/notes-emailcore-interim-jan-2022) in an > effort to propose better text for the subject topic. Before I > really start writing, though, I want to throw the following > outline to the group to see if it's directionally correct. > > - Define encryption (transmitting messages in ciphertext, > rather than in the clear, to provide privacy of > communication) and authentication (establishing the > identity of the hosts involved in the transaction), both > done using TLS. > - Discuss opportunistic TLS (sometimes called opportunistic > encryption) and mention that it's encryption without > authentication. - Discuss MTA-STS and DANE for SMTP, which > are both encryption with authentication. > - Mention SPF, DKIM, DMARC, and ARC, which are > authentication protocols, but not the kind of > authentication we're talking about here. - Mention private > use message encryption (e.g., PGP) but only for the > purposes of mentioning that it's out of scope for the A/S > > Appreciate your collective feedback, to include suggested text > for the definitions of encryption and authentication. Todd, (personal opinion only) I've read your later note, but think I should respond to this one. First, I agree, plus or minus wordsmithing, with Dave Crocker's suggestions. However, if we are going down this path, I think it is important to be very precise. Two examples: * At least as far as I know, none of the TLS-based techniques provide confidentiality from submission to delivery or even from the first entry into the SMTP system until the message reaches the delivery server (as RFC 5321 defines that term), at least unless it can be guaranteed that there will be a direct connection between those two systems (i.e., no MX or other relays that need to have at least the envelope in clear to route the message or even post-delivery processing before the receiving user gets the message into an MUA or equivalent). The distinction is, or at least used to be, important because, with the exception of attacks by governments, there were far more successful attacks on servers than on network infrastructure. On the other hand, if the concerns about link encryption really are about protection from government snooping, it may be time we get much more clear about that. * It is also important to distinguish between authentication of the person who originated the message, authentication of the originating system (submission server or first-hop MTA), and authorization of the sending address to initiate messages from that sending system and/or domain. While I hope everyone reading this is familiar with the above (whether they agree with me or not), the likely audience for the A/S may not be and we should not mislead them by, e.g., using phrases like "Confidentiality between Endpoints" without defining that very carefully and/or describing its limitations. In addition, I have noticed that draft-ietf-lamps-e2e-mail-guidance appears to be progressing in the LAMPS WG. Someone may want to start coordinating soon because it would be really unfortunate to end up with guidance about email from LAMPS that was inconsistent with guidance from EMAILCORE... and perhaps even more unfortunate to discover the conflicts during IETF Last Call on one document or the other. best, john From nobody Thu Jan 27 15:03: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 846E73A0981 for ; Thu, 27 Jan 2022 15:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 l_PtYNUchovt for ; Thu, 27 Jan 2022 15:02:51 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 3ED0F3A0912 for ; Thu, 27 Jan 2022 15:02:51 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id z1so2665795qto.3 for ; Thu, 27 Jan 2022 15:02:51 -0800 (PST) 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=6kZfov5VP7+jv5caRvGU+eTZKw7oUk+daHQBeoEuXvA=; b=HUvsjMivSoq8GHz5gRkMH/lHIKCqkPWQ8oRZfmXg74sHPi0sex4vBPFyZe2Llo2p1S 18xrE+5xzQcAsr2098GkUPssEe5Dvrk8Js8f6vImcWrBSNiJgssxXMIg552tO4S/S+HM ecFDdahsnK8IAZFPdS3vm/TbNRcAP4J3DPfeq4pJIVGkaqr4Wf4Ikpk5Q78dchELjFEC 6ki7/g6n5K1Hsd8ZM/fXCC/gz4ZW8w/Usy79kTFU1l2j9+hP5yEetrbPw/bFBhQyjFOJ XNvzjDRG6cgecCTeVe3+3BE+1oP1LwREoBQJoXucV+RXlApiuvHk0V1ksGVJfbLH2Epk ZZ9Q== 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=6kZfov5VP7+jv5caRvGU+eTZKw7oUk+daHQBeoEuXvA=; b=AqPeCtnOJ6Kjx6hmy8oDGcKWRJ/ieuvYGTTY5OsC3Y4RvqLcCkTeTznOWWccY35JfZ 89SIhftSmbgqQOtRT6+vGk0qVuwd7NwhZpydPQirhBoMZnq+OFpT9D1RPTszgSr6s8i8 +Oua7BCnyjM7CaeViPlb8FLUqZWma6zX+QsW6kXHxp3vdZNawFbqHr5gBcUcE63MvXi5 vtrTaqCFQjcRWg3TRS5Tb3+oVHE1sxneqiA9XSr7nVWWwqM+dPlF66wiB5oOVwkkq2KL Jo6mqRxb7/Aqi8TYC5POvxZ8cJiAIJIbFuiyqHVmGkIZOU3/tcTGimuwgkm1aTwarD+B gOpA== X-Gm-Message-State: AOAM531gDKoERNU+y4JdvMrSGX7mh6D2G7GeUuJhuX26nvJFE9Jzo9Vq 68s2+jqYUrMEopVE40L6Y5EZOEIev+DA1lvMpBraCBKF9EXdog== X-Google-Smtp-Source: ABdhPJzBCWVSgCdFD7FZN33fKV3bCUAGS09MOXCwt9LaKgWH76U6gBjtBcbz/KLrLa6Bgg/vBeb6UW1MyPhunLMMtxw= X-Received: by 2002:ac8:7957:: with SMTP id r23mr4406904qtt.450.1643324568883; Thu, 27 Jan 2022 15:02:48 -0800 (PST) MIME-Version: 1.0 From: Todd Herr Date: Thu, 27 Jan 2022 18:02:33 -0500 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="0000000000002dea9f05d6985144" Archived-At: Subject: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 3 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, 27 Jan 2022 23:02:57 -0000 --0000000000002dea9f05d6985144 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Greetings. I've taken your comments under consideration, have incorporated many of them, and have made a few other edits to boot. The following text is the latest proposed text for this section of the A/S, and will also be added to Ticket 54. =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=3D 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 for the target receiving server and is not done for the sending client. 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, there is no guarantee that the message will be stored in encrypted fashion 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. Support for both protocols is increasing, but is not yet mandatory. 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. While its name might suggest that it would be within scope for this section of the Applicability Statement, nothing could be further from the truth. 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=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. --0000000000002dea9f05d6985144 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings.

I've taken your comments und= er consideration, have incorporated many of them, and have made a few other= edits to boot.

The following text is the latest proposed=C2=A0text for = this section of the A/S, and will also be added to Ticket 54.

=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 cu= t 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=3D

<= font face=3D"tahoma, sans-serif" style=3D"">5. Confidentiality and Authenti= cation with SMTP

SMTP is specifi= ed without embedded mechanisms for authentication or confidentiality; its t= raffic is therefore =E2=80=9Cin the clear=E2=80=9D. Years of operational ex= perience have shown that such transmission exposes the message to easy comp= romise, including wiretapping and spoofing. To mitigate these risks, operat= ion 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 t= erms =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 est= ablishing the identity of one or more of the endpoints of a communication c= hannel. TLS only requires authentication of the server side of the communic= ation channel; authentication of the client side is optional.=

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

<= p dir=3D"ltr" style=3D"line-height:1.656;margin-top:0pt;margin-bottom:12pt"= >It is not uncommon for implementers to use the ter= m =E2=80=9Cencryption=E2=80=9D to mean =E2=80=9Cconfidentiality=E2=80=9D, b= ut this is not quite correct. Rather, encryption using TLS is the current m= ethod by which confidentiality is achieved with SMTP, but that does not mea= n that future methods might not be developed.

Note: With typical email use of TLS, authentication only is p= erformed for the target receiving server and is not done for the sending cl= ient. That is, it serves to validate that the connection has been made to t= he 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 T= LS=E2=80=9D, which is frequently referred to as =E2=80=9Copportunistic encr= yption=E2=80=9D. With this method, a receiving server announces in its gree= ting that it is capable of supporting TLS encryption through the presence o= f the =E2=80=9CSTARTTLS=E2=80=9D keyword. The sending client then attempts = to negotiate an encrypted connection, and if successful, transmits the mess= age in encrypted form; if negotiation fails, the client falls back to sendi= ng the message in clear text.

Op= portunistic TLS is confidentiality without authentication, because no effor= t is made to authenticate the receiving server, and it is optional confiden= tiality due to the ability to fall back to transmission in the clear if a s= ecure connection cannot be established. That said, most modern implementati= ons of SMTP support this method, especially at the largest mailbox provider= s, and so the vast majority of email traffic is encrypted during its time t= ransiting from the client to the server.=C2=A0

Note: While TLS provides protection while the message is in = transit, there is no guarantee that the message will be stored in encrypted= fashion at its destination. In fact, storage in plain text should be expec= ted!

5.2 Require= d Confidentiality, with Receiving Server Authentication

= Two protocols exist that move message confidentiali= ty from optional to required (with conditions as noted below) - MTA-STS [RF= C8461] and DANE for SMTP [RFC7672]. While they differ in their implementati= on details, receiving servers relying on either protocol are stating that t= hey only accept mail if the transmission can be encrypted with TLS, and a f= ailure to negotiate a secure connection MUST result in the sending client r= efusing to transmit the message. Support for both protocols is increasing, = but is not yet mandatory.

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 n= egotiation of an encrypted connection fails.

Note: Both protocols mentioned in this section rely not only o= n 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 us= e Opportunistic TLS or clear-text to transmit the message.

5.3 Message-Level Authentication=

Protocols exist to allow for au= thentication 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 hea= der, and a fourth, ARC [RFC8617], provides a way for each hop to record res= ults of authentication checks performed at that hop.

All of these are outside the scope of this document, a= s they are outside the scope of SMTP. They deal with validating the authori= zed usage of one or more domains in an email message, and not with establis= hing the identity of the receiving server.

5.4 SMTP Authentication

SMTP Authentication, which is often abbreviated as SMT= P AUTH, is an extension to SMTP. While its name might suggest that it would= be within scope for this section of the Applicability Statement, nothing c= ould be further from the truth.

= SMTP AUTH defines a method for a client to identify itself to a Message Sub= mission Agent (MSA) when presenting a message for transmission, usually usi= ng port 587 rather than the traditional port 25. The most common implementa= tion of SMTP AUTH is for a person to present a username and password to the= ir mailbox provider=E2=80=99s outbound SMTP server when configuring their M= UA 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 messag= e prior to its being submitted to the SMTP communications channel, and decr= yption 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 doc= ument.

=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=3D

<= span id=3D"gmail-docs-internal-guid-8eb767ea-7fff-8e17-3287-ff276b2de8da"><= br class=3D"gmail-Apple-interchange-newline">



--

Todd Herr | Technical Director, Standards and Ecosystem
m: 703.220.41= 53

This email and all data transmitted with it contains conf= idential and/or proprietary information intended solely for the use of indi= vidual(s) authorized to receive it. If you are not an intended and authoriz= ed recipient you are hereby notified of any use, disclosure, copying or dis= tribution of the information included in this transmission is prohibited an= d may be unlawful. Please immediately notify the sender by replying to this= email and then delete it from your system.

<= /div> --0000000000002dea9f05d6985144-- From nobody Thu Jan 27 15:45: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 B8D1F3A0D1B for ; Thu, 27 Jan 2022 15:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 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.714, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 HBStkfr-R46L for ; Thu, 27 Jan 2022 15:45:33 -0800 (PST) Received: from purple.birch.relay.mailchannels.net (purple.birch.relay.mailchannels.net [23.83.209.150]) (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 829E33A0D18 for ; Thu, 27 Jan 2022 15:45:33 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 25178881CDF; Thu, 27 Jan 2022 23:45:32 +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 70CEC881BFD; Thu, 27 Jan 2022 23:45:31 +0000 (UTC) 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.106.113.27 (trex/6.4.3); Thu, 27 Jan 2022 23:45:32 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Bored-Share: 273de9017b821ccb_1643327131935_2164321930 X-MC-Loop-Signature: 1643327131935:3101006833 X-MC-Ingress-Time: 1643327131934 Received: from [192.168.0.107] (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 4JlHJn304Pz7W5Ly; Thu, 27 Jan 2022 23:45:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1643327130; bh=eq2TPXLMzeVlKXgYiUCS8/V8gnvQYCyXU3oiU0ubC3M=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To; b=Aq4U6MF6CiHuV+OyYP50jatZ7lbtnHkWOEZUFekY/1QR/3bM/JrATjlLO2rBgEYBd B41uj2sU9YmSldCqXuHyJzzOdwOswLfE629PGcQ47Ch8WlglEYyQ4E4T8QYzb6jTtK IoFnf9FnQ7HhrmfL875xTtotbnmWm4EtEykQF3tudSTIDSa8fSQJXEfquvzxlArSNc QeoUo5onUnTzdaUhokZICfD9K2VnW6sMDHuhc2WFepCduMbnmFa0iY1n41ohFgJLL9 aoxdR34GXtrOEWzu7XTcfKIAmIWKxtGlCAU1VC9kmitJXctjWSu27sNRdi0lmoomjO oiV5xScavgIgw== Message-ID: <6e513013-53e1-5142-afd9-e0088d8add9e@dcrocker.net> Date: Thu, 27 Jan 2022 15:45:28 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 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: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 3 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, 27 Jan 2022 23:45:40 -0000 On 1/27/2022 3:02 PM, Todd Herr wrote: ... > Note: With typical email use of TLS, authentication only is performed > for the target receiving server and is not done for the sending client. > That is, it serves to validate that the connection has been made to the > intended server, but does not validate who initiated it. I think this has my wording and I now see the first sentence might be misinterpreted, since it isn't clear who is authenticating whom. I suggest: 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 ... > > Note: While TLS provides protection while the message is in transit, > there is no guarantee that the message will be stored in encrypted > fashion at its destination. In fact, storage in plain text should be > expected! To respond to the significant concern that was raised that the reader properly understand that this is hop-by-hop wire encryption and is not end-to-end, I suggest: 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 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. Support for both protocols is > increasing, but is not yet mandatory. > > 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. While its name might suggest that it would be within > scope for this section of the Applicability Statement, nothing could be > further from the truth. I suspect many things could be further for the truth... So perhaps some milder and more bording wording, such as: It doesn't. > > 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 > I'm not offering wording, but it might be worth using this section to introduce the terms Channel Security versus Object Security. TLS is a channel-based mechanism. So is SPF. S/MIME, OpenPGP, DKIM, DMARC and ARC are all Object based. The simple description I'm used to, about the difference, is that Channel-based protects whatever bits go over the channel, without concern for the content, where Object-based is attached to the object and is not concerned with details of the Channel. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jan 28 08:37: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 459D03A1391; Fri, 28 Jan 2022 08:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, 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 jud-TFC7GKMR; Fri, 28 Jan 2022 08:37:35 -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 375EE3A19FB; Fri, 28 Jan 2022 08:37:33 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nDUFf-0001wC-Na; Fri, 28 Jan 2022 11:37:31 -0500 Date: Fri, 28 Jan 2022 11:37:25 -0500 From: John C Klensin To: Todd Herr , emailcore@ietf.org Message-ID: 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. 3 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, 28 Jan 2022 16:37:41 -0000 Todd, I think this is moving in the right direction. However... (1) Much of this seems to be a tutorial rather than clear statements about things that people should or should not do. I wonder if such a tutorial reasonably falls within the scope of EMAILCORE and, more specifically, if we should be encouraging the Security ADs to make such a tutorial part of the LAMPS effort that is working on draft-ietf-lamps-e2e-mail-guidance. For similar reasons that are less related to the LAMPS work, it is not clear to me why an Applicability Statement needs to spend time discussing what it is not going to discuss. Almost independent of that concern... (2) If you are going to mention S/MIME and OpenPGP at all, you should add that each can provide authentication as well as, or in addition to confidentiality. In particular, given a few assumptions about the ability of senders to manage keys (a much broader issue and heavily dependent on the type of senders), they provide much stronger authentication and message content integrity protection than any of the other methods you mention. Probably also worth mentioning that there are other mechanisms (not standardized by the IETF) in that space and they do not provide confidentiality for the SMTP envelope and, in general, not even the message headers. (3) Having read through the text several times, it is not likely that a reader who is not very clear about all of these mechanisms already will be able to figure out what is being protected from either an authentication or confidentiality standpoint. At one extreme, S/MIME, OpenPGP, and friends provide strong and sender to receiver authentication, integrity protection, and/or confidentiality, but only for some or all of the message content. Other methods you describe may provide greater protection for message headers and all or part of the envelope information, but require that anyone wanting to trust that confidentiality or authenticity have great trust in the operators, servers, and systems that handle the message when it is not actually on the wire. IMO, failure to make those distinctions clear significantly weakens the presentation and may even turn it from "helpful" into "part of the problem and dangerous". The text you quoted takes a small step in the direction I'm encouraging by pointing out that TLS often does not involve authentication of the client, only the server (and, by implication, does not authenticate the sender at all, only some of the machines that handle the message). Perhaps a chart would be helpful. best, john --On Thursday, January 27, 2022 18:02 -0500 Todd Herr wrote: > Greetings. > > I've taken your comments under consideration, have > incorporated many of them, and have made a few other edits to > boot. > > The following text is the latest proposed text for this > section of the A/S, and will also be added to Ticket 54. > > =========================== cut here ========================= > > 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 for the target receiving server and is not done for > the sending client. 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, there is no guarantee that the message will be stored > in encrypted fashion 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. Support for > both protocols is increasing, but is not yet mandatory. > > 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. While its name might suggest that it > would be within scope for this section of the Applicability > Statement, nothing could be further from the truth. > > 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 Mon Jan 31 07:46:56 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 248363A00E3; Mon, 31 Jan 2022 07:46:54 -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.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <164364401410.15844.7642839719540036536@ietfa.amsl.com> Date: Mon, 31 Jan 2022 07:46:54 -0800 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-as-04.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, 31 Jan 2022 15:46:54 -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 : Applicability Statement for IETF Core Email Protocols Authors : John C Klensin Kenneth Murchison E Sam Filename : draft-ietf-emailcore-as-04.txt Pages : 9 Date : 2022-01-31 Abstract: Electronic mail is one of the oldest Internet applications that is still in very active use. While the basic protocols and formats for mail transport and message formats have evolved slowly over the years, events and thinking in more recent years have supplemented those core protocols with additional features and suggestions for their use. This Applicability Statement describes the relationship among many of those protocols and provides guidance and makes recommendations for the use of features of the core protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emailcore-as/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-as-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-as-04 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Jan 31 12:19:38 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 16BE43A165E for ; Mon, 31 Jan 2022 12:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 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.714, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=eOoDTBmc; dkim=pass (1152-bit key) header.d=tana.it header.b=AI/pd68s 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 eHZSFF9QAcOj for ; Mon, 31 Jan 2022 12:19:23 -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 069AA3A1644 for ; Mon, 31 Jan 2022 12:19:22 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1643387630; bh=LV+Rx7/xAqNoFyuJgtfF+/7ZB184Oh8F+mjV7JB1j0A=; h=Subject:To:References:From:Date:In-Reply-To; b=eOoDTBmc0xbMgv9rYrf1tXuQMnKGBB/58ieGCpl5+ul4wFvWczHihgWPr/T1ERMRb ZQNChE6yhjv0/l6lSOjDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1643387630; bh=LV+Rx7/xAqNoFyuJgtfF+/7ZB184Oh8F+mjV7JB1j0A=; h=To:References:From:Date:In-Reply-To; b=AI/pd68sSBXK1rSE6H8dLpeQxHxa0EQP/rGM97GFwBoOiI+5IRiWxVTRQWmkdHl/c D+djeIJv5Hk/fi++c2be2o22ahtFXZv2IrfNMrKd1wT+lSBLzHVcaXN5qQW6whWDpV XEHdiP8mehVzUwNYmkdOih6yCJIihoul2ZDbrlkRvod26nIFApbmYmaRhKQi5 Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.98] (alenovo.tana [172.25.197.98]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC042.0000000061F41AEE.0000250F; Fri, 28 Jan 2022 17:33:50 +0100 To: emailcore@ietf.org References: <6e513013-53e1-5142-afd9-e0088d8add9e@dcrocker.net> From: Alessandro Vesely Message-ID: <15014dd3-66fd-3897-50f7-6ba0eccda941@tana.it> Date: Fri, 28 Jan 2022 17:33:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <6e513013-53e1-5142-afd9-e0088d8add9e@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 3 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, 31 Jan 2022 20:19:36 -0000 On Fri 28/Jan/2022 00:45:28 +0100 Dave Crocker wrote: > On 1/27/2022 3:02 PM, Todd Herr wrote: > ... >> Note: With typical email use of TLS, authentication only is >> performed for the target receiving server and is not done for the >> sending client. That is, it serves to validate that the connection >> has been made to the intended server, but does not validate who >> initiated it. > > I think this has my wording and I now see the first sentence might be > misinterpreted, since it isn't clear who is authenticating whom.  I > suggest: > > > 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. To be even more clear, I'd add something like "Sending client authentication is usually done on the first hop only, see Section 5.4". >> [...] >> 5.2 Required Confidentiality, with Receiving Server Authentication >> >> Two protocols exist [...] Support for both protocols is >> increasing, but is not yet mandatory. Mandatory -> widespread (or prevalent?) at the time of this writing. jm2c Ale -- From nobody Mon Jan 31 19:33:59 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 0F1FE3A0EEB for ; Mon, 31 Jan 2022 19:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Fm1Zb0Jw; dkim=pass (2048-bit key) header.d=taugh.com header.b=AHSwbPaD 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 4s3HnZ4YsY82 for ; Mon, 31 Jan 2022 19:33:52 -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 F19613A0EE5 for ; Mon, 31 Jan 2022 19:33:51 -0800 (PST) Received: (qmail 16125 invoked from network); 1 Feb 2022 03:33:48 -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=3eec.61f8aa1c.k2201; bh=Fo0fVaXUSbIOy/ItyS2kTP/HUQun4AanKu0xPEA5ffo=; b=Fm1Zb0JwGGH0QCdL42nkk6j98F8V9NAQbbsznCjOfLW5gTWGJtvSgR3hn3UB6HcVHTlL48gZLwHQQ0uIRJ6q49CenL/FqLlNBQ8OZJWawztnkkjznRvetHDH5QwIokWNFqppPvuxNmFdcPRjVfJW0e7F0xUseRid7FjCrTaAcolz7McnJtYgWxCr3U4PGm+/7ID0VJ5Eu7qgxwUDZs6HH9cLEF1tLVAVpQsHRqqMbN1ia+sR5M6RIWuoykKP3sHOQNKXEFc6+hdHrKMR3UscJPtKmEAuPleuLiI1alqo1gKSttjknhYL8tlmZ6p7awb+LIoiCKfZJTxWViYBFUHuxQ== 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=3eec.61f8aa1c.k2201; bh=Fo0fVaXUSbIOy/ItyS2kTP/HUQun4AanKu0xPEA5ffo=; b=AHSwbPaDMmXet5G3EOq/tkMPi7mzpl2GsycP2qzvSPqz9dkFkQ/V4VfFvvWgF9Kn0eqOJpfFnpH2zrwr0+lhNRdz5Kdh3IrFSLzfLP3e+1O9+Y0yv102kQnAAPL4G7+XitWH39B5J+X7Rbx7+Vxmos1cZk0HjsFRodvMtkYN6XWTyQFMf4bJxB/teBAhSPpNzzvWijmG0MaYna/9iIhOhtL8QNWtPq5G5nbI0tkyeF/gUVvzSif3ULxytiXSXhoX+obumSKuGG2GoH4FNkPSLszW4SrtzkaAApsw0wYQJMJLLSolWxyUFXRLnOM7CAe3vWxchCQRREjbYAD5oLjgqA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 01 Feb 2022 03:33:47 -0000 Received: by ary.qy (Postfix, from userid 501) id 7931D35D1ADE; Mon, 31 Jan 2022 22:33:46 -0500 (EST) Date: 31 Jan 2022 22:33:46 -0500 Message-Id: <20220201033347.7931D35D1ADE@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: vesely@tana.it In-Reply-To: <15014dd3-66fd-3897-50f7-6ba0eccda941@tana.it> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 3 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, 01 Feb 2022 03:33:57 -0000 It appears that Alessandro Vesely said: >> 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. > >To be even more clear, I'd add something like "Sending client >authentication is usually done on the first hop only, see Section 5.4". I'm not sure whether you are referring to authentication OF the sending client or BY the sending client, but either way, it seems wrong. Authentication BY the client happens on a hop to a server located using an MX or maybe A/AAAA record, using DANE or MTA-STS to check that the server is the one it's looking for. All the other hops are within the sending or receiving system which presumably has knowledge if its internal structure so there's nothing to authenticate. Authentication OF the client doesn't happen at all unless I supose you're talking about DNS checks on the HELO name, or you're mixing submission with SMTP. R's, John