From nobody Wed Jul 29 06:14:21 2020 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 5C72F3A0ADC; Wed, 29 Jul 2020 06:14:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IETF Secretariat To: "IETF Announcement List" Cc: aamelnikov@fastmail.fm, seth@valimail.com, emailcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.11.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ietf@ietf.org Message-ID: <159602845135.32463.6439545361849775531@ietfa.amsl.com> Date: Wed, 29 Jul 2020 06:14:11 -0700 Archived-At: Subject: [Emailcore] New Non-WG Mailing List: emailcore 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: Wed, 29 Jul 2020 13:14:12 -0000 A new IETF non-working group email list has been created. List address: emailcore@ietf.org Archive: https://mailarchive.ietf.org/arch/browse/emailcore/ To subscribe: https://www.ietf.org/mailman/listinfo/emailcore Purpose: Discussion of moving core email protocols (RFCs 5321 and 5322) to Internet Standard, and producing an Applicability Statement about the usage of those protocols.   This list belongs to IETF area: ART For additional information, please contact the list administrators. From nobody Wed Jul 29 09:09:10 2020 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 D0BEE3A0DBC for ; Wed, 29 Jul 2020 09:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 IToZwNMy1n3M for ; Wed, 29 Jul 2020 09:08:52 -0700 (PDT) Received: from mail-ob.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6193A0D61 for ; Wed, 29 Jul 2020 09:08:44 -0700 (PDT) Received: (qmail 35858 invoked from network); 29 Jul 2020 16:08:43 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (c64a275e-d1b5-11ea-898d-47e5c5e1c2ab); Wed, 29 Jul 2020 09:08:43 -0700 To: emailcore@ietf.org, ietf-smtp@ietf.org, mailsec@ietf.org From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <11c583d2-ef3a-e24e-5e32-98c2e6e66d86@linuxmagic.com> Date: Wed, 29 Jul 2020 09:08:43 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: c64a275e-d1b5-11ea-898d-47e5c5e1c2ab 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: [Emailcore] Good to see new list, comments about the "purpose" 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, 29 Jul 2020 16:08:59 -0000 I believe this is an opportunity, and the BOF should consider that the working group's mandate be extended larger than originally suggested. As pointed out previously on other threads, having a working group that covers the whole email core, would enable this working group to tackle more wide ranging email problems, that are important to the internet community. For example, the current conversation in the ietf-smtp mailing list, there are discussions about permitted labels' in email, that should properly encompass IMAP usage as well, same goes for the conversations about SSL vs STARTTLS, applies to both SMTP and IMAP. Having a standing WG that can address issues across the whole email ecosystem makes sense. And if that is true, again I purport the new WG could then take on: https://tools.ietf.org/html/draft-yu-imap-client-id-04 https://tools.ietf.org/html/draft-storey-smtp-client-id-09 *Comments Welcome* Someone (Dave) suggested we use a standardized template. Item: { Reference-name } Issue: { Concise description of problem, concern, or the like } Effect: { What significant effect(s) is this issue producing? } Validation: { Document the basis for the claimed effect } Item: CLIENTID Issue: Traditional IMAP/SMTP protocols are no longer sufficient for modern day threat protection, especially when it concerns traditional email and password authentication. Malicious bots and attacks, and data breaches have made world wide users of email vulnerable to email account takeovers. Password replay attacks, dictionary attacks, password reuse, and weak passwords are a very real and persistent threat. Hacked email accounts are no longer just used to send spam, threat actors now use it for data exfiltration, spear phishing, deploying ransomware, and the takeover of cloud services, where the email address controls access, such as banking information, cloud services, domain name takeovers, impersonation, as well as access to sensitive information in email mail repositories, contacts, and other related information. Effect: Adding CLIENTID to the base IMAP/SMTP protocols allow for ACL's and/or controls to only allow authentication to approved devices, and/or classes of devices, preventing password reuse/guessing attacks, which currently are attributed to be the major source of email compromise. This technology can be deployed transparently to the end user(s). Validation: The CLIENTID extensions are already in wide spread use, across multiple email servers, and multiple email clients, and it's use detects and prevents > 99% of all such attacks against CLIENTID enabled email accounts. As this is already becoming a standard across multiple vendors. and it's efficacy is proven, this would be the time to ratify the implementation standards. For those that aren't aware, it's in public use in MagicMail and MailEnable servers, and it is supported in emClient, SaneBox, BlueMail, Thunderbird, and many other email client libraries. I believe the IETF supports enshrining in RFC's standards that are already being adopted in the wild. And we are still looking for an official home for this, and the working group to take it on. -- "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 Jul 29 09:19:29 2020 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 C018D3A09E1; Wed, 29 Jul 2020 09:19:26 -0700 (PDT) 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, NICE_REPLY_A=-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 zRLuqbCYMOiR; Wed, 29 Jul 2020 09:19:24 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 0E56D3A094E; Wed, 29 Jul 2020 09:19:14 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06TGLo5E001815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jul 2020 09:21:50 -0700 Reply-To: dcrocker@bbiw.net To: Michael Peddemors , ietf-smtp@ietf.org, mailsec@ietf.org References: <11c583d2-ef3a-e24e-5e32-98c2e6e66d86@linuxmagic.com> Cc: emailcore@ietf.org From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <70a175d5-c32b-9096-7203-996475054f48@dcrocker.net> Date: Wed, 29 Jul 2020 09:19:07 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <11c583d2-ef3a-e24e-5e32-98c2e6e66d86@linuxmagic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] [ietf-smtp] Good to see new list, comments about the "purpose" 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, 29 Jul 2020 16:19:27 -0000 On 7/29/2020 9:08 AM, Michael Peddemors wrote: > I believe this is an opportunity, and the BOF should consider that the > working group's mandate be extended larger than originally suggested. > > As pointed out previously on other threads, having a working group that > covers the whole email core, would enable this working group to tackle > more wide ranging email problems, that are important to the internet > community. That would be an excellent way to avoid getting the primary task done, which is to get the two, primary specification elevated to full standard. It's a variation on attempting to boil the ocean. It's not that the larger scope isn't worthy, it's that it isn't practical. After the primary task is completed, it might make sense to consider rechartering, for a scope of the type you suggest. But not before then. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jul 29 12:00:00 2020 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 E25193A0E32 for ; Wed, 29 Jul 2020 11:59:55 -0700 (PDT) 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=IsEDMeF9; dkim=pass (1536-bit key) header.d=taugh.com header.b=qiDzOceg 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 qxp5Jfn0THc5 for ; Wed, 29 Jul 2020 11:59:54 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18CCD3A0E3C for ; Wed, 29 Jul 2020 11:59:53 -0700 (PDT) Received: (qmail 81192 invoked from network); 29 Jul 2020 18:59:51 -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; s=13d25.5f21c727.k2007; bh=AKOwUgqiD4HUfoF9D1ZbL5EVyvRDWtLI57DW9/Bx5pI=; b=IsEDMeF9JOu31c25WyOlfNWxoGSO7hBgT+ojY5m55gK2hGb13GgcMM3lMRlrisLWjBfgP/8cSgIdflkx3ZUIAmjOtUxDUCBSwjOVn5iNXAjaqVPALvdGMa2XBpp++LZx6yQBfc/OST7YGQ/p1Gyc8KiPkG8t9CrA0e9Inmb8sPehz6vBqOogjtYmUGK7dfj1vAB16qyi4XUmwHhGxktJR3WR8HrC8QC2H/Noh4yBa94kHpDSpPoDTtH6A9I4vzNL 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; s=13d25.5f21c727.k2007; bh=AKOwUgqiD4HUfoF9D1ZbL5EVyvRDWtLI57DW9/Bx5pI=; b=qiDzOcegxh+HlLNjFLhajj6Xy0KOBiQ+6sVzynzTOmvxIrVAhMn6rsJoe8zydnrZThXXPSqI7kjjeTA8zHp3hZaJDuiPYgHbQzd/3Ni0Rp96vupcpjs+relWGCJYrzl0z36wfvmAm9TMWbbnJ1hGbn8iuPfvQhsiSvamR9ti/Nf2DFNsw5z3jruYU1FnYZ9tvnSb3Al3nOPS/IdW50Bf6p2MewSs2lYAXLWwpPMJP6nO0UYk74r0K0SI+abasV/O 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; 29 Jul 2020 18:59:50 -0000 Received: by ary.qy (Postfix, from userid 501) id E4C3E1DA164E; Wed, 29 Jul 2020 14:59:50 -0400 (EDT) Date: 29 Jul 2020 14:59:50 -0400 Message-Id: <20200729185950.E4C3E1DA164E@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: michael@linuxmagic.com In-Reply-To: <11c583d2-ef3a-e24e-5e32-98c2e6e66d86@linuxmagic.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Good to see new list, comments about the "purpose" 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, 29 Jul 2020 18:59:56 -0000 In article <11c583d2-ef3a-e24e-5e32-98c2e6e66d86@linuxmagic.com> you write: >Item: CLIENTID No. This WG is to standardize existing practice, not to advance pet projects. R's, John From nobody Wed Jul 29 12:09:19 2020 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 969DE3A0AC3 for ; Wed, 29 Jul 2020 12:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=HnFK29SU; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=wnnZXnkv 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 4pD0msje31eA for ; Wed, 29 Jul 2020 12:09:15 -0700 (PDT) Received: from mail.winserver.com (news.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 4F8373A0E3F for ; Wed, 29 Jul 2020 12:09:15 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1245; t=1596049749; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=88bLgJhkbz5JH+Jrk1BTbhBrdvA=; b=HnFK29SUyJP8JZnUrkCfjB+hLmeegiXBbHFh3LGMUn4P0et2l14/e/I7MfByTL oKK2h/UfXm7s5mkegitpOqp/gDJazDbXJ5HWavL0mlNJyhyS1xyvGFSpkCqAnftN Jw5Xbkmwha4p1PFWGcVClO2gpngBUesP7hPBfzsesEg0M= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Wed, 29 Jul 2020 15:09:09 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2482039866.1.884; Wed, 29 Jul 2020 15:09:07 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1245; t=1596049636; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=G8u+gMe Qr3BXxrs9Put/pHx1f9izDwSzRVzEi/N6x58=; b=wnnZXnkvIpLc+/9dceaY189 HOAmUnRmJNrIo6aHJ5+MyX8g9hwXsQwZ+ODJOBI5rlWIx5PTvSJuM9W320350IVR ZgKnDthvzGN14Lf9wMVVuFRk8PDlLzwkOLJQ4wQkJNspLkQfAIkEepXh/O+iMDB0 X8W3SotAv3Wg8zk1X1xk= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Wed, 29 Jul 2020 15:07:16 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2192810921.1.60520; Wed, 29 Jul 2020 15:07:15 -0400 Message-ID: <5F21C956.1040508@isdg.net> Date: Wed, 29 Jul 2020 15:09:10 -0400 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: ietf-smtp@ietf.org CC: emailcore@ietf.org References: <11c583d2-ef3a-e24e-5e32-98c2e6e66d86@linuxmagic.com> <70a175d5-c32b-9096-7203-996475054f48@dcrocker.net> In-Reply-To: <70a175d5-c32b-9096-7203-996475054f48@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] [ietf-smtp] Good to see new list, comments about the "purpose" 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, 29 Jul 2020 19:09:18 -0000 On 7/29/2020 12:19 PM, Dave Crocker wrote: > On 7/29/2020 9:08 AM, Michael Peddemors wrote: >> I believe this is an opportunity, and the BOF should consider that >> the working group's mandate be extended larger than originally >> suggested. >> >> As pointed out previously on other threads, having a working group >> that covers the whole email core, would enable this working group to >> tackle more wide ranging email problems, that are important to the >> internet community. > > > That would be an excellent way to avoid getting the primary task done, > which is to get the two, primary specification elevated to full > standard. It's a variation on attempting to boil the ocean. > > It's not that the larger scope isn't worthy, it's that it isn't > practical. > > After the primary task is completed, it might make sense to consider > rechartering, for a scope of the type you suggest. But not before then. > Dave, I agree with you, keep the eye on the prize, RFC5322/5321 standardization. Very important. I'm sure there will be plenty of "Heads Up" discussions, items that can perhaps be phrased as implementation notes. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Wed Jul 29 18:35:34 2020 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 147B83A0998; Wed, 29 Jul 2020 18:35:27 -0700 (PDT) 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 EWgEdI0IGCq4; Wed, 29 Jul 2020 18:35:25 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C973A092F; Wed, 29 Jul 2020 18:35:25 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1k0xTf-000D33-TY; Wed, 29 Jul 2020 21:35:23 -0400 Date: Wed, 29 Jul 2020 21:35:17 -0400 From: John C Klensin To: emailcore@ietf.org cc: ietf-smtp@ietf.org Message-ID: <7E95359C842EE556A1D3788F@PSB> In-Reply-To: <70a175d5-c32b-9096-7203-996475054f48@dcrocker.net> References: <11c583d2-ef3a-e24e-5e32-98c2e6e66d86@linuxmagic.com> <70a175d5-c32b-9096-7203-996475054f48@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] [ietf-smtp] Good to see new list, comments about the "purpose" 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, 30 Jul 2020 01:35:27 -0000 Hi. Some observations and an attempt to play devil's advocate: (1) If we are going to have a separate list, let's have a separate list, not create confusion by copying ietf-smtp and having both the additional clutter and the risk of parallel discussions. So, while this note is copied to ietf-smtp for obviously reasons, I hope it will be the last, or nearly-last, cross-posting. (2) Perhaps I'm the only one, but I'd really like to try to survive this week without putting something else on my virtual plate. So I would encourage others to just let this go until next week (or longer). In any event, for myself, please don't expect further responses from me until at least the weekend. And I would encourage not reading the rest of this note until those who would do so have recovered from this week. (3) Now the substantive part (and, for most of it, the devil's advocate part): Personally, I'm fine with the model of focusing on moving 5321bis and 5322bis to Internet Standard, using a separate { Applicability Statement | BCP | Rubber Ducky } as a way to accommodate whatever behavioral recommendations, comments on or pointers to other specifications, and/or "roadmap" materials for whatever mail-related specifications the WG concludes are important. As Pete said during the BOF about 5322[bis], I'd really, really, like to get 5321[bis] off my plate, do so before I retire [1], and do so with a minimum of pain and suffering. The current plan appears to me to be the best way to accomplish all of that. _However_... Despite a BOF that was organized around that narrow scope and focus, not only is it not the only way forward but it may be based on a false premise. RFC 6410 dropped the standards track from three maturity levels to two in the hope that would result in significantly more documents moving to Internet Standard. A handful of specifications that have been advanced without changes to the underlying documents aside, it is rather clear that has not happened and that, if anything, the Internet and the users of IETF specifications care even less than they did nine years ago. I do care on grounds of tidiness; Pete, Alexey, Seth, and Barry presumably care, and probably others reading this care, but it is not clear that any significant number of relevant others care. And, while that narrow focus may be the fastest way to get the work it defines done, it will still be a fair amount of work; the BOF today provided evidence that some things will be controversial and painful to resolve; and so on. The payoff may not be sufficient to justify that, which suggests two other possibilities. (a) RFC 5321 is a bad document (so was 2821). It is really a merge of three separate documents combined with excerpts from a fourth and some added applicability statement material associated with the technical specification. In part because of that merge and the age of RFCs 821 and 974, it switches organizational styles and writing style from section to section. The switch from the textbook BNF of RFC 821 to the ABNF of 2821 introduced errors; the transition to 5321 did not catch all of them and may have introduced some new ones (see Appendix H, Section H.1, of draft-klensin-rfc5321bis-03) and there is no good reason to be confident that there are none left. And, as was sort of mentioned during the BOF, the references between the two documents for syntax and the greater permissiveness of 5822 contribute to confusion. Two consecutive WGs (DRUMS and YAM) decided against doing a full rewrite --largely on the grounds that it would take more time and risk more errors -- but, if we really want to add value in this iteration, maybe we should be developing something more like: (i) A complete rewrite of 5321 (ii) An update to 5322 more or less along the lines planned -- material in 5322 only has one core document and two editors in its history while I count about eight authors/editors for what became 5321 -- but with some material torn out. (iii) A consensus, best practices, terminology and model document using RFC 5598 as a starting point. (iv) A syntax specification that draws on both 5321 and 5322 and that is referenced by both. (v) A "roadmap" document for Internet email specifications, possibly combined with A/S and/or BCP material for some of those specs. Or those could be one or more documents separate from the roadmap. Other breakdowns are clearly possible, but the goal would be to recognize that we have something of a mess on our hands and that part of the goal for producing Internet Standards is to make them clear and easy to understand, a goal that actually requires more than the narrow revisions now proposed. (b) As any of us with experience in this area should have been able to predict (and several of us did), mentioning the idea of opening up 5321 and 5322 immediately drew multiple topics out for consideration for inclusion in one or the other document (or something related). Maybe that energy is A Good Thing. If so, perhaps we should put the efforts to get 5321bis / 5322bis to Internet Standard aside for six months or a year (or longer) to give those proposals time and attention sufficient to get clear documentation and IETF consensus on whether or not they are good ideas and then to be able to demonstrate interoperability, wide deployment, etc., only then coming back to 5321bis/5322bis when we are ready to make substantive (rather than procedural) decisions about their inclusion. That time might also allow some already-published specs to mature sufficiently to be incorporated or normatively referenced. Again, I'm not suggesting either (a) or (b) above, but they appear to me to be plausible alternatives that we should consider and, if appropriate, reach consensus to explicitly reject rather than blowing them off because they are inconsistent with the path we have been on. best, john [1] Something that is feeling a lot closer right now than it did last week.