From nobody Sun Nov 15 23:01:47 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 25FB23A1472 for ; Sun, 15 Nov 2020 23:01:45 -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 0lWHzIFMoyJY for ; Sun, 15 Nov 2020 23:01:44 -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 26C4F3A1471 for ; Sun, 15 Nov 2020 23:01:44 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1keYWE-000Pxp-QX for emailcore@ietf.org; Mon, 16 Nov 2020 02:01:42 -0500 Date: Mon, 16 Nov 2020 02:01:37 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: <96736BC4D69B0E29F09A2DBF@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Emailcore] Agenda for Tuesday 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, 16 Nov 2020 07:01:45 -0000 Hi. Since the WG was chartered, there has, AFAICT, zero substantive discussion on the mailing list of anything that would impact 5321bis or 5322bis. There was a lengthy discussion last month about repeated use of EHLO but, if there was consensus on anything other than "maybe for the A/S", I wasn't able to discuss it. More important, and again AFAICT, there has been zero discussion of any of the six topics listed on the agenda. Assuming we still believe in the principle that work gets done on the mailing list, why are we meeting tomorrow? And, if we don't believe in that principle but are, indeed, going to work through issues in meetings, I count 29 identified issues in 5321bis alone. At six issues per IETF (which may be optimistic as we get to the harder issues) plus some time to refine and nit-pick drafts and start building the A/S, this WG takes about two years. I also note that there has been no announcement of an editor for the A/S. So, either between now and Tuesday on list, or as a first agenda item for the meeting, I think a brief discussion of whether we really have the energy to do this work would be in order. If we do not, it would be much better to figure it out now than to get a year out and discover that Pete and I are the only ones who are really engaged on the documents. A different version of that discussion, and probably a more useful one, is what the WG and co-chairs plan to do to turn things around so that the above pessimistic picture doesn't come true. john From nobody Mon Nov 16 08:35:33 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 44E853A12B9 for ; Mon, 16 Nov 2020 08:35:25 -0800 (PST) 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, NICE_REPLY_A=-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 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 S3oVsvhRgFEW for ; Mon, 16 Nov 2020 08:35:23 -0800 (PST) Received: from mail-ob.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0793A129A for ; Mon, 16 Nov 2020 08:35:23 -0800 (PST) Received: (qmail 31028 invoked from network); 16 Nov 2020 16:35:20 -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 (b785cdde-2829-11eb-b40b-cf70bfa6bb24); Mon, 16 Nov 2020 08:35:20 -0800 To: emailcore@ietf.org References: <96736BC4D69B0E29F09A2DBF@PSB> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <3966c613-b159-1ace-6f0b-297aa304a94f@linuxmagic.com> Date: Mon, 16 Nov 2020 08:35:20 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <96736BC4D69B0E29F09A2DBF@PSB> 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: b785cdde-2829-11eb-b40b-cf70bfa6bb24 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] Agenda for Tuesday 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, 16 Nov 2020 16:35:31 -0000 Hi John, This does bring about an interesting point, that might need to be brought up in the IETF as a whole, is that engagement on topics in my opinion, has been dropping off in general. It is possibly time that the IETF consider ways to bring more industry people into the conversations that affect everyone. We do need a new generation of highly engaged people on various topics to the IETF discussions. I don't have any answers to that, but if there is someone that can gather engagement statistics over the last 10 years, it might be interesting. Not sure where to cc' that conversation, but I do think it is a trend on many of the working group conversations. -- Michael -- On 2020-11-15 11:01 p.m., John C Klensin wrote: > Hi. > > Since the WG was chartered, there has, AFAICT, zero substantive > discussion on the mailing list of anything that would impact > 5321bis or 5322bis. There was a lengthy discussion last month > about repeated use of EHLO but, if there was consensus on > anything other than "maybe for the A/S", I wasn't able to > discuss it. > > More important, and again AFAICT, there has been zero discussion > of any of the six topics listed on the agenda. > > Assuming we still believe in the principle that work gets done > on the mailing list, why are we meeting tomorrow? > > And, if we don't believe in that principle but are, indeed, > going to work through issues in meetings, I count 29 identified > issues in 5321bis alone. At six issues per IETF (which may be > optimistic as we get to the harder issues) plus some time to > refine and nit-pick drafts and start building the A/S, this WG > takes about two years. I also note that there has been no > announcement of an editor for the A/S. > > So, either between now and Tuesday on list, or as a first agenda > item for the meeting, I think a brief discussion of whether we > really have the energy to do this work would be in order. If we > do not, it would be much better to figure it out now than to get > a year out and discover that Pete and I are the only ones who > are really engaged on the documents. A different version of > that discussion, and probably a more useful one, is what the WG > and co-chairs plan to do to turn things around so that the above > pessimistic picture doesn't come true. > > john > -- "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 Mon Nov 16 08:54:30 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 A4DE63A12BA for ; Mon, 16 Nov 2020 08:54:28 -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 (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 7P-zqVkes7yB for ; Mon, 16 Nov 2020 08:54:27 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id A79E83A12BE for ; Mon, 16 Nov 2020 08:53:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1605545597; d=isode.com; s=june2016; i=@isode.com; bh=2hMQBf/fE7ZKPxnKghoS0HN06hkfVjzWZCjE4i/r3RE=; 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=jb/uD9tQaMFjVcPpHhXVpFJIlwB6+fA1hwxhkZ5QetG20iT0+WMzAYGgCqn3D3qoJSwq3w AQUw12CfFndC52mC5E3uYls6s5t/SLLwDITfL8VR2pX8610BsCh5CMLvBLzkCq9qG6sLIk n85Nr4Fsg8QIyc+Nn/zDV16LKcoeFiQ=; Received: from [192.168.0.5] ((unknown) [176.252.130.164]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 16 Nov 2020 16:53:17 +0000 X-SMTP-Protocol-Errors: NORDNS To: emailcore@ietf.org From: Alexey Melnikov Message-ID: <240e4ce1-d90b-285e-8878-d79c9cad70c2@isode.com> Date: Mon, 16 Nov 2020 16:53:16 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------74E7DEE0CA4E9B1FB1402B30" Content-Language: en-GB Archived-At: Subject: [Emailcore] Ticket #4: Exploders seem to be prohibited from adding List-* header fields 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, 16 Nov 2020 16:54:29 -0000 --------------74E7DEE0CA4E9B1FB1402B30 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Dear collegues, I would like us to discuss the following ticket for rfc5321bis: 3.9. Mailing Lists and Aliases =C2=A0=C2=A0=C2=A0 [...] When a message is =C2=A0=C2=A0=C2=A0 delivered or forwarded to each address of an expanded li= st form, the =C2=A0=C2=A0=C2=A0 return address in the envelope ("MAIL FROM:") MUST be ch= anged to be =C2=A0=C2=A0=C2=A0 the address of a person or other entity who administers = the list. =C2=A0=C2=A0=C2=A0 However, in this case, the message header section (RFC 5= 322 [11]) =C2=A0=C2=A0=C2=A0 MUST be left unchanged; in particular, the "From" field = of the header =C2=A0=C2=A0=C2=A0 section is unaffected. As was already pointed out on the mailing list, the text "the message=20 header section (RFC 5322 [11]) MUST be left unchanged" seems to prohibit=20 addition of List-* header fields. Strawman proposal how to address this issue: OLD: =C2=A0=C2=A0=C2=A0 However, in this case, the message header section (RFC 5= 322 [11]) =C2=A0=C2=A0=C2=A0 MUST be left unchanged; in particular, the "From" field = of the header NEW: =C2=A0=C2=A0=C2=A0 However, in this case, the message header section (RFC 5= 322 [11]) =C2=A0=C2=A0=C2=A0 MUST NOT be modified, except for adding header fields re= lated to =C2=A0=C2=A0=C2=A0 mailing list processing (e.g. List-* [RFC4021][RFC8058])= and/or trace =C2=A0=C2=A0=C2=A0 header fields [rfc5322bis]; [...] Please discuss if the proposed text is an improvement and whether it can=20 be further improved. (I am aware that this depends on ticket #7 "Better definition for trace=20 header fields", which includes suggestion to replace "trace header=20 field" with something else. But once the ticket #7 is resolved, this=20 should hopefully will have little impact on the above proposed text.) Best Regards, Alexey, as a co-chair --------------74E7DEE0CA4E9B1FB1402B30 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Dear collegues,

I would like us to discuss the following ticket for rfc5321bis:

3.9. Mailing Lists and Aliases

=C2=A0=C2=A0=C2=A0 [...] When a message is
=C2=A0=C2=A0=C2=A0 delivered or forwarded to each address of an expand= ed list form, the
=C2=A0=C2=A0=C2=A0 return address in the envelope ("MAIL FROM:") MUST = be changed to be
=C2=A0=C2=A0=C2=A0 the address of a person or other entity who adminis= ters the list.
=C2=A0=C2=A0=C2=A0 However, in this case, the message header section (= RFC 5322 [11])
=C2=A0=C2=A0=C2=A0 MUST be left unchanged; in particular, the "From" f= ield of the header
=C2=A0=C2=A0=C2=A0 section is unaffected.

As was already pointed out on the mailing list, the text "the message header section (RFC 5322 [11]) MUST be left unchanged" seems to prohibit addition of List-* header fields.

Strawman proposal how to address this issue:

OLD:

=C2=A0=C2=A0=C2=A0 However, in this case, the message header section = (RFC 5322 [11])
=C2=A0=C2=A0=C2=A0 MUST be left unchanged; in particular, the "From" f= ield of the header

NEW:

=C2=A0=C2=A0=C2=A0 However, in this case, the message header section = (RFC 5322 [11])

=C2=A0=C2=A0=C2=A0 MUST NOT be modified, except for adding header fie= lds related to

=C2=A0=C2=A0=C2=A0 mailing list processing (e.g. List-* [RFC4021][RFC= 8058]) and/or trace

=C2=A0=C2=A0=C2=A0 header fields [rfc5322bis]; [...]

Please discuss if the proposed text is an improvement and whether it can be further improved.

(I am aware that this depends on ticket #7 "B= etter definition for trace header fields", which includes suggestion to replace "trace header field" with something else. But once the ticket #7 is resolved, this should hopefully will have little impact on the above proposed text.)

Best Regards,

Alexey, as a co-chair


--------------74E7DEE0CA4E9B1FB1402B30-- From nobody Mon Nov 16 09:04:41 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 C877C3A12CC for ; Mon, 16 Nov 2020 09:04:39 -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, 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 Nv8_oCe7v4nG for ; Mon, 16 Nov 2020 09:04:37 -0800 (PST) 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 87D8C3A12C9 for ; Mon, 16 Nov 2020 09:04:09 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0AGH7diC032548 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 16 Nov 2020 09:07:39 -0800 To: Alexey Melnikov , emailcore@ietf.org References: <240e4ce1-d90b-285e-8878-d79c9cad70c2@isode.com> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: Date: Mon, 16 Nov 2020 09:04:01 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <240e4ce1-d90b-285e-8878-d79c9cad70c2@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Emailcore] Ticket #4: Exploders seem to be prohibited from adding List-* header fields 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, 16 Nov 2020 17:04:40 -0000 On 11/16/2020 8:53 AM, Alexey Melnikov wrote: > > 3.9. Mailing Lists and Aliases > ... > > NEW: > >     However, in this case, the message header section (RFC 5322 [11]) > >     MUST NOT be modified, except for adding header fields related to > >     mailing list processing (e.g. List-* [RFC4021][RFC8058]) and/or trace > >     header fields [rfc5322bis]; [...] > This document should remove all references to aliases and mailing lists.  They are, quite simply, out of scope for basic email transfer, which is what SMTP does. Also  they have become complicated topics that take more than the superficial treatment this specification can (or should) provide. Aliases and Mailing Lists operate /after delivery/.  That is, after SMTP has done its job.  They therefore operate at a layer above SMTP. As a small example, the Must Not stricture is clearly wrong with respect to modern handling of the From: field in some cases. While there is demonstrated resistance to referencing RFC 5598, it's still worth considering. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Nov 16 09:10:17 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 E13733A12FC for ; Mon, 16 Nov 2020 09:10:14 -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 a7bP58wtOinF for ; Mon, 16 Nov 2020 09:10:13 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE4F3A12FA for ; Mon, 16 Nov 2020 09:10:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1605546612; d=isode.com; s=june2016; i=@isode.com; bh=kzKx8Yemtk7AF1Kopm+QMSGS23cUf1lRXNSpX9WPRBg=; 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=Me/5SPrPREdApTZcvQUH8UCzTrIX1hzC/GiivZtgcqR+HtzzGzTlH/gyxyQeSiMPuQ9+xW bsr/ywuxux5ZjFJUNyixZo7OAFotdXXaECiFY8SMEHeFimp9DDtMMgqB1UWxx+ewOkE+Ai YTRpLcJGZWyNxD9JEeN1JyJ9XNTat90=; Received: from [192.168.0.5] ((unknown) [176.252.130.164]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 16 Nov 2020 17:10:12 +0000 X-SMTP-Protocol-Errors: NORDNS To: emailcore@ietf.org From: Alexey Melnikov Message-ID: Date: Mon, 16 Nov 2020 17:10:11 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [Emailcore] Ticket #8: Need a registry of header fields that are Ok to add after submission 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, 16 Nov 2020 17:10:15 -0000 Dear WG participants, Based on an earlier discussion on the mailing it looks like there is=20 consensus to create (or possible ammend an existing) registry for header=20 fields with extra information about which types of SMTP agents are=20 allowed to add them in transit or before final delivery. In order to=20 stimulate the discussion, I would like to propose the following strawman: Add to IANA Considerations: IANA is requested to create a new subregistry for email header fields=20 that can be added to a message header section by a =E2=80=9Crelay=E2=80=9D a= nd/or=20 =E2=80=9Cdelivery=E2=80=9D SMTP system. The new subregistry would show wheth= er a header=20 field can be added by a =E2=80=9Crelay=E2=80=9D, =E2=80=9Cdelivery=E2=80=9D = system or both. It will also=20 include information whether the header field is allowed to be added=20 multiple times or just once. Only header fields that are already=20 registered in=20 =20 (whether it is registered as a Permanent Message Header Field Name or as=20 a Provisional Message Header Field Name) can appear in this new=20 subregistry. Registration policy for this new subregistry is =E2=80=9CExpert= =20 Review=E2=80=9D. Notes: a) the reason why I am suggesting to create a new subregistry is because=20 I think this will be far less work. The same registry is currently also=20 used by HTTP and NNTP, so adding extra columns to convey the above=20 information would likely confuse HTTP users of the registry. It would=20 also be easier to do this if there is no need to get buy in from other=20 users of the registry. b) I believe John asked whether this should be "First Come First Served"=20 or "Expert Review". I proposed to do the latter to make sure that=20 somebody checks that a particular header field is indeeded added during=20 relay/final delivery/both. The review process can be lightweight. Comments please. Best Regards, Alexey From nobody Mon Nov 16 09:10:36 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 E72DC3A138E for ; Mon, 16 Nov 2020 09:10:30 -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 9n-SFjbYfJ_u for ; Mon, 16 Nov 2020 09:10:29 -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 787693A133D for ; Mon, 16 Nov 2020 09:10:26 -0800 (PST) Received: by sdaoden.eu (Postfix, from userid 1000) id 5CDA516057; Mon, 16 Nov 2020 18:10:25 +0100 (CET) Date: Mon, 16 Nov 2020 18:10:24 +0100 From: Steffen Nurpmeso To: Michael Peddemors Cc: emailcore@ietf.org, Steffen Nurpmeso Message-ID: <20201116171024.O9qeB%steffen@sdaoden.eu> In-Reply-To: <3966c613-b159-1ace-6f0b-297aa304a94f@linuxmagic.com> References: <96736BC4D69B0E29F09A2DBF@PSB> <3966c613-b159-1ace-6f0b-297aa304a94f@linuxmagic.com> Mail-Followup-To: Michael Peddemors , emailcore@ietf.org, Steffen Nurpmeso User-Agent: s-nail v14.9.19-162-g58c95b43 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] Agenda for Tuesday 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, 16 Nov 2020 17:10:36 -0000 Michael Peddemors wrote in <3966c613-b159-1ace-6f0b-297aa304a94f@linuxmagic.com>: |This does bring about an interesting point, that might need to be |brought up in the IETF as a whole, is that engagement on topics in my |opinion, has been dropping off in general. | |It is possibly time that the IETF consider ways to bring more industry |people into the conversations that affect everyone. Please not even more people from the industry who live on the fee of their business employers and have to prove performance records, and have to solve (very) specific (and particular) problems. It has been a long time since truly substantial RFCs like RFC 1149 have been produced. |We do need a new generation of highly engaged people on various topics |to the IETF discussions. I don't have any answers to that, but if there |is someone that can gather engagement statistics over the last 10 years, |it might be interesting. Yes, exactly. The sheer number of RFCs which explicitly talk about the essence of things ("cost reduction") alone. It seems to me that of all the internet i use, almost a hundred percent are driven by decade (plural) old standards. (Except for DNS which unfortunately is forced to HTTP and needs to use resource records i do not like.) Looking at the SMTP agenda (i watch only out of interest) it seems substantial faults have to be corrected! Sudden new circumstances and prospects which have to addressed will surely come up at times. Until then a tremendous amount of engineered standards will exist and be ready for use. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Mon Nov 16 09:20:11 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 C6EC13A131B for ; Mon, 16 Nov 2020 09:20:09 -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 6EJ5w97eGoMT for ; Mon, 16 Nov 2020 09:20:08 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id A781C3A131A for ; Mon, 16 Nov 2020 09:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1605547207; d=isode.com; s=june2016; i=@isode.com; bh=S+0dT5jpThRcyHJeRNcx2zZ/mdFseHwTb9yg0ns32QM=; 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=o9ef1KWYzIzyyeMLfuUR7Mijf/Bg1dov3VrsxxXM4BBcirqx1MMV2572Jsz0Ts8hCz2+E+ vZrUDNSB3byuJFUFeYy9TMhVWdBACfRKNVFG0UzhPd5jkhfjU3LXa2aHCYg17M5XxuniMZ Ah13vk0XqVVWNurUgHwNKRNpEKmqbW8=; Received: from [192.168.0.5] ((unknown) [176.252.130.164]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 16 Nov 2020 17:20:07 +0000 X-SMTP-Protocol-Errors: NORDNS To: emailcore@ietf.org From: Alexey Melnikov Message-ID: <0cc7e71d-e12c-a990-d628-749699e7a495@isode.com> Date: Mon, 16 Nov 2020 17:20:06 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [Emailcore] Ticket #9: G.7.3. Resolvable FQDN in SMTP and private domain names 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, 16 Nov 2020 17:20:10 -0000 Dear WG participants, Another rfc5321bis issue for your consideration: In Section 2.3.5 ("Domain Names"): =C2=A0=C2=A0=C2=A0 Only resolvable, fully-qualified domain names (FQDNs) ar= e permitted=20 when domain names are used in SMTP. John's Note (as the editor): does "in the public DNS" or equivalent need=20 to be added to "resolvable"??? My personal opinion: I don't think we should require "in the public=20 DNS", as as SMTP works just fine with split horizon or private DNS servers. In order to stimulate discussion of this topic I would like to propose=20 the following strawman: "Resolvable" can mislead readers to think that they need to attempt=20 resolve all domain names when received. I don't think this is intended.=20 I would like to propose to drop "resolvable" from the sentence quoted=20 above. Possibly discuss "private domain names" in the Applicability=20 Statement draft. Thoughts? Best Regards, Alexey From nobody Mon Nov 16 09:32: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 23E8A3A1333 for ; Mon, 16 Nov 2020 09:32:09 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEUvxb-9WozD for ; Mon, 16 Nov 2020 09:32:08 -0800 (PST) Received: from mail-ob1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id D8E0F3A1331 for ; Mon, 16 Nov 2020 09:32:07 -0800 (PST) Received: (qmail 7851 invoked from network); 16 Nov 2020 17:32:07 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (a62d8dee-2831-11eb-ada1-7bf33805d6d0); Mon, 16 Nov 2020 09:32:07 -0800 To: emailcore@ietf.org References: From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: Date: Mon, 16 Nov 2020 09:32:07 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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 3.11 and newer X-MagicMail-UUID: a62d8dee-2831-11eb-ada1-7bf33805d6d0 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 #8: Need a registry of header fields that are Ok to add after submission 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, 16 Nov 2020 17:32:09 -0000 On 2020-11-16 9:10 a.m., Alexey Melnikov wrote: > b) I believe John asked whether this should be "First Come First Served" > or "Expert Review". I proposed to do the latter to make sure that > somebody checks that a particular header field is indeeded added during > relay/final delivery/both. The review process can be lightweight. While this may be an attractive notion, it will generate critisicm if the IETF gets to be the 'police' of which headers are allowed. AS well, the industry routinely starts using new headers for various purposes, and it isn't always feasible to wait on an 'approval' that the header is accepted.. While the use of X- headers appears to be no longer encouraged, that was a simple way for vendors to add new trial headers safely. While this 'might' have some benefit in stopping those spammers that insert random headers, in the misguided belief that it will help get around various filtering or beysean tests, that number is relatively low. There are a lot more proprietary headers out there, only used by a single vendor.. I don't think this is a 'cut and dried' benefit, so yes, it should undergo at length discussions.. And there will always be some in the industry that might be concerned that the 'Expert Review' might have some prejudicial positions, whether true or not. The only problem with first come/first serve, is that this would open the door to abuse, as well becoming a very large list. My thoughts.. -- "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 Mon Nov 16 09:41:38 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 A9F623A1337 for ; Mon, 16 Nov 2020 09:41:36 -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 cQB6gaugG08z for ; Mon, 16 Nov 2020 09:41:35 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id E01203A133C for ; Mon, 16 Nov 2020 09:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1605548494; d=isode.com; s=june2016; i=@isode.com; bh=tDYU4U7J/MxO/OREBiWpRGx0JDIVaWNZMRhXRbCKskw=; 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=R10ce9SZGiBbVz76N8dvmL+r4L5VUJXvW2fssJrKIWlzxQSlfaattwkCrVTAJkrOosNY48 QT81CSzGNRUTc79nGBnpYkJtf29A9TYlDbpFrcY1LT/ULBKzubAeNwYdyYPlo51DbwAjwB akrbm/Jq7+4ftErR/yF3kOMr0j4gEY0=; Received: from [192.168.0.5] ((unknown) [176.252.130.164]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 16 Nov 2020 17:41:33 +0000 X-SMTP-Protocol-Errors: NORDNS To: emailcore@ietf.org From: Alexey Melnikov Message-ID: <35ab0a5a-2758-4c64-9f66-3a5f3d8d7a26@isode.com> Date: Mon, 16 Nov 2020 17:41:32 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [Emailcore] Ticket #27: Erratum 4315: IPv6 ABNF needs updating to align with RFC 5952 and RFC 3986 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, 16 Nov 2020 17:41:37 -0000 Dear collegues, This ticket took me a bit of time to investigate, so it might be a bit=20 tricky (not that anything in this WG is easy ;-)). Basically erratum=20 4315 requested upgrade to IPv6 address ABNF in the document to match=20 [RFC 3986]=C2=A0 (URI spec) and [RFC 5952] (A Recommendation for IPv6 Addres= s=20 Text Representation). There was a specific proposal in the erratum, but=20 I think John's solution (which is currently in the draft) is better: IPv6-addr =3D 6( h16 ":" ) ls32 =C2=A0=C2=A0=C2=A0 / "::" 5( h16 ":" ) ls32 =C2=A0=C2=A0=C2=A0 / [ h16 ] "::" 4( h16 ":" ) ls32 =C2=A0=C2=A0=C2=A0 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 =C2=A0=C2=A0=C2=A0 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 =C2=A0=C2=A0=C2=A0 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 =C2=A0=C2=A0=C2=A0 / [ *4( h16 ":" ) h16 ] "::" ls32 =C2=A0=C2=A0=C2=A0 / [ *5( h16 ":" ) h16 ] "::" h16 =C2=A0=C2=A0=C2=A0 / [ *6( h16 ":" ) h16 ] "::" =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ; This definition is consistent = with the one for =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ; URIs [40]. ls32 =3D ( h16 ":" h16 ) / IPv4address =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ; least-significant 32 bits of a= ddress h16 =3D 1*4HEXDIG =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ; 16 bits of address represented= in hexadecimal Basically IPv6-addr looks very similar to what is in RFC 3986, so it is=20 easy to verify correctness. However, RFC 3986 doesn't follow advice from RFC 5952, as it predates=20 it. Some minor issues I've noticed with the above ABNF: RFC 5952, 4.1. Handling Leading Zeros in a 16-Bit Field =C2=A0=C2=A0=C2=A0 Leading zeros MUST be suppressed. For example, 2001:0db8= ::0001 is =C2=A0=C2=A0=C2=A0 not acceptable and must be represented as 2001:db8::1. A= single 16- =C2=A0=C2=A0=C2=A0 bit 0000 field MUST be represented as 0. 4.3. Lowercase =C2=A0=C2=A0=C2=A0 The characters "a", "b", "c", "d", "e", and "f" in an IP= v6 address =C2=A0=C2=A0=C2=A0 MUST be represented in lowercase. Both of these would probably affect h16, which can be tweaked to make it=20 clear that leading "0" are prohibited and only lowercase is to be used.=20 (HEXDIG allows uppercase hex at the moment). This made me wonder though:=20 are there any backward compatibility issues with changing this (e.g. to=20 disallow uppercase hex)? Should we have 2 grammars, "strict" one for=20 what should be generated and a more relaxed one for what should be accepted? Best Regards, Alexey From nobody Mon Nov 16 09:51:24 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 7832F3A135B for ; Mon, 16 Nov 2020 09:51:23 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2J82STKsW36e for ; Mon, 16 Nov 2020 09:51:22 -0800 (PST) Received: from mail-ob3.cityemail.com (mail-ob3.cityemail.com [104.128.152.20]) by ietfa.amsl.com (Postfix) with ESMTP id 65AA23A1358 for ; Mon, 16 Nov 2020 09:51:22 -0800 (PST) Received: (qmail 8151 invoked from network); 16 Nov 2020 17:51:22 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe3.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (56783788-2834-11eb-866e-c3cf96172283); Mon, 16 Nov 2020 09:51:22 -0800 To: emailcore@ietf.org References: <35ab0a5a-2758-4c64-9f66-3a5f3d8d7a26@isode.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <939f1a0b-852f-c1b0-5985-40e67f34d195@linuxmagic.com> Date: Mon, 16 Nov 2020 09:51:21 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <35ab0a5a-2758-4c64-9f66-3a5f3d8d7a26@isode.com> 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: 56783788-2834-11eb-866e-c3cf96172283 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 #27: Erratum 4315: IPv6 ABNF needs updating to align with RFC 5952 and RFC 3986 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, 16 Nov 2020 17:51:24 -0000 On 2020-11-16 9:41 a.m., Alexey Melnikov wrote: > Both of these would probably affect h16, which can be tweaked to make it > clear that leading "0" are prohibited and only lowercase is to be used. > (HEXDIG allows uppercase hex at the moment). This made me wonder though: > are there any backward compatibility issues with changing this (e.g. to > disallow uppercase hex)? Should we have 2 grammars, "strict" one for > what should be generated and a more relaxed one for what should be > accepted? Not a bad approach, the 2 grammar idea.. Lends itself to a longer term enforcement of all lower case. -- "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 Mon Nov 16 10:28:52 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 096B73A1386 for ; Mon, 16 Nov 2020 10:28:51 -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 rIxbbR-fxY3x for ; Mon, 16 Nov 2020 10:28:49 -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 66B8C3A1384 for ; Mon, 16 Nov 2020 10:28:49 -0800 (PST) Received: by sdaoden.eu (Postfix, from userid 1000) id 6983116057; Mon, 16 Nov 2020 19:28:47 +0100 (CET) Date: Mon, 16 Nov 2020 19:28:47 +0100 From: Steffen Nurpmeso To: Alexey Melnikov Cc: emailcore@ietf.org, Steffen Nurpmeso Message-ID: <20201116182847.webSL%steffen@sdaoden.eu> In-Reply-To: <35ab0a5a-2758-4c64-9f66-3a5f3d8d7a26@isode.com> References: <35ab0a5a-2758-4c64-9f66-3a5f3d8d7a26@isode.com> Mail-Followup-To: Alexey Melnikov , emailcore@ietf.org, Steffen Nurpmeso User-Agent: s-nail v14.9.19-162-g58c95b43 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Ticket #27: Erratum 4315: IPv6 ABNF needs updating to align with RFC 5952 and RFC 3986 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, 16 Nov 2020 18:28:51 -0000 Alexey Melnikov wrote in <35ab0a5a-2758-4c64-9f66-3a5f3d8d7a26@isode.com>: |This ticket took me a bit of time to investigate, so it might be a bit=20 |tricky (not that anything in this WG is easy ;-)). Basically erratum=20 |4315 requested upgrade to IPv6 address ABNF in the document to match=20 |[RFC 3986]=C2=A0 (URI spec) and [RFC 5952] (A Recommendation for IPv6 Add= ress=20 |Text Representation). There was a specific proposal in the erratum, but= =20 |I think John's solution (which is currently in the draft) is better: | |IPv6-addr ... |Basically IPv6-addr looks very similar to what is in RFC 3986, so it is= =20 |easy to verify correctness. | |However, RFC 3986 doesn't follow advice from RFC 5952, as it predates=20 |it. Some minor issues I've noticed with the above ABNF: | |RFC 5952, 4.1. Handling Leading Zeros in a 16-Bit Field | =C2=A0=C2=A0=C2=A0 Leading zeros MUST be suppressed. For example, 2001:0= db8::0001 is | =C2=A0=C2=A0=C2=A0 not acceptable and must be represented as 2001:db8::1= . A single 16- | =C2=A0=C2=A0=C2=A0 bit 0000 field MUST be represented as 0. | |4.3. Lowercase | =C2=A0=C2=A0=C2=A0 The characters "a", "b", "c", "d", "e", and "f" in an= IPv6 address | =C2=A0=C2=A0=C2=A0 MUST be represented in lowercase. | |Both of these would probably affect h16, which can be tweaked to make it= =20 |clear that leading "0" are prohibited and only lowercase is to be used.= =20 |(HEXDIG allows uppercase hex at the moment). This made me wonder though:= =20 |are there any backward compatibility issues with changing this (e.g. to= =20 |disallow uppercase hex)? Should we have 2 grammars, "strict" one for=20 |what should be generated and a more relaxed one for what should be \ |accepted? I had written an IP address class which supported IPv4 and IPv6, as of RFC 1884, which means, for the string representation, compression was optional and upper- and lowercase were both possible. (Personally i liked that, as it is no problem on the parser nor generator side (despite my code being ugly), and why artificially encforcing people to do things for no technical reason is beyond my worldview.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Mon Nov 16 10:31:31 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 A3FA43A1384 for ; Mon, 16 Nov 2020 10:31:29 -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 gzEcP89QCU5j for ; Mon, 16 Nov 2020 10:31:28 -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 415CE3A138C for ; Mon, 16 Nov 2020 10:31:28 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kejHi-0003JN-Ga; Mon, 16 Nov 2020 13:31:26 -0500 Date: Mon, 16 Nov 2020 13:31:20 -0500 From: John C Klensin To: Michael Peddemors cc: emailcore@ietf.org Message-ID: In-Reply-To: <3966c613-b159-1ace-6f0b-297aa304a94f@linuxmagic.com> References: <96736BC4D69B0E29F09A2DBF@PSB> <3966c613-b159-1ace-6f0b-297aa304a94f@linuxmagic.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Agenda for Tuesday 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, 16 Nov 2020 18:31:30 -0000 --On Monday, November 16, 2020 08:35 -0800 Michael Peddemors wrote: > Hi John, > > This does bring about an interesting point, that might need to > be brought up in the IETF as a whole, is that engagement on > topics in my opinion, has been dropping off in general. > > It is possibly time that the IETF consider ways to bring more > industry people into the conversations that affect everyone. > > We do need a new generation of highly engaged people on > various topics to the IETF discussions. I don't have any > answers to that, but if there is someone that can gather > engagement statistics over the last 10 years, it might be > interesting. > > Not sure where to cc' that conversation, but I do think it is > a trend on many of the working group conversations. Michael, While not as concerned as Steffen is, or perhaps concerned differently, I share both his concern and yours. In addition to all of the things that are special about the IETF, I've seen a pattern that seems very common across standards bodies (and I've worked in several and closely observed many more). The problem is that, when a technology area that is a candidate for standardization is still new, organizations tend to send their front-line designers and developers both to shape the standard and to learn from similar people in other organizations and with other perspectives. Certainly (although they weren't even talking about standards yet) that was the case in the meetings and other exchanges about the early development of the ARPANET and Internet and even in the IETF. But, as standards and implementations stabilize, specifications go through an iteration/ refinement or two, and there is a good deal of deployment, those same organizations (and often the designers and implementation leads themselves) conclude that those people have better ways to spend their time than polishing the relevant standards to a high gloss. Instead, they either drop out or start seeing people who are less critical to the company's mission and who may be coming with primary goals of observing and reporting back about what is going on, protecting the design decisions in the company's product, and otherwise not contributing in a useful way (unless one counts nit-picking and attending, or even sponsoring, Fine Lunches and Dinners). There is often an even worse effect, but I'll skip than in the interests of time. I think we have seen some symptoms of that trend in the IETF already, so be careful what you wish for. And, no, I don't know what to do to reverse that trend or even keep it from getting worse. I do know that some of those other standards bodies have controls to mitigate the worst effects that the IETF refuses to consider, but, again, that is a longer story. best, john From nobody Mon Nov 16 11:17:26 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 9974A3A13BE; Mon, 16 Nov 2020 11:17:19 -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 k-LbdZI73x7v; Mon, 16 Nov 2020 11:17:17 -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 7FB863A07F9; Mon, 16 Nov 2020 11:17:17 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kek04-0003iB-0Y; Mon, 16 Nov 2020 14:17:16 -0500 Date: Mon, 16 Nov 2020 14:17:10 -0500 From: John C Klensin To: art-ads@ietf.org cc: emailcore-chairs@ietf.org, 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] Obnoxious, 11th hour, appeal of the decision to hold an emailcore meeting 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, 16 Nov 2020 19:17:25 -0000 Barry and Murray, About 12 hours ago (much later than it should have been), I posted a note to the emailcore list questioning the appropriateness of holding a formal WG meeting given that none of the topics on the agenda had received any mailing list discussion since the WG was chartered. That message has gotten no response from either of the co-chairs. Instead, there have been several postings of questions and issues to be resolved from Alexey. Having no discussion on the mailing list and requests for specific discussion in well under 24 hours before a WG meeting during IETF is inconsistent with many (or all) of our principles about having materials available so that people can consider them well before a WG meeting and preferably before IETF starts. I have seen nothing from the IESG (or even in SHMOO discussions) that would change those principles for an all-virtual meeting. So I am requesting that the EMAILCORE meeting scheduled for tomorrow's "Session II" slot be either cancelled or (at least) postponed until the end of the week with strict instructions from you about when new (to the mailing list) topics can be introduced. I note that there is no evidence that the items listed on the agenda could not be settled on the mailing list (because that has not been tried) so there is a reasonable hypothesis that canceling tomorrow's meeting will delay the WG's schedule. It might even get people's attention and speed things up. I also note that there is precedent for canceling a WG meeting during an IETF this close, or closer, to the meeting time. I have a low level of expectation that the request will be granted. There will clearly be no appeal from whatever you decide (or avoid deciding) to the full IESG because, by the time it could be considered, or even posted, it would be moot. However, I do want it on the record that I have identified a procedural problem and that I have asked. obnoxiously yours, john From nobody Mon Nov 16 14:10:52 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 359033A1520; Mon, 16 Nov 2020 14:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhSA3afTYDs6; Mon, 16 Nov 2020 14:10:50 -0800 (PST) Received: from mail-ua1-f42.google.com (mail-ua1-f42.google.com [209.85.222.42]) (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 D59E83A15E8; Mon, 16 Nov 2020 14:10:20 -0800 (PST) Received: by mail-ua1-f42.google.com with SMTP id t15so5863534ual.6; Mon, 16 Nov 2020 14:10:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Pz4VuaEnaAr8G4PuihNhoFbIaxlAuRA/V0GuevPNEns=; b=i34Vik84sVgHmNcVUHqPszpw28at7R0fnezC5PRiSMHj5nF1weuFT+MOyHO8pDV0Nj Pd5ly/3yFF1JDObAGs4BEfEPHkdwIPUXdOG+Gz2Nmn3PooLKyIFK5j1EW7KCNdrUCdF+ IaWOqhBDMqQ3mTXiITh3ePZYg8feABXb1cZ3RH43aX/I7lnTephU8EVlmuXY7zw53e4Y UJBv4Plqj+3f+5JOPkWYHP8Y2wAN5nDHSlJeVrpuNipHKUb/VonAdKWD3YInhlHErUyL CRmorY1ZAwdCYaxX7Nv7XPy+nq71yNmRl83pEBkkkwWODDCAOTtpBlx0s0wlNKI3y7c8 cmHw== X-Gm-Message-State: AOAM530wHRUlVX5jvvI+Vx3OsOmnrccuuaz1xjSMybrSrhRmrdfFX3E3 rtKZpv2WZgMzUTdD7fq4MB+AeMco6X1P51/nExpczcozExM= X-Google-Smtp-Source: ABdhPJwaXbcbJu9vTGvKs0hAsQn3MpFK5K8Y2oo9zJhYreK4gAJnUVDgltfB3oQhft6iRLIUAgvUyx/IYjfqEnPTxn0= X-Received: by 2002:ab0:3054:: with SMTP id x20mr7628141ual.72.1605564619640; Mon, 16 Nov 2020 14:10:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Mon, 16 Nov 2020 17:10:08 -0500 Message-ID: To: John C Klensin Cc: art-ads@ietf.org, emailcore@ietf.org, emailcore-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000d1510e05b440a46c" Archived-At: Subject: Re: [Emailcore] Obnoxious, 11th hour, appeal of the decision to hold an emailcore meeting 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, 16 Nov 2020 22:10:51 -0000 --000000000000d1510e05b440a46c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, John, and thanks for raising this. Given the tight lead time for this, I prefer to leave the decision to the chairs, but: 1. Postponing until Friday is not an option, as the overall meeting agenda is full, and my agenda as AD is definitely full (I have a WG session I=E2= =80=99m responsible for in every slot). I also see no reason to believe that we=E2= =80=99ll be any more prepared for a useful session on Friday than on Tuesday: I think we need more time than that. 2. I think the best approach is to cancel the emailcore session at 109 and schedule an interim meeting within the upcoming 4 weeks. I urge the chairs to seriously consider this, and to let me, the Secretariat, and the working group know quickly. Barry On Mon, Nov 16, 2020 at 2:17 PM John C Klensin wrote: > Barry and Murray, > > About 12 hours ago (much later than it should have been), I > posted a note to the emailcore list questioning the > appropriateness of holding a formal WG meeting given that none > of the topics on the agenda had received any mailing list > discussion since the WG was chartered. > > That message has gotten no response from either of the > co-chairs. Instead, there have been several postings of > questions and issues to be resolved from Alexey. > > Having no discussion on the mailing list and requests for > specific discussion in well under 24 hours before a WG meeting > during IETF is inconsistent with many (or all) of our principles > about having materials available so that people can consider > them well before a WG meeting and preferably before IETF starts. > I have seen nothing from the IESG (or even in SHMOO discussions) > that would change those principles for an all-virtual meeting. > > So I am requesting that the EMAILCORE meeting scheduled for > tomorrow's "Session II" slot be either cancelled or (at least) > postponed until the end of the week with strict instructions > from you about when new (to the mailing list) topics can be > introduced. I note that there is no evidence that the items > listed on the agenda could not be settled on the mailing list > (because that has not been tried) so there is a reasonable > hypothesis that canceling tomorrow's meeting will delay the WG's > schedule. It might even get people's attention and speed things > up. I also note that there is precedent for canceling a WG > meeting during an IETF this close, or closer, to the meeting > time. > > I have a low level of expectation that the request will be > granted. There will clearly be no appeal from whatever you > decide (or avoid deciding) to the full IESG because, by the time > it could be considered, or even posted, it would be moot. > However, I do want it on the record that I have identified a > procedural problem and that I have asked. > > obnoxiously yours, > john > > --000000000000d1510e05b440a46c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, John, and thanks for raising this.

Given the tight lead time for this, I pref= er to leave the decision to the chairs, but:

1. Postponing until Friday is not an option, as the ov= erall meeting agenda is full, and my agenda as AD is definitely full (I hav= e a WG session I=E2=80=99m responsible for in every slot).=C2=A0 I also see= no reason to believe that we=E2=80=99ll be any more prepared for a useful = session on Friday than on Tuesday: I think we need more time than that.

2. I think the best approac= h is to cancel the emailcore session at 109 and schedule an interim meeting= within the upcoming 4 weeks.=C2=A0 I urge the chairs to seriously consider= this, and to let me, the Secretariat, and the working group know quickly.<= /div>

Barry

On Mon, Nov 16= , 2020 at 2:17 PM John C Klensin <j= ohn-ietf@jck.com> wrote:
Bar= ry and Murray,

About 12 hours ago (much later than it should have been), I
posted a note to the emailcore list questioning the
appropriateness of holding a formal WG meeting given that none
of the topics on the agenda had received any mailing list
discussion since the WG was chartered.

That message has gotten no response from either of the
co-chairs.=C2=A0 Instead, there have been several postings of
questions and issues to be resolved from Alexey.=C2=A0

Having no discussion on the mailing list and requests for
specific discussion in well under 24 hours before a WG meeting
during IETF is inconsistent with many (or all) of our principles
about having materials available so that people can consider
them well before a WG meeting and preferably before IETF starts.
I have seen nothing from the IESG (or even in SHMOO discussions)
that would change those principles for an all-virtual meeting.

So I am requesting that the EMAILCORE meeting scheduled for
tomorrow's "Session II" slot be either cancelled or (at least= )
postponed until the end of the week with strict instructions
from you about when new (to the mailing list) topics can be
introduced.=C2=A0 I note that there is no evidence that the items
listed on the agenda could not be settled on the mailing list
(because that has not been tried) so there is a reasonable
hypothesis that canceling tomorrow's meeting will delay the WG's schedule.=C2=A0 It might even get people's attention and speed things up.=C2=A0 =C2=A0I also note that there is precedent for canceling a WG
meeting during an IETF this close, or closer, to the meeting
time.

I have a low level of expectation that the request will be
granted.=C2=A0 There will clearly be no appeal from whatever you
decide (or avoid deciding) to the full IESG because, by the time
it could be considered, or even posted, it would be moot.
However, I do want it on the record that I have identified a
procedural problem and that I have asked.

obnoxiously yours,
=C2=A0 =C2=A0 john

--000000000000d1510e05b440a46c-- From nobody Mon Nov 16 14:46:28 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 63D793A15ED for ; Mon, 16 Nov 2020 14:46:27 -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=unavailable 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 0I8iQRTaxSXO for ; Mon, 16 Nov 2020 14:46:24 -0800 (PST) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 361853A15EE for ; Mon, 16 Nov 2020 14:46:24 -0800 (PST) Received: by mail-vs1-xe36.google.com with SMTP id y78so10022304vsy.6 for ; Mon, 16 Nov 2020 14:46:24 -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 :cc; bh=r2576qnr/BJVa9euxxpwKeCcpHgutthzrXH0xM/HwKw=; b=eXs7NDdKIamxcqF2SUQ9YDIPgjgTCQxdMqMCDdeDc+gFA5EAxRgbQ8Z5ZBJiMcVKd5 CKiKQ95axIxDqCt98jJPE2WPumDUUAiwlSy60xSk3MVCbVr8E7QVgdwJhIM69R6rtAQx DYit1Dzxi+pFVetpz8UFf4WeS5jqPKTehDipDD6ge0z7J/H7Xk4awxiOIhrdHOHLh2xG x+CjbS4J5zEhzoZ+7QuW2NHYsivaTt7FQmnFZTT47S4B5y/nske92Db298t3XQLRpF+O 8cuzNdSYsAS+g/SEDlpIVN9gyZbPXsc8jNLtAAb7A4ishGLWVjuPweIJ74VSJrGiDyNj KxUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r2576qnr/BJVa9euxxpwKeCcpHgutthzrXH0xM/HwKw=; b=kUbbAIkUo9I4hcHXlYAULEEbew+ecGy80zM6Z5vWl7SQoBNh2uYlk4Py6Os+1mu69h OvPWtUiUXLO20k4x0sY2IqhqsXp2M8639JZY3OGKedIzdQbq2J1hD8Liy91JcsSzpAH4 qXR4j1pjiW3mJiG4gOEEyPGvzqchTa+SdIRNI1ksnLxKBUm9/O9C1kfLYCllXWVJR3e9 Tn2fznhv6P5VXqOM4eLP8OGc+cqYGNssmNMrSg99fq9v/K0OVJwwuMBAKkXLPr3KXKYj m7D43IfvvlUwNrJa1AW44oOsVZhfTcXF1Tb1HGAg0EmKlal1KwNiMiswNuhWo9TqirfK Y6yw== X-Gm-Message-State: AOAM532xaKk+CkvZd4JdCfeJgtMZUxfrnZSNeLxt23RYkxP2FQEmpoBY JokGKV1wOe2lBnXSVZs76pDoOkuy47qWlFAJGQ3DJhAB+/c4Bw== X-Google-Smtp-Source: ABdhPJzjhvrU2wwkYLFb+msQFNHjWF8wf5MZ9En4sKdWsA/Ao9Tt0q5ix9os977kbPToXljGL8ZVMzck8IEEd4pTLPE= X-Received: by 2002:a67:db91:: with SMTP id f17mr9514684vsk.41.1605566782803; Mon, 16 Nov 2020 14:46:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Seth Blank Date: Mon, 16 Nov 2020 14:46:12 -0800 Message-ID: To: emailcore@ietf.org Cc: John C Klensin , ART ADs , emailcore-chairs@ietf.org, Barry Leiba Content-Type: multipart/alternative; boundary="000000000000c0a90305b4412542" Archived-At: Subject: Re: [Emailcore] Obnoxious, 11th hour, appeal of the decision to hold an emailcore meeting 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, 16 Nov 2020 22:46:27 -0000 --000000000000c0a90305b4412542 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John and Barry, The Chairs wish to hold today's session at 109. We believe it will be productive in accelerating on-list conversations, assuming a critical mass of participants actually in attendance. We can also hold an interim in December, and likely will if there are substantive topics that need discussion or there's a set of tickets that aren't moving in a timely manner on the list. Thanks, Seth and Alexey, as Chairs On Mon, Nov 16, 2020 at 2:11 PM Barry Leiba wrote= : > Hi, John, and thanks for raising this. > > Given the tight lead time for this, I prefer to leave the decision to the > chairs, but: > > 1. Postponing until Friday is not an option, as the overall meeting agend= a > is full, and my agenda as AD is definitely full (I have a WG session I=E2= =80=99m > responsible for in every slot). I also see no reason to believe that we= =E2=80=99ll > be any more prepared for a useful session on Friday than on Tuesday: I > think we need more time than that. > > 2. I think the best approach is to cancel the emailcore session at 109 an= d > schedule an interim meeting within the upcoming 4 weeks. I urge the chai= rs > to seriously consider this, and to let me, the Secretariat, and the worki= ng > group know quickly. > > Barry > > On Mon, Nov 16, 2020 at 2:17 PM John C Klensin wrote: > >> Barry and Murray, >> >> About 12 hours ago (much later than it should have been), I >> posted a note to the emailcore list questioning the >> appropriateness of holding a formal WG meeting given that none >> of the topics on the agenda had received any mailing list >> discussion since the WG was chartered. >> >> That message has gotten no response from either of the >> co-chairs. Instead, there have been several postings of >> questions and issues to be resolved from Alexey. >> >> Having no discussion on the mailing list and requests for >> specific discussion in well under 24 hours before a WG meeting >> during IETF is inconsistent with many (or all) of our principles >> about having materials available so that people can consider >> them well before a WG meeting and preferably before IETF starts. >> I have seen nothing from the IESG (or even in SHMOO discussions) >> that would change those principles for an all-virtual meeting. >> >> So I am requesting that the EMAILCORE meeting scheduled for >> tomorrow's "Session II" slot be either cancelled or (at least) >> postponed until the end of the week with strict instructions >> from you about when new (to the mailing list) topics can be >> introduced. I note that there is no evidence that the items >> listed on the agenda could not be settled on the mailing list >> (because that has not been tried) so there is a reasonable >> hypothesis that canceling tomorrow's meeting will delay the WG's >> schedule. It might even get people's attention and speed things >> up. I also note that there is precedent for canceling a WG >> meeting during an IETF this close, or closer, to the meeting >> time. >> >> I have a low level of expectation that the request will be >> granted. There will clearly be no appeal from whatever you >> decide (or avoid deciding) to the full IESG because, by the time >> it could be considered, or even posted, it would be moot. >> However, I do want it on the record that I have identified a >> procedural problem and that I have asked. >> >> obnoxiously yours, >> john >> >> --=20 *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 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. --000000000000c0a90305b4412542 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John and Barry,

The Chairs wish to hold today= 9;s session at 109. We believe it will be productive in accelerating on-lis= t conversations, assuming a critical mass of participants actually in atten= dance.

We can also hold an interim in December, and likely will if t= here are substantive topics that need discussion or there's a set of ti= ckets that aren't moving in a timely manner on the list.

Thanks,=

Seth and Alexey, as Chairs

=
On Mon, Nov 16, 2020 at 2:11 PM Barry= Leiba <barryleiba@computer.o= rg> wrote:
Hi, John, and thanks for raising this.

Given the tight lead time for this, I pr= efer to leave the decision to the chairs, but:

<= /div>
1. Postponing until Friday is not an option, as the = overall meeting agenda is full, and my agenda as AD is definitely full (I h= ave a WG session I=E2=80=99m responsible for in every slot).=C2=A0 I also s= ee no reason to believe that we=E2=80=99ll be any more prepared for a usefu= l session on Friday than on Tuesday: I think we need more time than that.

2. I think the best appro= ach is to cancel the emailcore session at 109 and schedule an interim meeti= ng within the upcoming 4 weeks.=C2=A0 I urge the chairs to seriously consid= er this, and to let me, the Secretariat, and the working group know quickly= .

Barry

On Mon, Nov = 16, 2020 at 2:17 PM John C Klensin <john-ietf@jck.com> wrote:
Barry and Murray,

About 12 hours ago (much later than it should have been), I
posted a note to the emailcore list questioning the
appropriateness of holding a formal WG meeting given that none
of the topics on the agenda had received any mailing list
discussion since the WG was chartered.

That message has gotten no response from either of the
co-chairs.=C2=A0 Instead, there have been several postings of
questions and issues to be resolved from Alexey.=C2=A0

Having no discussion on the mailing list and requests for
specific discussion in well under 24 hours before a WG meeting
during IETF is inconsistent with many (or all) of our principles
about having materials available so that people can consider
them well before a WG meeting and preferably before IETF starts.
I have seen nothing from the IESG (or even in SHMOO discussions)
that would change those principles for an all-virtual meeting.

So I am requesting that the EMAILCORE meeting scheduled for
tomorrow's "Session II" slot be either cancelled or (at least= )
postponed until the end of the week with strict instructions
from you about when new (to the mailing list) topics can be
introduced.=C2=A0 I note that there is no evidence that the items
listed on the agenda could not be settled on the mailing list
(because that has not been tried) so there is a reasonable
hypothesis that canceling tomorrow's meeting will delay the WG's schedule.=C2=A0 It might even get people's attention and speed things up.=C2=A0 =C2=A0I also note that there is precedent for canceling a WG
meeting during an IETF this close, or closer, to the meeting
time.

I have a low level of expectation that the request will be
granted.=C2=A0 There will clearly be no appeal from whatever you
decide (or avoid deciding) to the full IESG because, by the time
it could be considered, or even posted, it would be moot.
However, I do want it on the record that I have identified a
procedural problem and that I have asked.

obnoxiously yours,
=C2=A0 =C2=A0 john



--

Seth Blank | VP, Standards = and New Technologies
p:= 415.273.8818


= This email and all= data transmitted with it contains confidential and/or proprietary informat= ion 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 include= d in this transmission is prohibited and may be unlawful. Please immediatel= y notify the sender by replying to this email and then delete it from your = system.

--000000000000c0a90305b4412542-- From nobody Mon Nov 16 15:00:30 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 D67223A1611; Mon, 16 Nov 2020 15:00:20 -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 EsjZ-isjOkam; Mon, 16 Nov 2020 15:00:19 -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 8D46F3A1614; Mon, 16 Nov 2020 15:00:19 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kenTu-0004ub-2y; Mon, 16 Nov 2020 18:00:18 -0500 Date: Mon, 16 Nov 2020 18:00:12 -0500 From: John C Klensin To: Barry Leiba cc: art-ads@ietf.org, emailcore@ietf.org, emailcore-chairs@ietf.org Message-ID: <838D85B9A36E8B1D34D95E4A@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] Obnoxious, 11th hour, appeal of the decision to hold an emailcore meeting 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, 16 Nov 2020 23:00:21 -0000 --On Monday, November 16, 2020 17:10 -0500 Barry Leiba wrote: > Hi, John, and thanks for raising this. > > Given the tight lead time for this, I prefer to leave the > decision to the chairs, but: > > 1. Postponing until Friday is not an option, as the overall > meeting agenda is full, and my agenda as AD is definitely full > (I have a WG session I'm responsible for in every slot). I > also see no reason to believe that we'll be any more > prepared for a useful session on Friday than on Tuesday: I > think we need more time than that. I mostly agree, but Friday would give me time to review the proposed slides (which I didn't see until this afternoon), Alexey time to get whatever other issues he wanted to see discussed raised on the list, etc. So, whether possible as an option or not, Friday would be at least half-plausible. > 2. I think the best approach is to cancel the emailcore > session at 109 and schedule an interim meeting within the > upcoming 4 weeks. I urge the chairs to seriously consider > this, and to let me, the Secretariat, and the working group > know quickly. Curiously, I proposed almost the same thing to the WG Chairs almost three hours ago. The more I think about it, the more I think that it would be wiser to cancel a meeting tomorrow for which none of us really seem prepared, set a date for an interim immediately so it can be used as the forcing function tomorrow obviously was not, try to get some solid discussion on the list with the chairs actively intervening when people start doing extended tours of rat and/or rabbit holes, and then hold a productive meeting. So, either interest coincidence or great minds thinking alike. thanks, john > On Mon, Nov 16, 2020 at 2:17 PM John C Klensin > wrote: > >> Barry and Murray, >> >> About 12 hours ago (much later than it should have been), I >> posted a note to the emailcore list questioning the >> appropriateness of holding a formal WG meeting given that none >> of the topics on the agenda had received any mailing list >> discussion since the WG was chartered. >> >> That message has gotten no response from either of the >> co-chairs. Instead, there have been several postings of >> questions and issues to be resolved from Alexey. >> >> Having no discussion on the mailing list and requests for >> specific discussion in well under 24 hours before a WG meeting >> during IETF is inconsistent with many (or all) of our >> principles about having materials available so that people >> can consider them well before a WG meeting and preferably >> before IETF starts. I have seen nothing from the IESG (or >> even in SHMOO discussions) that would change those principles >> for an all-virtual meeting. >> >> So I am requesting that the EMAILCORE meeting scheduled for >> tomorrow's "Session II" slot be either cancelled or (at least) >> postponed until the end of the week with strict instructions >> from you about when new (to the mailing list) topics can be >> introduced. I note that there is no evidence that the items >> listed on the agenda could not be settled on the mailing list >> (because that has not been tried) so there is a reasonable >> hypothesis that canceling tomorrow's meeting will delay the >> WG's schedule. It might even get people's attention and >> speed things up. I also note that there is precedent for >> canceling a WG meeting during an IETF this close, or closer, >> to the meeting time. >> >> I have a low level of expectation that the request will be >> granted. There will clearly be no appeal from whatever you >> decide (or avoid deciding) to the full IESG because, by the >> time it could be considered, or even posted, it would be moot. >> However, I do want it on the record that I have identified a >> procedural problem and that I have asked. >> >> obnoxiously yours, >> john >> >> From nobody Mon Nov 16 15:52:26 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 383243A16F9 for ; Mon, 16 Nov 2020 15:52:24 -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=A6yEezDJ; dkim=pass (2048-bit key) header.d=taugh.com header.b=Fp8ZgOFT 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 fuVGXfQFxJBz for ; Mon, 16 Nov 2020 15:52: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 6DF443A16F3 for ; Mon, 16 Nov 2020 15:52:21 -0800 (PST) Received: (qmail 23056 invoked from network); 16 Nov 2020 23:52:20 -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=5a03.5fb310b4.k2011; bh=6nsnCunOW+5D/cdak3nDgbak0BkquKN3MM7m48QvRPo=; b=A6yEezDJ3Qt8rzIOSlAm/7D9n0F9xjMeDqgUG/Be+qZgrcp6V/BMt+c9NETH+NjC1jvkSMJOloq9gbSoqjJei48K6BLBO/Sm61jWfh0wkBVBEPnBhcAZk9tqbliaBq/4pB04sQcrxNarw79x2xtAvZwuoqPg9qEXeeD9io6R3pKU9U89BUn+AREU3WNUMba3UYS6Tn6fHHOIJoQkPkEJwuIPmRYR9yxQVhnBlwtcFf8Mccz/B03ssjxuVFQjRYF1uwd6WoHIroYAwSNUvVU+8D0NPcCeNcS7zVD7Te8jJDBcqdfTttPZinw8Me1uxVGp1FVzjMXU0rDDo5NT8yY4hA== 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=5a03.5fb310b4.k2011; bh=6nsnCunOW+5D/cdak3nDgbak0BkquKN3MM7m48QvRPo=; b=Fp8ZgOFT8caTjy7jczGS3gf2adiTM5woL8xcVS3IoeFcyjm68ZZRyfN2f9YaPP2SrlztvDzbd8s360v91n6n+Uc2QxjBu0KkVzEtnvCpHkbFzSBiFhcMQw0+OYcpYVd3XnCctTqxmWODBm6p5Qj7Lul9vQvvG/QFI3ImuHLmGl3We/0FOEoa1NTYG4Vik3KO13N5KpRFZuqi7mVybK0WTAT82sDHBqMWxinBwfitIY80UBdIFaiOFlS7dMRylp2ezvxwmpQchFDBDPkE9hVcIbVwa2wsAGHNh4FGKHt/k51nlNvJXUw9LbLoNxHlfBYzoi1OuIimN7U5uEIAjFIugA== 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; 16 Nov 2020 23:52:19 -0000 Received: by ary.qy (Postfix, from userid 501) id BF19D272A459; Mon, 16 Nov 2020 18:52:18 -0500 (EST) Date: 16 Nov 2020 18:52:18 -0500 Message-Id: <20201116235218.BF19D272A459@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: alexey.melnikov@isode.com In-Reply-To: <240e4ce1-d90b-285e-8878-d79c9cad70c2@isode.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #4: Exploders seem to be prohibited from adding List-* header fields 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, 16 Nov 2020 23:52:24 -0000 In article <240e4ce1-d90b-285e-8878-d79c9cad70c2@isode.com> you write: >As was already pointed out on the mailing list, the text "the message >header section (RFC 5322 [11]) MUST be left unchanged" seems to prohibit >addition of List-* header fields. It is understanding that the intention here was to prohibit the kind of rewriting that submission servers do, not to prohibit what mailing lists have done for decades. If we change the language I'd say something like it cannot change existing headers except for the ones whose definition says they can be replaced, which at this point means Authentication-Results. R's, John From nobody Mon Nov 16 16:17:39 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 4FD983A1742; Mon, 16 Nov 2020 16:17: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 vu6iuOzG_rdh; Mon, 16 Nov 2020 16:17:36 -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 BC62E3A1741; Mon, 16 Nov 2020 16: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 1keogg-0005Ib-6K; Mon, 16 Nov 2020 19:17:34 -0500 Date: Mon, 16 Nov 2020 19:17:28 -0500 From: John C Klensin To: Seth Blank , emailcore@ietf.org cc: ART ADs , emailcore-chairs@ietf.org, Barry Leiba 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] Obnoxious, 11th hour, appeal of the decision to hold an emailcore meeting 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, 17 Nov 2020 00:17:38 -0000 Barry, Again, consider this an appeal as the meeting schedule (and preparation) are procedurally irregular. No matter how much you would like to leave the decision to the co-chairs, this is an appeal and the buck stops with you. I note for the record that I have not asked you to remove them for relative non-feasance since the WG was chartered. And Seth and Alexey, I am unlikely to be able to make time for two WG meetings (as distinct from mailing list participation and working on the document at hours of my choosing) within a four week period. Didn't sign up for that. Just so you know. john --On Monday, November 16, 2020 14:46 -0800 Seth Blank wrote: > Hi John and Barry, > > The Chairs wish to hold today's session at 109. We believe it > will be productive in accelerating on-list conversations, > assuming a critical mass of participants actually in > attendance. > > We can also hold an interim in December, and likely will if > there are substantive topics that need discussion or there's a > set of tickets that aren't moving in a timely manner on the > list. > > Thanks, > > Seth and Alexey, as Chairs > > On Mon, Nov 16, 2020 at 2:11 PM Barry Leiba > wrote: > >> Hi, John, and thanks for raising this. >> >> Given the tight lead time for this, I prefer to leave the >> decision to the chairs, but: >> >> 1. Postponing until Friday is not an option, as the overall >> meeting agenda is full, and my agenda as AD is definitely >> full (I have a WG session I'm responsible for in every >> slot). I also see no reason to believe that we'll be any >> more prepared for a useful session on Friday than on Tuesday: >> I think we need more time than that. >> >> 2. I think the best approach is to cancel the emailcore >> session at 109 and schedule an interim meeting within the >> upcoming 4 weeks. I urge the chairs to seriously consider >> this, and to let me, the Secretariat, and the working group >> know quickly. >> >> Barry >> >> On Mon, Nov 16, 2020 at 2:17 PM John C Klensin >> wrote: >> >>> Barry and Murray, >>> >>> About 12 hours ago (much later than it should have been), I >>> posted a note to the emailcore list questioning the >>> appropriateness of holding a formal WG meeting given that >>> none of the topics on the agenda had received any mailing >>> list discussion since the WG was chartered. >>> >>> That message has gotten no response from either of the >>> co-chairs. Instead, there have been several postings of >>> questions and issues to be resolved from Alexey. >>> >>> Having no discussion on the mailing list and requests for >>> specific discussion in well under 24 hours before a WG >>> meeting during IETF is inconsistent with many (or all) of >>> our principles about having materials available so that >>> people can consider them well before a WG meeting and >>> preferably before IETF starts. I have seen nothing from the >>> IESG (or even in SHMOO discussions) that would change those >>> principles for an all-virtual meeting. >>> >>> So I am requesting that the EMAILCORE meeting scheduled for >>> tomorrow's "Session II" slot be either cancelled or (at >>> least) postponed until the end of the week with strict >>> instructions from you about when new (to the mailing list) >>> topics can be introduced. I note that there is no evidence >>> that the items listed on the agenda could not be settled on >>> the mailing list (because that has not been tried) so there >>> is a reasonable hypothesis that canceling tomorrow's meeting >>> will delay the WG's schedule. It might even get people's >>> attention and speed things up. I also note that there is >>> precedent for canceling a WG meeting during an IETF this >>> close, or closer, to the meeting time. >>> >>> I have a low level of expectation that the request will be >>> granted. There will clearly be no appeal from whatever you >>> decide (or avoid deciding) to the full IESG because, by the >>> time it could be considered, or even posted, it would be >>> moot. However, I do want it on the record that I have >>> identified a procedural problem and that I have asked. >>> >>> obnoxiously yours, >>> john >>> From nobody Mon Nov 16 16:30:01 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 A88A53A1762; Mon, 16 Nov 2020 16:29:59 -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, HTML_MESSAGE=0.001, 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 KmYPfMgaz0kH; Mon, 16 Nov 2020 16:29:58 -0800 (PST) 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 485C23A175B; Mon, 16 Nov 2020 16:29:58 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0AH0XQvp012292 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 16 Nov 2020 16:33:26 -0800 To: John C Klensin , Seth Blank , emailcore@ietf.org Cc: emailcore-chairs@ietf.org, ART ADs , Barry Leiba References: Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Mon, 16 Nov 2020 16:29:48 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E789DD47A6CAEF47ADAA934F" Content-Language: en-US Archived-At: Subject: Re: [Emailcore] Obnoxious, 11th hour, appeal of the decision to hold an emailcore meeting 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, 17 Nov 2020 00:30:00 -0000 This is a multi-part message in MIME format. --------------E789DD47A6CAEF47ADAA934F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/16/2020 4:17 PM, John C Klensin wrote: > Again, consider this an appeal as the meeting schedule (and > preparation) are procedurally irregular. No matter how much you > would like to leave the decision to the co-chairs, this is an > appeal and the buck stops with you. I'm going to second that request.  The real-time meetings are for dealing with issues that have been raised and need discussion. The view that Seth expresses, that this might generate wg energy, does not seem reasonable to me. The attempt, here, is to compensate for the working group's having done little in the venue that is supposed to be primary. That's not going to get fixed with a quick real-time session, especially when all or nearly all of the participants are likely to be attending in the middle of their night. /d > --On Monday, November 16, 2020 14:46 -0800 Seth Blank > wrote: > >> Hi John and Barry, >> >> The Chairs wish to hold today's session at 109. We believe it >> will be productive in accelerating on-list conversations, >> assuming a critical mass of participants actually in >> attendance. -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------E789DD47A6CAEF47ADAA934F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/16/2020 4:17 PM, John C Klensin wrote:
Again, consider this an appeal as the meeting schedule (and
preparation) are procedurally irregular.  No matter how much you
would like to leave the decision to the co-chairs, this is an
appeal and the buck stops with you.

I'm going to second that request.  The real-time meetings are for dealing with issues that have been raised and need discussion. 

The view that Seth expresses, that this might generate wg energy, does not seem reasonable to me. 

The attempt, here, is to compensate for the working group's having done little in the venue that is supposed to be primary.  That's not going to get fixed with a quick real-time session, especially when all or nearly all of the participants are likely to be attending in the middle of their night.

/d


--On Monday, November 16, 2020 14:46 -0800 Seth Blank
<seth@valimail.com> wrote:


Hi John and Barry,

The Chairs wish to hold today's session at 109. We believe it
will be productive in accelerating on-list conversations,
assuming a critical mass of participants actually in
attendance.


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------E789DD47A6CAEF47ADAA934F-- From nobody Mon Nov 16 17:00:18 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 C6EAF3A17B7; Mon, 16 Nov 2020 17:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-p4Hx_xfrhK; Mon, 16 Nov 2020 17:00:14 -0800 (PST) Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) (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 EAFD43A19D6; Mon, 16 Nov 2020 16:59:36 -0800 (PST) Received: by mail-vk1-f172.google.com with SMTP id b190so4172929vka.0; Mon, 16 Nov 2020 16:59:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xS1uMPObyEuPtD96qvyeZit4DonZYExhWecMwHBZm24=; b=nomGrdAOqDmqwLJtKCJFqp2JsH3Q1ZC+D+J4e8U5KCqLetdbs1YpiHCYnq6Q+vMKag lpppM9dAo/n+su9x71Qp12TBVfhQj4x3N3tVCUBvjkFSX/thpl/vXkNsVwfU1w1nYW+f JznEjGhaednG1U5Xf0nw01aXzT7S3ogBnmmbacz//tF8UI5fORzIP3cbJJ2eJXXQlfzT scMj7HCHzzsWE8wsXfnRb/wc8a0L7rpFQXf/1WQyynS/c2bR3BvVOrCUmQFvrnCbP2tT npaemwnI0JFgCo09zlt0jHKTnHbQrEjfRDOxV+L3r71o56eXVN3sIT8XT+kcWK/j0ewL CwwQ== X-Gm-Message-State: AOAM531iceeaRfXb1aV28hWuItnCzxRAJzW6RyyxwGwvPFDuSmYN2wAR YskOfM6OFPQUf23s78FS668NZkw7f17LrXZy7KyCViG6Y60= X-Google-Smtp-Source: ABdhPJwGwIycGOCR4o0s2b0IeK+XAFT2gvnaR1KDUmh9jBzrLV8jSiBw9WOVeGnVJ1v6hMSomyLJXxvDePC2GbdCz/Y= X-Received: by 2002:a1f:9ed4:: with SMTP id h203mr9733380vke.1.1605574775704; Mon, 16 Nov 2020 16:59:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Mon, 16 Nov 2020 19:59:24 -0500 Message-ID: To: dcrocker@bbiw.net Cc: ART ADs , John C Klensin , Seth Blank , emailcore@ietf.org, emailcore-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000002a96f405b44302de" Archived-At: Subject: Re: [Emailcore] Obnoxious, 11th hour, appeal of the decision to hold an emailcore meeting 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, 17 Nov 2020 01:00:17 -0000 --0000000000002a96f405b44302de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I understand what both of you are saying, so let me be clearer: 1. Given how little time there is before the session (6.5 hours or so, as I type this), I think it=E2=80=99s likely that people planning to attend woul= d not see the cancellation between the time we got it announced and the session time, and that itself would be disrespectful of people=E2=80=99s time and p= lanning. 2. While it=E2=80=99s ideal that meeting sessions be spent furthering maili= ng list discussion, I do think that a meeting can be productive under the parameters we currently have. 3. I=E2=80=99ve discussed this with Seth and accept his analysis that the m= eeting session can be productive. >From an appeal standpoint, I support the chairs=E2=80=99 decision to contin= ue with the session as scheduled. And for clarity on John=E2=80=99s subject line, I don=E2=80=99t consider ei= ther the appeal or John to be obnoxious. :-) Nevertheless, it might well have been different had this been brought up a week ago or two, as, =E2=80=9CLet=E2= =80=99s cancel the 109 session if we don=E2=80=99t have significant discussion on he list in t= he next (n) days.=E2=80=9D Let=E2=80=99s please try to have productive discussion here, and do our bes= t to continue that discussion on the list afterward. Barry On Mon, Nov 16, 2020 at 7:30 PM Dave Crocker wrote: > On 11/16/2020 4:17 PM, John C Klensin wrote: > > Again, consider this an appeal as the meeting schedule (and > preparation) are procedurally irregular. No matter how much you > would like to leave the decision to the co-chairs, this is an > appeal and the buck stops with you. > > I'm going to second that request. The real-time meetings are for dealing > with issues that have been raised and need discussion. > > The view that Seth expresses, that this might generate wg energy, does no= t > seem reasonable to me. > > The attempt, here, is to compensate for the working group's having done > little in the venue that is supposed to be primary. That's not going to > get fixed with a quick real-time session, especially when all or nearly a= ll > of the participants are likely to be attending in the middle of their nig= ht. > > /d > > > --On Monday, November 16, 2020 14:46 -0800 Seth Blank = wrote: > > > Hi John and Barry, > > The Chairs wish to hold today's session at 109. We believe it > will be productive in accelerating on-list conversations, > assuming a critical mass of participants actually in > attendance. > > > -- > Dave Crocker > Brandenburg InternetWorkingbbiw.net > > --0000000000002a96f405b44302de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I understand what both of you are saying, so let me be cl= earer:

1. Given how litt= le time there is before the session (6.5 hours or so, as I type this), I th= ink it=E2=80=99s likely that people planning to attend would not see the ca= ncellation between the time we got it announced and the session time, and t= hat itself would be disrespectful of people=E2=80=99s time and planning.

2. While it=E2=80=99s idea= l that meeting sessions be spent furthering mailing list discussion, I do t= hink that a meeting can be productive under the parameters we currently hav= e.

3. I=E2=80=99ve discu= ssed this with Seth and accept his analysis that the meeting session can be= productive.

From an app= eal standpoint, I support the chairs=E2=80=99 decision to continue with the= session as scheduled.

A= nd for clarity on John=E2=80=99s subject line, I don=E2=80=99t consider eit= her the appeal or John to be obnoxious. =C2=A0:-) =C2=A0 Nevertheless, it m= ight well have been different had this been brought up a week ago or two, a= s, =E2=80=9CLet=E2=80=99s cancel the 109 session if we don=E2=80=99t have s= ignificant discussion on he list in the next (n) days.=E2=80=9D

Let=E2=80=99s please try to have pr= oductive discussion here, and do our best to continue that discussion on th= e list afterward.

Barry<= /div>

On Mon, Nov 16, 2020 at 7:30 PM Dave Crocker <dhc@dcrocker.net> wrote:
=20 =20 =20
On 11/16/2020 4:17 PM, John C Klensin wrote:
Again, consider this an appeal as the meeting schedule (and
preparation) are procedurally irregular.  No matter how much you
would like to leave the decision to the co-chairs, this is an
appeal and the buck stops with you.

I'm going to second that request.=C2=A0 The real-time meetings a= re for dealing with issues that have been raised and need discussion.=C2=A0 =

The view that Seth expresses, that this might generate wg energy, does not seem reasonable to me.=C2=A0

The attempt, here, is to compensate for the working group's having done little in the venue that is supposed to be primary.=C2=A0 That's not going to get fixed with a quick real-time session, especially when all or nearly all of the participants are likely to be attending in the middle of their night.

/d


--On Monday, November 16, 2020 14:46 -0800 Seth Blank
<seth@valimail.co=
m> wrote:


Hi John and Barry,

The Chairs wish to hold today's session at 109. We believe it
will be productive in accelerating on-list conversations,
assuming a critical mass of participants actually in
attendance.


--=20
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--0000000000002a96f405b44302de-- From nobody Mon Nov 16 18:03:57 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 0B2443A187C; Mon, 16 Nov 2020 18:03:55 -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 YD44ubYKM81c; Mon, 16 Nov 2020 18:03:53 -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 986683A187B; Mon, 16 Nov 2020 18:03:53 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1keqLR-0005bv-Vn; Mon, 16 Nov 2020 21:03:45 -0500 Date: Mon, 16 Nov 2020 21:03:39 -0500 From: John C Klensin To: Barry Leiba , dcrocker@bbiw.net cc: ART ADs , Seth Blank , emailcore@ietf.org, emailcore-chairs@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] Obnoxious, 11th hour, appeal of the decision to hold an emailcore meeting 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, 17 Nov 2020 02:03:55 -0000 --On Monday, November 16, 2020 19:59 -0500 Barry Leiba wrote: > I understand what both of you are saying, so let me be clearer: > > 1. Given how little time there is before the session (6.5 > hours or so, as I type this), I think it's likely that > people planning to attend would not see the cancellation > between the time we got it announced and the session time, and > that itself would be disrespectful of people's time and > planning. That is fair although I note that I made the request to cancel more than 12 hours before the meeting was to start, at which time it would have been more reasonable to call it off. > 2. While it's ideal that meeting sessions be spent > furthering mailing list discussion, I do think that a meeting > can be productive under the parameters we currently have. > > 3. I've discussed this with Seth and accept his analysis > that the meeting session can be productive. > > From an appeal standpoint, I support the chairs' decision to > continue with the session as scheduled. Ok. See below. > And for clarity on John's subject line, I don't consider > either the appeal or John to be obnoxious. :-) > Nevertheless, it might well have been different had this been > brought up a week ago or two, as, "Let's cancel the 109 > session if we don't have significant discussion on he list > in the next (n) days." Yes. Probably the issue should have been raised a week or two ago. And, had the chairs posted a revised agenda that focused more on figuring out how to move forward more constructively than pretending everything was normal, I probably would not be complaining. And, unless there has been a change that I didn't notice, all approvals for WG meetings are contingent on the WG being ready to meet and you could have stepped in at any time before today's rash of postings, or certainly after I posed the "why are we meeting" question at 07:01 UTC today and said "no on-list discussion, no meeting" without waiting for someone to formally ask. I have to agree with Dave that this is not a good way to get the WG moving. > Let's please try to have productive discussion here, and do > our best to continue that discussion on the list afterward. I will do my best. However, I have not had, would not have had even without this discussion of cancellation, and am almost certain to not have between now and the meeting, time to review and think about the about the agenda topics minimally discussed today or review what 5321bis now says and review my notes about why it says that before the meeting starts and hence am unlikely to have much useful to contribute. thanks, john From nobody Mon Nov 16 23:28:46 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 41DA53A113B for ; Mon, 16 Nov 2020 23:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNX90qjNv_YF for ; Mon, 16 Nov 2020 23:28:42 -0800 (PST) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16193A12CF for ; Mon, 16 Nov 2020 23:28:24 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RS3HYGAYO0004MRH@mauve.mrochek.com> for emailcore@ietf.org; Mon, 16 Nov 2020 23:23:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1605597801; bh=H+xk31C7o+d9UkNKzMI2Vf/UTPKZhYrtEYsZkOTwb64=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=c76IGLSN4AJnOmiaQvz/Vnn4k6++Fy0lyTDV+mm7ebpfYtSkVFoh532a55JgMWk1S mt7i49N64D6i48Pe2Bt3RYdU8c4meJe52v0y+DsLA00nwwP3r/aZ4Gw8yyZA6kjtbA +hIAB0npa3zq5TSSueJXpiTQYCPVdtbL+DjL1t88= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RRN7E11EGG005PTU@mauve.mrochek.com>; Mon, 16 Nov 2020 23:23:18 -0800 (PST) Cc: emailcore@ietf.org Message-id: <01RS3HYELTKW005PTU@mauve.mrochek.com> Date: Mon, 16 Nov 2020 22:51:05 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 16 Nov 2020 17:41:32 +0000" <35ab0a5a-2758-4c64-9f66-3a5f3d8d7a26@isode.com> References: <35ab0a5a-2758-4c64-9f66-3a5f3d8d7a26@isode.com> To: Alexey Melnikov Archived-At: Subject: Re: [Emailcore] Ticket #27: Erratum 4315: IPv6 ABNF needs updating to align with RFC 5952 and RFC 3986 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, 17 Nov 2020 07:28:44 -0000 > Dear collegues, > This ticket took me a bit of time to investigate, so it might be a bit > tricky (not that anything in this WG is easy ;-)). Basically erratum > 4315 requested upgrade to IPv6 address ABNF in the document to match > [RFC 3986]  (URI spec) and [RFC 5952] (A Recommendation for IPv6 Address > Text Representation). There was a specific proposal in the erratum, but > I think John's solution (which is currently in the draft) is better: > IPv6-addr = 6( h16 ":" ) ls32 >     / "::" 5( h16 ":" ) ls32 >     / [ h16 ] "::" 4( h16 ":" ) ls32 >     / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 >     / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 >     / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 >     / [ *4( h16 ":" ) h16 ] "::" ls32 >     / [ *5( h16 ":" ) h16 ] "::" h16 >     / [ *6( h16 ":" ) h16 ] "::" >         ; This definition is consistent with the one for >         ; URIs [40]. > ls32 = ( h16 ":" h16 ) / IPv4address >         ; least-significant 32 bits of address > h16 = 1*4HEXDIG >         ; 16 bits of address represented in hexadecimal > Basically IPv6-addr looks very similar to what is in RFC 3986, so it is > easy to verify correctness. > However, RFC 3986 doesn't follow advice from RFC 5952, as it predates > it. Some minor issues I've noticed with the above ABNF: > RFC 5952, 4.1. Handling Leading Zeros in a 16-Bit Field >     Leading zeros MUST be suppressed. For example, 2001:0db8::0001 is >     not acceptable and must be represented as 2001:db8::1. A single 16- >     bit 0000 field MUST be represented as 0. > 4.3. Lowercase >     The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address >     MUST be represented in lowercase. > Both of these would probably affect h16, which can be tweaked to make it > clear that leading "0" are prohibited and only lowercase is to be used. > (HEXDIG allows uppercase hex at the moment). This made me wonder though: > are there any backward compatibility issues with changing this (e.g. to > disallow uppercase hex)? Should we have 2 grammars, "strict" one for > what should be generated and a more relaxed one for what should be accepted? Perhaps a better question is wheter or not you even have a way of measuring the extent to which there are going to be backwards compatibility issues. Implementations have been written, and to the extent that IPv6 literals are even used, the supported forwats are what they are. It may well be there are uses out there that would break. Or not. It's really impossible to tell. Now, it would be one thing if this was a change to allow for more flexibility in address formats. I could see a case for that. But it's the exact opposite. And yes, we have a clever mechanism of imposing syntax restrictions on addresses. But use of this mechanism is not with it's own costs. So why make the change? The case for imposing these restriction is made in section 3 of RFC 5952. I'm not going to bother to reproduce all of it here, but it basically boils down to listing the advantages of having a canonical form for IPv6 addresses and how it helps for searching, auditing, and so on. Now let's please remember that we're talking about IPv6 literals in the context of email addresses. In regards to caoonical forms in this context, let me simply say ned.freed@mrochek.com ned.freed @ mrochek.com Ned.Freed@mrochek.com NED.FREED@MROCHEK.COM All of these are legal addresses. Are they equivelant? The first two are, but implementations are specifically allowed to treat local-parts as case-senisitive, or not. How about "ned.freed"@mrochek.com "ned . freed"@mrochek.com Please note I haven't even gotten to obsolete forms, or EAI addresses. Or subaddreses. Or multiple aliases. When it comes to canonical forms for email addresses, the horse has left the barn and the barn has been torn down and replaced with a parking lot. Given this context, it would be a serious understatement To say I see no value in worrying about canonical forms for IPv6 in domain literals. tl;dr. The proposed change provides nothing of value and may have some cost. It should be rejected. Ned From nobody Mon Nov 16 23:35:49 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 8B8C13A115A for ; Mon, 16 Nov 2020 23:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdV5sQ9sezvt for ; Mon, 16 Nov 2020 23:35:46 -0800 (PST) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47FB83A1152 for ; Mon, 16 Nov 2020 23:35:46 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RS3I8JT27K00BG75@mauve.mrochek.com> for emailcore@ietf.org; Mon, 16 Nov 2020 23:30:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1605598242; bh=agX4Xv1DpBPM+STtMtJVXiCReFVpiNg6rwPYGY1jfJg=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=k081z4h4qtatg5xuSmWi9fUKSg2fWiIGg+gyznd7NjF5KtD0HAmhXc4uAe5qvbXnC r9i4oG0gPnUeBlR4rn9YIzTTpgaiZ/X+CWae62DhF9VmlgD7KOmUe9tAitv+DyuMzr RUAMlZROFwGn+HZAUTB5O4IHikJ/oyjNd6kqDCzE= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RRN7E11EGG005PTU@mauve.mrochek.com>; Mon, 16 Nov 2020 23:30:39 -0800 (PST) Cc: emailcore@ietf.org Message-id: <01RS3I8I4F10005PTU@mauve.mrochek.com> Date: Mon, 16 Nov 2020 23:24:34 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 16 Nov 2020 17:20:06 +0000" <0cc7e71d-e12c-a990-d628-749699e7a495@isode.com> References: <0cc7e71d-e12c-a990-d628-749699e7a495@isode.com> To: Alexey Melnikov Archived-At: Subject: Re: [Emailcore] Ticket #9: G.7.3. Resolvable FQDN in SMTP and private domain names 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, 17 Nov 2020 07:35:48 -0000 > Dear WG participants, > Another rfc5321bis issue for your consideration: > In Section 2.3.5 ("Domain Names"): >     Only resolvable, fully-qualified domain names (FQDNs) are permitted > when domain names are used in SMTP. > John's Note (as the editor): does "in the public DNS" or equivalent need > to be added to "resolvable"??? > My personal opinion: I don't think we should require "in the public > DNS", as as SMTP works just fine with split horizon or private DNS servers. Agreed. While it can be convenient to perform DNS validity checks of the domains in addresses in some contexts - or even more limited stuff like checking for valid TLDs - it should not be an SMTP requirement. Requirements like these lead to implementations imposing restrictions that are difficult to remove - and there are cases where you want to remove them. > In order to stimulate discussion of this topic I would like to propose > the following strawman: > "Resolvable" can mislead readers to think that they need to attempt > resolve all domain names when received. I don't think this is intended. > I would like to propose to drop "resolvable" from the sentence quoted > above. Possibly discuss "private domain names" in the Applicability > Statement draft. Works for me. Ned From nobody Tue Nov 17 00:36:49 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 89F213A0994 for ; Tue, 17 Nov 2020 00:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mXwrXLNj5SK for ; Tue, 17 Nov 2020 00:36:41 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772A53A0985 for ; Tue, 17 Nov 2020 00:36:41 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RS3KD1LL0W006F2P@mauve.mrochek.com> for emailcore@ietf.org; Tue, 17 Nov 2020 00:31:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1605601896; bh=e8ekjq8+SWRukiFulGLXKGgnVZ/w6ofqH9AYcc9hlBU=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=J4ysWXVAcsu1+66SVXnpUpFAIdfT0XAEh/BDfpT3OEM+h+oTyWwQxTDhP3m1odODS rOvV8lK0h69Dnx4QhbTkvQVuzg1FqxWIf1f4CrvPV7uNlXXzOvhB4E9sAKHlSr9Kic Em9XHqR/tbpDVSK+/5M7z0cK1+AgEG89rbhxayiw= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RRN7E11EGG005PTU@mauve.mrochek.com>; Tue, 17 Nov 2020 00:31:33 -0800 (PST) Cc: Alexey Melnikov , emailcore@ietf.org Message-id: <01RS3KCZXVQW005PTU@mauve.mrochek.com> Date: Mon, 16 Nov 2020 23:31:44 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 16 Nov 2020 09:04:01 -0800" References: <240e4ce1-d90b-285e-8878-d79c9cad70c2@isode.com> To: Dave Crocker Archived-At: Subject: Re: [Emailcore] Ticket #4: Exploders seem to be prohibited from adding List-* header fields 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, 17 Nov 2020 08:36:47 -0000 > On 11/16/2020 8:53 AM, Alexey Melnikov wrote: > > > > 3.9. Mailing Lists and Aliases > > ... > > > > NEW: > > > >     However, in this case, the message header section (RFC 5322 [11]) > > > >     MUST NOT be modified, except for adding header fields related to > > > >     mailing list processing (e.g. List-* [RFC4021][RFC8058]) and/or trace > > > >     header fields [rfc5322bis]; [...] > > > This document should remove all references to aliases and mailing > lists.  They are, quite simply, out of scope for basic email transfer, > which is what SMTP does. The problem is that aliases can and do operate at the MTA level without going through any sort of "delivery" processing. Pretty much every MTA in existence - including those that do what they consider to be pure relay with nothing they regard as MDA functionality at all - has the ability to do some form of RCPT TO address substitution. Or if not substitution, differing interpretations. I realize that the email architecture document makes a case for treating even the simple replacement of the RCPT TO value as an MDA thing. But we really are pretty far out in the rough in regards to what actual implementations do here. FWIW, I accept part of the blame for the current sorry state of affairs: The conflation of RCPT TO replacement with delivery goes back to the NOTARY documents, where we made a distinction between delivery, which includes RCPT TO replacement and not much else, and final delivery, which includes all the other stuff like adding Return-Path, success DSNs, and so on. I now think it was a mistake to call this delivery. And of course once you want to talk about aliases, you have to distinguish them from mailing lists. With all that implies. I don't have any good answers here. But I'm very uncomfortable with a solution that involves removing this material entirely. > Also  they have become complicated topics that take more than the > superficial treatment this specification can (or should) provide. > Aliases and Mailing Lists operate /after delivery/.  That is, after SMTP > has done its job.  They therefore operate at a layer above SMTP. Er, no. Aliases as defined in the NOTARY speficiation do not invoke all aspects of final delivery processing. And that's how they work in practice. > As a small example, the Must Not stricture is clearly wrong with respect > to modern handling of the From: field in some cases. > While there is demonstrated resistance to referencing RFC 5598, it's > still worth considering. FWIW< RFC 5598 actually isn't entirely clear on this either - it defines aliases, but doesn't make it clear the thing it's talking about is what's being done by, say, wholesale replacement of one domain with another in RCPT TO fields. Ned From nobody Tue Nov 17 01:17:37 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 735DF3A0BC4; Tue, 17 Nov 2020 01:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gheiRTMhTDMt; Tue, 17 Nov 2020 01:17:33 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F593A0BAD; Tue, 17 Nov 2020 01:17:33 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RS3LRRCOY80072EA@mauve.mrochek.com>; Tue, 17 Nov 2020 01:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1605604349; bh=5ZmewHNxF92Kp7SbFjF22qTUkQFyNlhXKLF+Cp56fso=; h=Date:From:Subject:In-reply-to:References:To:From; b=GSlWp2rcTS/AkUJpzB3Sp+wGUk/UXfLplL+O+tbLJVqogDio62mTtNSOmd9PsUKx3 inqC6GoXcQJPpyRMkuDceSkzhkKMB1sASIMVfGdpKRJ+v9pk9x2MswoUO1lySoOQBJ iOvEfGa2MstjXH9CeraXqNDd7Bn0h+MRkXT+ZlEA= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RRN7E11EGG005PTU@mauve.mrochek.com>; Tue, 17 Nov 2020 01:12:26 -0800 (PST) Message-id: <01RS3LRPSITQ005PTU@mauve.mrochek.com> Date: Tue, 17 Nov 2020 00:38:56 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 16 Nov 2020 21:03:39 -0500" References: To: emailcore@ietf.org, ART ADs Archived-At: Subject: Re: [Emailcore] Obnoxious, 11th hour, appeal of the decision to hold an emailcore meeting 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, 17 Nov 2020 09:17:35 -0000 And noe for a 13th hour comment. These days I spend a significant fraction of my time engaged in online meetings, mostly using Zoom, occasionally some more specialized thing. The number of times I have any sort of issue joining meetings and participting is incredibly tiny. It doesn't matter what brower, app, or device I choose to use. It just works. It works when I use my laptop, tablet, or my phone. It works when I use the builtin mic, a headset, or a speakerphone. it works when I dial in. It works when I use a builtin camera or an external one. Or switch between the two. It works when I join more than one meeting. It works when I join a meeting outside its scheduled time slot. And no doubt it's tolerating numerous other sins I'm unaware I'm commiting. To the extent there are problems, it's invariably either a network issue or a PIBKAC. I can count the number of serious software bugs I've encountered in the time of Covid-19 on the fingers of no hands. And then we come to the IETF. And Meetecho. I'm going to skip the obligatory, "How much hard work has gone into it and how wonderful all the support has been, etc." lines because I'm frankly not in the mood. Today's emailcore meeting was par for the course. Odd popup window on logging in - not clear what that was about. Some warning about audio issues that vanished before I could even read it. And then no ability to speak myself - and no indication of why. Reseting the audio - an option no other app seems to need - provided no satisfaction, unless pressing buttons that do nothing counts as satisfying. I was resigned to using chat to communicate until we reached a point in the meeting where nothing but high bandwidth would really do. In desperation I decided to try a different browser. I disonnected - I know better than to join the same meeting twice using different tools - and tried to reconnect. Except the meeting had run over time, and I wasn't allowed in. Folks, I'm not kidding when I say that the local folk music center consistently does a better job, and a less technically savvy group is hard for me to imagine. The IETF needs to get its shit together. It's embarassing. Ned From nobody Tue Nov 17 01:24:39 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 AD9603A0C94; Tue, 17 Nov 2020 01:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XW6iXSmULKkR; Tue, 17 Nov 2020 01:24:35 -0800 (PST) Received: from episteme.net (episteme.net [216.169.5.102]) by ietfa.amsl.com (Postfix) with ESMTP id EE4CE3A0BD9; Tue, 17 Nov 2020 01:24:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 37FCDC6AE39C; Tue, 17 Nov 2020 03:24:31 -0600 (CST) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96U34e-8LpJQ; Tue, 17 Nov 2020 03:24:29 -0600 (CST) Received: from [172.16.1.10] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 95BFCC6AE38D; Tue, 17 Nov 2020 03:24:29 -0600 (CST) From: "Pete Resnick" To: "Ned Freed" Cc: emailcore@ietf.org, "ART ADs" Date: Tue, 17 Nov 2020 03:24:28 -0600 X-Mailer: MailMate (1.13.2r5726) Message-ID: In-Reply-To: <01RS3LRPSITQ005PTU@mauve.mrochek.com> References: <01RS3LRPSITQ005PTU@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Emailcore] Obnoxious, 11th hour, appeal of the decision to hold an emailcore meeting 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, 17 Nov 2020 09:24:37 -0000 This should probably be sent to tools-discuss. I have had relatively good experiences with Meetecho A/V, but it is not as reliable as most tools out there and they really need to address this. Hitting the little "reset audio" button in the bottom right corner should simply not need to be done, ever. pr On 17 Nov 2020, at 2:38, Ned Freed wrote: > And noe for a 13th hour comment. > > These days I spend a significant fraction of my time engaged in online > meetings, mostly using Zoom, occasionally some more specialized thing. > The > number of times I have any sort of issue joining meetings and > participting is > incredibly tiny. > > It doesn't matter what brower, app, or device I choose to use. It just > works. > It works when I use my laptop, tablet, or my phone. It works when I > use the > builtin mic, a headset, or a speakerphone. it works when I dial in. > > It works when I use a builtin camera or an external one. Or switch > between the > two. > > It works when I join more than one meeting. It works when I join a > meeting > outside its scheduled time slot. And no doubt it's tolerating numerous > other > sins I'm unaware I'm commiting. > > To the extent there are problems, it's invariably either a network > issue or a > PIBKAC. I can count the number of serious software bugs I've > encountered in the > time of Covid-19 on the fingers of no hands. > > And then we come to the IETF. And Meetecho. I'm going to skip the > obligatory, > "How much hard work has gone into it and how wonderful all the support > has > been, etc." lines because I'm frankly not in the mood. > > Today's emailcore meeting was par for the course. Odd popup window on > logging > in - not clear what that was about. Some warning about audio issues > that > vanished before I could even read it. And then no ability to speak > myself - and > no indication of why. Reseting the audio - an option no other app > seems to need > - provided no satisfaction, unless pressing buttons that do nothing > counts as > satisfying. > > I was resigned to using chat to communicate until we reached a point > in the > meeting where nothing but high bandwidth would really do. In > desperation I > decided to try a different browser. I disonnected - I know better than > to join > the same meeting twice using different tools - and tried to reconnect. > Except > the meeting had run over time, and I wasn't allowed in. > > Folks, I'm not kidding when I say that the local folk music center > consistently > does a better job, and a less technically savvy group is hard for me > to > imagine. > > The IETF needs to get its shit together. It's embarassing. > > Ned -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Tue Nov 17 01:31:28 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 650503A0D79 for ; Tue, 17 Nov 2020 01:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 dXUEETeVmdUb for ; Tue, 17 Nov 2020 01:31:25 -0800 (PST) Received: from forward5-smtp.messagingengine.com (forward5-smtp.messagingengine.com [66.111.4.239]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E593A0D73 for ; Tue, 17 Nov 2020 01:31:25 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.nyi.internal (Postfix) with ESMTP id 62F811941B38; Tue, 17 Nov 2020 04:31:24 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute2.internal (MEProxy); Tue, 17 Nov 2020 04:31:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=XhD5f4 C80YVP1cUEErnKuN0RyKrjIIvLfHSHyU3BeTc=; b=BFyJkrV3PnHYlnjznJ41jG gb4vVOIWs4tfnKco6nxvAWt5Xrpd+QdXXkD5D2UycKQRgb1OSA9e6iqPtkQeTaY+ 5wnBbZM4W3MFoeRNPM1b3NxWNVRh4ZHi+WPB29eEhidA6Ir/nqumovwrejI2fc2O /Uk8lqBCNNTcCGIsam5ykcgovmzDW6JHcyJJRgNp8o7aRvpixEFfCza97q8bUpsH 8VcLuMk/IDkjMo34LfVhFeG27Awqvx2tWqiubkFl3EpAliGLZgPnZ6ynNF7Qd/z/ SSr84mrdbuUGukSl1O6K6FGkxWWaGPYbN12i66iSYmufHdqnqKZZBYrOyiL92riw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeffedgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrlhgvgigvhidrmhgvlhhnihhkohhvsehishhoug gvrdgtohhmqeenucggtffrrghtthgvrhhnpeetvedvgfejhfekueduiedvfedvgfelgeeg veegvdfhvdffvdegheffjeffheegfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpegrlhgvgigvhidrmhgvlhhnihhkohhvsehishhouggvrdgt ohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EA2F4660069; Tue, 17 Nov 2020 04:31:10 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <649b287b-81ca-48a5-af8b-dcbe6670fcc6@www.fastmail.com> In-Reply-To: <01RS3HYELTKW005PTU@mauve.mrochek.com> References: <35ab0a5a-2758-4c64-9f66-3a5f3d8d7a26@isode.com> <01RS3HYELTKW005PTU@mauve.mrochek.com> Date: Tue, 17 Nov 2020 09:31:02 +0000 From: "Alexey Melnikov" To: "Ned Freed" Cc: emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] =?utf-8?q?Ticket_=2327=3A_Erratum_4315=3A_IPv6_ABNF_?= =?utf-8?q?needs_updating_to_align_with_RFC_5952_and_RFC_3986?= 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, 17 Nov 2020 09:31:26 -0000 On Tue, Nov 17, 2020, at 6:51 AM, Ned Freed wrote: [snip] > Given this context, it would be a serious understatement To say I see no value > in worrying about canonical forms for IPv6 in domain literals. > > tl;dr. The proposed change provides nothing of value and may have some > cost. It should be rejected. Ok, fair point. I suggest we keep John's change to match RFC 3986 (URI spec), but don't do anything else to comply with RFC 5952. We can also add some text to the A/S draft saying that IPv6 syntax is not necessarily canonical, so it doesn't follow recommendations from RFC 5952. From nobody Tue Nov 17 03:51:37 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 2F9C93A1143 for ; Tue, 17 Nov 2020 03:51:35 -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, NICE_REPLY_A=-0.001, 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 (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_lkrFsZ_pLD for ; Tue, 17 Nov 2020 03:51:33 -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 4835C3A1136 for ; Tue, 17 Nov 2020 03:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1605613888; bh=tOlJ9nF364ey2k1WnDg5woI71+Fh9eK79eahGpry9ak=; l=502; h=To:References:From:Date:In-Reply-To; b=BBmgVM114mIRFKhaJZaZrHhGTGnBOQO4s8onOc2mmbyQu/LloDgM6d2SyiMWvsXRb ClA6UlzE0dfAypobajGBmvhtDWGRbOeTPOyeexRxnMW1PfMRIVob/m5sij49Wt+GYa LBHM8OZjAysMrF5Y6GSSmym+juWp3+4s48DkOqQZYyaEJGMdwHfE3I/WfpBX9 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 00000000005DC081.000000005FB3B940.00003067; Tue, 17 Nov 2020 12:51:28 +0100 To: emailcore@ietf.org References: From: Alessandro Vesely Message-ID: <9a964fb0-f29c-904b-1b2e-98d4eb71f36e@tana.it> Date: Tue, 17 Nov 2020 12:51:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #8: Need a registry of header fields that are Ok to add after submission 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, 17 Nov 2020 11:51:36 -0000 On 16/11/2020 18:10, Alexey Melnikov wrote: > > IANA is requested to create a new subregistry for email header fields that can > be added to a message header section by a “relay” and/or “delivery” SMTP > system. The new subregistry would show whether a header field can be added by a > “relay”, “delivery” system or both. How about fields set by the MUA and by the MSA? If we do that distinction, it would be worth to consider all MxAs, for x=U, S, T, D. Best Ale -- From nobody Tue Nov 17 03:52: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 778473A11ED for ; Tue, 17 Nov 2020 03:52:14 -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, NICE_REPLY_A=-0.001, 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 (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rx67PSHoNfyL for ; Tue, 17 Nov 2020 03:52:12 -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 30A633A1269 for ; Tue, 17 Nov 2020 03:52:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1605613925; bh=5OTWKCAvavB8CmqGoMdigN6+ujoNcMbIpCri2ka9EdQ=; l=1864; h=To:References:From:Date:In-Reply-To; b=Av/HW0kCOt7HJ60eMfvnQYgKI/krxICaJECkXZ60W6ssO+15X3SYbqi78yPocIpNO 4yOU88s1jaeExO4AyLNhYIUn2aDZYb+1V9AJCle+/vpdk+rqW0jSulJvwKrrS/lsOA Im3KBCvnSKSb1h9NI0CGY7CQCAiQnxov3tLYxRY8Ku+kfxX8S3ogKa446TzZg 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 00000000005DC081.000000005FB3B965.00003090; Tue, 17 Nov 2020 12:52:05 +0100 To: emailcore@ietf.org References: <240e4ce1-d90b-285e-8878-d79c9cad70c2@isode.com> From: Alessandro Vesely Message-ID: <0b6ea1c2-2c17-5060-b981-eae166ccc1fd@tana.it> Date: Tue, 17 Nov 2020 12:52:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <240e4ce1-d90b-285e-8878-d79c9cad70c2@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #4: Exploders seem to be prohibited from adding List-* header fields 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, 17 Nov 2020 11:52:18 -0000 On 16/11/2020 17:53, Alexey Melnikov wrote: > > I would like us to discuss the following ticket for rfc5321bis: > > 3.9. Mailing Lists and Aliases Can we change that title? It is itself misleading. I'd propose "Forwarding". IMHO, aliasing to internal users, such as Sales => Mike, Bob, is very different from aliasing to external addresses, such as is done for email address portability. >     [...] When a message is >     delivered or forwarded to each address of an expanded list form, the >     return address in the envelope ("MAIL FROM:") MUST be changed to be >     the address of a person or other entity who administers the list. >     However, in this case, the message header section (RFC 5322 [11]) >     MUST be left unchanged; in particular, the "From" field of the header >     section is unaffected. > > As was already pointed out on the mailing list, the text "the message header > section (RFC 5322 [11]) MUST be left unchanged" seems to prohibit addition of > List-* header fields. How about subject tags? > Strawman proposal how to address this issue: > > OLD: > >     However, in this case, the message header section (RFC 5322 [11]) >     MUST be left unchanged; in particular, the "From" field of the header > > NEW: > >     However, in this case, the message header section (RFC 5322 [11]) >     MUST NOT be modified, except for adding header fields related to >     mailing list processing (e.g. List-* [RFC4021][RFC8058]) and/or trace >     header fields [rfc5322bis]; [...] > > Please discuss if the proposed text is an improvement and whether it can be > further improved. I'd drop the MUST NOT altogether. The MAIL FROM discussion is pristine. Trying to limit what part of a message an MDA can change makes no sense. Best Ale -- From nobody Tue Nov 17 05:25:51 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 234FB3A12ED for ; Tue, 17 Nov 2020 05:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83Z38QzxCORs for ; Tue, 17 Nov 2020 05:25:48 -0800 (PST) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B77083A1302 for ; Tue, 17 Nov 2020 05:25:47 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RS3ULXGPR400BYU6@mauve.mrochek.com> for emailcore@ietf.org; Tue, 17 Nov 2020 05:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1605619505; bh=LajFZwwodSImPXv6Qj8sZtng67sKsyWdyjHwbztpa/Y=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=aiAfdDHLrdhGV9hocTZQDMSd4C1l2RbNB1qYR/HERBhHq+lr8dfmm3g1NlSypvWf2 yU2xpHhYgOj7MYqOI2TTPaBmyw4PR4vTbLjU/1Pb1N7anu4VhH4TSDh/qOVT0GxXEe LvnSOc4oFPcMu1BJwVyHWIPSsNILG0VeHtwSMBKk= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RRN7E11EGG005PTU@mauve.mrochek.com>; Tue, 17 Nov 2020 05:25:03 -0800 (PST) Cc: emailcore@ietf.org Message-id: <01RS3ULW3EE6005PTU@mauve.mrochek.com> Date: Tue, 17 Nov 2020 05:22:55 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 17 Nov 2020 12:51:28 +0100" <9a964fb0-f29c-904b-1b2e-98d4eb71f36e@tana.it> References: <9a964fb0-f29c-904b-1b2e-98d4eb71f36e@tana.it> To: Alessandro Vesely Archived-At: Subject: Re: [Emailcore] Ticket #8: Need a registry of header fields that are Ok to add after submission 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, 17 Nov 2020 13:25:49 -0000 > On 16/11/2020 18:10, Alexey Melnikov wrote: > > > > IANA is requested to create a new subregistry for email header fields that can > > be added to a message header section by a “relay” and/or “delivery” SMTP > > system. The new subregistry would show whether a header field can be added by a > > “relay”, “delivery” system or both. > How about fields set by the MUA and by the MSA? If we do that distinction, it > would be worth to consider all MxAs, for x=U, S, T, D. I'm not sure there's a clear distinction to be made between what an MUA does and what an MSA does - the responsibility split in some cases puts most of the MUA function in the MSA - but yes, I think it does make sense to include submission. If only to be able to say that submitted messages really shouldn't insert a return-path field... Ned > -- > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore From nobody Tue Nov 17 05:25:54 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 D2F453A12ED for ; Tue, 17 Nov 2020 05:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jHR-J8Rk1MO for ; Tue, 17 Nov 2020 05:25:48 -0800 (PST) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B4A3A1304 for ; Tue, 17 Nov 2020 05:25:46 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RS3UGIQF9S0051N5@mauve.mrochek.com> for emailcore@ietf.org; Tue, 17 Nov 2020 05:20:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1605619243; bh=8Yi2QmqcheiP5zNxmqDkdkwRT6wZyHaK6iE8rD6DeSc=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=iZfa0ZTMxATY5IxXHrz9mSbGU9BCT5imoDVPwONmu8OCBbq4WLTjTTqqVfisZ/PL7 dPMYZU+5lkSiS63KbQ4k5d8WjCkabtaWpkGoQdqc0YuEjb/PvZo8QhgPYEAtPRSH/a GVVkecYK0niity13S+S1tZgaIRKXcP1ChObFWeRk= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RRN7E11EGG005PTU@mauve.mrochek.com>; Tue, 17 Nov 2020 05:20:42 -0800 (PST) Cc: emailcore@ietf.org Message-id: <01RS3UGHA8B8005PTU@mauve.mrochek.com> Date: Tue, 17 Nov 2020 05:13:06 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 17 Nov 2020 12:52:05 +0100" <0b6ea1c2-2c17-5060-b981-eae166ccc1fd@tana.it> References: <240e4ce1-d90b-285e-8878-d79c9cad70c2@isode.com> <0b6ea1c2-2c17-5060-b981-eae166ccc1fd@tana.it> To: Alessandro Vesely Archived-At: Subject: Re: [Emailcore] Ticket #4: Exploders seem to be prohibited from adding List-* header fields 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, 17 Nov 2020 13:25:50 -0000 > On 16/11/2020 17:53, Alexey Melnikov wrote: > > > > I would like us to discuss the following ticket for rfc5321bis: > > > > 3.9. Mailing Lists and Aliases > Can we change that title? It is itself misleading. I'd propose "Forwarding". The terms agree with those in the email architecture document, and the NOTARY documents before that. What would be misleading is to switch to different terms after ~25 years. > IMHO, aliasing to internal users, such as Sales => Mike, Bob, is very different > from aliasing to external addresses, such as is done for email address portability. In what way is it different? What semantic changes are involved? Please be very specific. > >     [...] When a message is > >     delivered or forwarded to each address of an expanded list form, the > >     return address in the envelope ("MAIL FROM:") MUST be changed to be > >     the address of a person or other entity who administers the list. > >     However, in this case, the message header section (RFC 5322 [11]) > >     MUST be left unchanged; in particular, the "From" field of the header > >     section is unaffected. > > > > As was already pointed out on the mailing list, the text "the message header > > section (RFC 5322 [11]) MUST be left unchanged" seems to prohibit addition of > > List-* header fields. > How about subject tags? Nobody is saying that the present text is acceptable. It isn't. > > Strawman proposal how to address this issue: > > > > OLD: > > > >     However, in this case, the message header section (RFC 5322 [11]) > >     MUST be left unchanged; in particular, the "From" field of the header > > > > NEW: > > > >     However, in this case, the message header section (RFC 5322 [11]) > >     MUST NOT be modified, except for adding header fields related to > >     mailing list processing (e.g. List-* [RFC4021][RFC8058]) and/or trace > >     header fields [rfc5322bis]; [...] > > > > Please discuss if the proposed text is an improvement and whether it can be > > further improved. > I'd drop the MUST NOT altogether. The MAIL FROM discussion is pristine. > Trying to limit what part of a message an MDA can change makes no sense. In the list case, yes, I agree. The alias case is mor subtle, and I for one think we have a problem with how we've defined it that goes beyond this txxt. Ned From nobody Tue Nov 17 05:33:05 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 E0E6B3A12ED for ; Tue, 17 Nov 2020 05:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEzGzGqxCHXJ for ; Tue, 17 Nov 2020 05:33:03 -0800 (PST) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2B823A12B8 for ; Tue, 17 Nov 2020 05:33:02 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RS3UPIO6UO00BYU6@mauve.mrochek.com> for emailcore@ietf.org; Tue, 17 Nov 2020 05:27:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1605619679; bh=kmekL0BBtoV6J6rIHFfBtcU2N2YfKsVXizIxBYWJYUc=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=h6NKl4QMF8PXrbvpsdfEI+bfW6MXvjm5kLN+Klc7uM3yPpyMJJOAP4TAi2w2cly+7 1FISjAtP8Q47Y0vCsuiE9pwkeCV/OwZChXrHsbOwAKkndUq+2bjcWzWv/DwYRv5/JS 3iW5eOottq9HwqKiBnhejrbpSbYPjf1+x6ch5eJ8= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RRN7E11EGG005PTU@mauve.mrochek.com>; Tue, 17 Nov 2020 05:27:56 -0800 (PST) Cc: Ned Freed , emailcore@ietf.org Message-id: <01RS3UPGOLZI005PTU@mauve.mrochek.com> Date: Tue, 17 Nov 2020 05:27:41 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 17 Nov 2020 09:31:02 +0000" <649b287b-81ca-48a5-af8b-dcbe6670fcc6@www.fastmail.com> References: <35ab0a5a-2758-4c64-9f66-3a5f3d8d7a26@isode.com> <01RS3HYELTKW005PTU@mauve.mrochek.com> <649b287b-81ca-48a5-af8b-dcbe6670fcc6@www.fastmail.com> To: Alexey Melnikov Archived-At: Subject: Re: [Emailcore] =?utf-8?q?Ticket_=2327=3A_Erratum_4315=3A_IPv6_ABNF_?= =?utf-8?q?needs_updating_to_align_with_RFC_5952_and_RFC_3986?= 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, 17 Nov 2020 13:33:04 -0000 > On Tue, Nov 17, 2020, at 6:51 AM, Ned Freed wrote: > [snip] > > Given this context, it would be a serious understatement To say I see no value > > in worrying about canonical forms for IPv6 in domain literals. > > > > tl;dr. The proposed change provides nothing of value and may have some > > cost. It should be rejected. > Ok, fair point. I suggest we keep John's change to match RFC 3986 (URI spec), > but don't do anything else to comply with RFC 5952. We can also add some text > to the A/S draft saying that IPv6 syntax is not necessarily canonical, so it > doesn't follow recommendations from RFC 5952. Works for me. Ned From nobody Tue Nov 17 07:28:26 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 01D973A1411; Tue, 17 Nov 2020 07:28:25 -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, 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 izCJ8SfDHi1U; Tue, 17 Nov 2020 07:28:24 -0800 (PST) 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 D227B3A1505; Tue, 17 Nov 2020 07:28:05 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0AHFVbeb016313 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 17 Nov 2020 07:31:38 -0800 To: Ned Freed , emailcore@ietf.org, ART ADs References: <01RS3LRPSITQ005PTU@mauve.mrochek.com> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <660d8af5-2b83-3507-00aa-a792eb9d2118@dcrocker.net> Date: Tue, 17 Nov 2020 07:27:59 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <01RS3LRPSITQ005PTU@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Emailcore] Obnoxious, 11th hour, appeal of the decision to hold an emailcore meeting 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, 17 Nov 2020 15:28:25 -0000 On 11/17/2020 12:38 AM, Ned Freed wrote: > Folks, I'm not kidding when I say that the local folk music center consistently > does a better job, and a less technically savvy group is hard for me to > imagine. > > The IETF needs to get its shit together. It's embarassing. The Meetecho folks are great and they tend to make good usability choices.  But they have never been a serious business. So it is not surprising that that industry has run right past them, especially with the current usage pressures, driving aggressive enhancement. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Nov 17 07:47:52 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 931AB3A144B for ; Tue, 17 Nov 2020 07:47:50 -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, 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 mcOhIdRVakdY for ; Tue, 17 Nov 2020 07:47:47 -0800 (PST) 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 ABFD93A1448 for ; Tue, 17 Nov 2020 07:47:47 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0AHFpKNW018355 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 17 Nov 2020 07:51:20 -0800 Reply-To: dcrocker@bbiw.net To: emailcore@ietf.org References: <35ab0a5a-2758-4c64-9f66-3a5f3d8d7a26@isode.com> <01RS3HYELTKW005PTU@mauve.mrochek.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <4bca2aeb-9c22-0c9a-512e-16f54ed12492@dcrocker.net> Date: Tue, 17 Nov 2020 07:47:41 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <01RS3HYELTKW005PTU@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #27: Erratum 4315: IPv6 ABNF needs updating to align with RFC 5952 and RFC 3986 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, 17 Nov 2020 15:47:51 -0000 On 11/16/2020 10:51 PM, Ned Freed wrote: > > tl;dr. The proposed change provides nothing of value and may have some > cost. It should be rejected. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Nov 17 08:57:21 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 507DA3A14D6 for ; Tue, 17 Nov 2020 08:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_B=1.502, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ngt1qJSmZ7C for ; Tue, 17 Nov 2020 08:57:12 -0800 (PST) Received: from leas1.unina.it (fmvip.unina.it [192.132.34.7]) (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 8153B3A1533 for ; Tue, 17 Nov 2020 08:57:11 -0800 (PST) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by leas1.unina.it with ESMTP id 0AHGv5Mm025629-0AHGv5Mo025629 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=CAFAIL); Tue, 17 Nov 2020 17:57:05 +0100 Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp1.unina.it (8.15.2/8.15.2/Debian-3) with ESMTPSA id 0AHGvAgm005040 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Nov 2020 17:57:12 +0100 From: Simon Pietro Romano Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: Date: Tue, 17 Nov 2020 17:57:02 +0100 Cc: emailcore@ietf.org, Simon Pietro Romano To: dhc@dcrocker.net X-Mailer: Apple Mail (2.3445.102.3) X-Virus-Scanned: clamav-milter 0.101.4 at smtp1 X-Virus-Status: Clean Authentication-Results: leas1.unina.it; spf=pass (unina.it: domain of spromano@unina.it designates 192.132.34.61 as permitted sender) smtp.mailfrom=spromano@unina.it Archived-At: Subject: Re: [Emailcore] Obnoxious, 11th hour, appeal of the decision to hold an emailcore meeting 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, 17 Nov 2020 16:57:20 -0000 Hello Dave, > The Meetecho folks are great and they tend to make good usability = choices. =20 Thanks for that.=20 > But they have never been a serious business.=20 Not quite sure what you mean by "serious", here. We pay our bills with = our work. Meetecho is all but a toy for us, and for our employees as = well. > So it is not surprising that that industry has run right past them, = especially with the current usage pressures, driving aggressive = enhancement. d/ Different people have different ideas as of who has run past whom, I = would say. Please don't make your personal thoughts raise up to the = level of universal judgements.=20 Undocumented statements like the one above might sound just like FUD = spreading, indeed. We do believe we are quite ahead of the pack, when it comes to = *standards-compliant* unified communication and collaboration.=20 Though, as I was saying, this is just personal thoughts :-) Cheers, Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli = Federico II Computer Engineering = Department=20 Phone: +39 081 7683823=20 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) = ) / = (_/ From nobody Tue Nov 17 09:22:51 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 597C43A155B for ; Tue, 17 Nov 2020 09:22:45 -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 x0C_Pyhy9v42 for ; Tue, 17 Nov 2020 09:22:39 -0800 (PST) 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 149AC3A158D for ; Tue, 17 Nov 2020 09:22:23 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0AHHPrjc029224 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 17 Nov 2020 09:25:53 -0800 Reply-To: dcrocker@bbiw.net To: emailcore@ietf.org References: <240e4ce1-d90b-285e-8878-d79c9cad70c2@isode.com> <01RS3KCZXVQW005PTU@mauve.mrochek.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 17 Nov 2020 09:22:14 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <01RS3KCZXVQW005PTU@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] Dropping Sections 3.7 and 3.9 ( was: Re: Ticket #4: Exploders seem to be ...) 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, 17 Nov 2020 17:22:51 -0000 Take a seat. This is going to take awhile... (I've added the Gatewaying section to the mix, since it, too, is trying to cover a complex topic that really is outside the scope of SMTP proper.) Discussion about Internet Mail architecture is typically muddled by inconsistent use of framework and terminology. It also suffers from the common malady of conflating software implementation with abstract network architecture. The purpose of RFC 5598 was to attempt to get common framework and language provided about the network architecture of the service. SMTP, itself, is a single-hop transfer protocol. Its specification is elaborated for multiple SMTP hops, to cover submission-to-delivery normative language, to formulate an end-to-end service within a coherent SMTP environment. What its specification should not and cannot do is cover material that is outside the scope of that homogeneous service, especially as such material has become far more complex than the SMTP specification can do justice to. That RFC 821 introduced language about aliases and mailing lists was reasonable, at that time, but somewhere over the decades, the material became grossly inadequate and this cannot be reasonably be fixed with the SMTP spec, proper. Worse, having any meaningful language about these topic in this specification gives the impression that the topics have been covered; whereas readers need to instead find more extensive material. A specification like SMTP gets a lot simpler when ways are found to divide and conquer, by carving complexities that are not essential to the core functions. A basic test for this is to ask a) will the core service's specification suffer by the removal, and b) will losing the text in the document adversely affect the operational service? For gatewaying, aliasing, and mailing lists, I believe both answers are no. They are important topics, of course, but they are not important to SMTP itself. To the extent that there is a strong case that the answer to the second question is yes, then what is needed is a separate document, not the -- by today's perspective -- half-hearted coverage that is possible within the main SMTP specification. These are specialty topics and they need special focus. As far as adding gatewaying to the recommendation for removal... By definition, gatewaying has to do with circumstances outside of the homogeneous SMTP environment. As such, the SMTP document, itself, cannot dictate pretty much of anything about it. Worse is that gatewaying tends more towards heuristics, rather than simple, strict, pervasive rules, by virtue of having to try to connect together two services that are, by definition, not the same, and usually are quite substantially different. Sometimes they are quite close, such as CSNET had between dial-up and SMTP, but that was because the dial-up side was designed to be compatible. But mostly, gatewaying tries to connect two environments that have independent histories and therefore distinctly different sets of design and semantics decisions. So while gatewaying is an extremely important topic, it's not one that the SMTP document, itself, can or should cover. inline... >> This document should remove all references to aliases and mailing >> lists. They are, quite simply, out of scope for basic email >> transfer, which is what SMTP does. > > The problem is that aliases can and do operate at the MTA level > without going through any sort of "delivery" processing. I understand the implementation basis for that view, of course, but the hangup is on the definition of delivery. A simplistic, operational test is whether the message got to the address that was specified and did not get rejected. In terms of RFC 5598, the definition of the term 'delivery' now seems to me weak and well-hidden but not useless, even for the current discussion: 4.3.3. Mail Delivery Agent (MDA) A transfer of responsibility from the MHS to a Recipient's environment (mailbox) is called "delivery". In spite of being implemented down in typical MTA software, the reality of an aliasing mechanism is that the RCPTO transformation is an action under control of the designated recipient, not the author, nor the basic handling service. However briefly, control passes to the recipient's environment, before the message is -- in abstract terms -- re-posted to its alternative recipient(s). Could aliasing be implemented as a streamlined mailing list service? Yes. That is isn't is for efficiency and implementation simplicity rather than architectural necessity. > I realize that the email architecture document makes a case for > treating even the simple replacement of the RCPT TO value as an MDA > thing. But we really are pretty far out in the rough in regards to > what actual implementations do here. But not in regards to the question of where the responsibility for the action lies. It lies with the original addressee, not the author and, really, not the transfer service. > And of course once you want to talk about aliases, you have to > distinguish them from mailing lists. With all that implies. Yup. And the distinction is useful because aliasing is so constrained and mailing lists are so not. However that does not mean they occupy different places in the email service architecture. One aspect of the lengthy process of developing RFC 5598 that I found personally quite educational was the focus on 'responsibility'. The most extreme demonstration of this was the view that emerged -- and needed some promoting to convince me -- that MSAs and MDAs have a MHS/User transition point /within/ them rather than having that responsibility transfer happen between architectural nodes. > I don't have any good answers here. But I'm very uncomfortable with a > solution that involves removing this material entirely. What happens to the SMTP service if these sections are removed? What would it take to remedy this, outside of the SMTP-proper specification? >> Also they have become complicated topics that take more than the >> superficial treatment this specification can (or should) provide. > >> Aliases and Mailing Lists operate /after delivery/. That is, after >> SMTP has done its job. They therefore operate at a layer above >> SMTP. > > Er, no. Aliases as defined in the NOTARY speficiation do not invoke > all aspects of final delivery processing. And that's how they work in > practice. > >> As a small example, the Must Not stricture is clearly wrong with >> respect to modern handling of the From: field in some cases. > >> While there is demonstrated resistance to referencing RFC 5598, >> it's still worth considering. > > FWIW< RFC 5598 actually isn't entirely clear on this either - it > defines aliases, but doesn't make it clear the thing it's talking > about is what's being done by, say, wholesale replacement of one > domain with another in RCPT TO fields. I'm not in love with the language in RFC 5598's Section 5.1, although for the current discussion some of it seems interesting (although significantly improveable): ...the message continues through the transfer service, for delivery to one or more alternate addresses. Although typically implemented as part of an MDA, this facility is a Recipient function. It resubmits the message, although all handling information except the envelope Recipient (rfc5321.RcptTo) address is retained. I'd have wished that the 'continues' language emphasized the semantic transition, that is only eventually declared by the 'resubmits'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Nov 17 14:35:07 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 920CB3A0E05 for ; Tue, 17 Nov 2020 14:35:05 -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, 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 PO5lpHPzzM5p for ; Tue, 17 Nov 2020 14:35:04 -0800 (PST) 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 7DC4A3A0E01 for ; Tue, 17 Nov 2020 14:35:04 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0AHMca7D002840 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 17 Nov 2020 14:38:36 -0800 Reply-To: dcrocker@bbiw.net To: Simon Pietro Romano Cc: emailcore@ietf.org References: From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 17 Nov 2020 14:34:57 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Obnoxious, 11th hour, appeal of the decision to hold an emailcore meeting 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, 17 Nov 2020 22:35:06 -0000 On 11/17/2020 8:57 AM, Simon Pietro Romano wrote: >> But they have never been a serious business. > > Not quite sure what you mean by "serious", here. We pay our bills with our work. Meetecho is all but a toy for us, and for our employees as well. Simon, A serious business does not use 'pay our bills' as a metric. It uses growth, market share, ROI, and the like. Given the scale of operation of your competitors and the number of years you've been in business, do you have 2 billion users? 100 million? In this market /that/ is a serious business. There is nothing inherently wrong with a 'boutique' business, except that it is operationally fragile. Note that my email was in response to the thoughtful concerns that Ned expressed. >> So it is not surprising that that industry has run right past them, especially with the current usage pressures, driving aggressive enhancement. d/ > > Different people have different ideas as of who has run past whom, I would say. Please don't make your personal thoughts raise up to the level of universal judgements. Why not? First, they are my professional thoughts and they are based on rather well-established and enitrely mundane criteria for assessing a business. > Undocumented statements like the one above might sound just like FUD spreading, indeed. > > We do believe we are quite ahead of the pack, when it comes to *standards-compliant* unified communication and collaboration. > Though, as I was saying, this is just personal thoughts :-) Over the years, companies that make their primary selling point that they are standards compliant usually do poorly because they have not figured out that customers focus on problems and solutions, not technology. It's not that the technology is irrelevant, but rather than it is merely secondary, in the service of functionality, usability, reliability, etc. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Nov 17 15:10:22 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 094233A0EE4 for ; Tue, 17 Nov 2020 15:10:20 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 euqHIbNFLj19 for ; Tue, 17 Nov 2020 15:10:18 -0800 (PST) Received: from leas1.unina.it (fmvip.unina.it [192.132.34.7]) (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 99EED3A100C for ; Tue, 17 Nov 2020 15:10:15 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by leas1.unina.it with ESMTP id 0AHNA8Tc001086-0AHNA8Te001086 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 18 Nov 2020 00:10:08 +0100 Received: from [192.168.1.246] ([2.237.150.174]) (authenticated bits=0) by smtp2.unina.it (8.15.2/8.15.2/Debian-3) with ESMTPSA id 0AHNAFA4027328 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 00:10:15 +0100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Simon Pietro Romano Mime-Version: 1.0 (1.0) Date: Wed, 18 Nov 2020 00:10:07 +0100 Message-Id: References: Cc: emailcore@ietf.org In-Reply-To: To: dcrocker@bbiw.net X-Mailer: iPhone Mail (18A8395) X-Virus-Scanned: clamav-milter 0.101.4 at smtp2 X-Virus-Status: Clean Authentication-Results: leas1.unina.it; spf=pass (unina.it: domain of spromano@unina.it designates 192.132.34.62 as permitted sender) smtp.mailfrom=spromano@unina.it Archived-At: Subject: Re: [Emailcore] Obnoxious, 11th hour, appeal of the decision to hold an emailcore meeting 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, 17 Nov 2020 23:10:20 -0000 Hello again Dave, your sharp comments just confirm my impression that you are confused as of w= hat our business is all about. I even think you don=E2=80=99t have a clear i= dea as of who should be considered as a competitor for our business cases. A= s to the trivially =E2=80=9Cquantitative=E2=80=9D argument about the number o= f users supported by the usual suspects you have in mind, I=E2=80=99ll just o= bserve that this is a double-edged one, especially when what you=E2=80=99re l= ooking for is (also) customization, integration with pre-existing components= and tailoring of features. Also, just don=E2=80=99t tell me that we are trading operational fragility i= n favor of the above, =E2=80=98cause this is simply not true. When I say you= should come out with informed statements I refer exactly to that. Again, it= is your respectful personal impression; though it is just a personal impres= sion. Finally, when I say we strive for standard solutions, I mean functiona= l, usable, realiable, standard solutions. Cheers, Simon Inviato da iPhone > Il giorno 17 nov 2020, alle ore 23:35, Dave Crocker ha s= critto: >=20 > =EF=BB=BFOn 11/17/2020 8:57 AM, Simon Pietro Romano wrote: >>> But they have never been a serious business. >> Not quite sure what you mean by "serious", here. We pay our bills with ou= r work. Meetecho is all but a toy for us, and for our employees as well. >=20 > Simon, >=20 > A serious business does not use 'pay our bills' as a metric. It uses grow= th, market share, ROI, and the like. Given the scale of operation of your c= ompetitors and the number of years you've been in business, do you have 2 bi= llion users? 100 million? In this market /that/ is a serious business. >=20 > There is nothing inherently wrong with a 'boutique' business, except that i= t is operationally fragile. Note that my email was in response to the thoug= htful concerns that Ned expressed. >=20 >=20 >>> So it is not surprising that that industry has run right past them, espe= cially with the current usage pressures, driving aggressive enhancement. d/ >> Different people have different ideas as of who has run past whom, I woul= d say. Please don't make your personal thoughts raise up to the level of uni= versal judgements. >=20 > Why not? First, they are my professional thoughts and they are based on r= ather well-established and enitrely mundane criteria for assessing a busines= s. >=20 >=20 >> Undocumented statements like the one above might sound just like FUD spre= ading, indeed. >> We do believe we are quite ahead of the pack, when it comes to *standards= -compliant* unified communication and collaboration. >> Though, as I was saying, this is just personal thoughts :-) >=20 > Over the years, companies that make their primary selling point that they a= re standards compliant usually do poorly because they have not figured out t= hat customers focus on problems and solutions, not technology. >=20 > It's not that the technology is irrelevant, but rather than it is merely s= econdary, in the service of functionality, usability, reliability, etc. >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From nobody Tue Nov 17 15:22:36 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 9C2273A101E for ; Tue, 17 Nov 2020 15:22:28 -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, 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 XDyReKqGfK59 for ; Tue, 17 Nov 2020 15:22:27 -0800 (PST) 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 344A93A102B for ; Tue, 17 Nov 2020 15:22:27 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0AHNPx8j009260 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 17 Nov 2020 15:26:00 -0800 Reply-To: dcrocker@bbiw.net To: Simon Pietro Romano Cc: emailcore@ietf.org References: From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 17 Nov 2020 15:22:21 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Obnoxious, 11th hour, appeal of the decision to hold an emailcore meeting 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, 17 Nov 2020 23:22:35 -0000 On 11/17/2020 3:10 PM, Simon Pietro Romano wrote: > Also, just don’t tell me that we are trading operational fragility in favor of the above, ‘cause this is simply not true. So none of the concerns Ned expressed are valid? Also, for reference, my perspective is in terms of the needs of the using organization, and less in terms of the providing one. It's fine that you are comfortable with your current operation. It is less fine for the IETF to be. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Nov 17 16:37:32 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 152A73A1121 for ; Tue, 17 Nov 2020 16:37:30 -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=n5gLBaC7; dkim=pass (2048-bit key) header.d=taugh.com header.b=MjEmJKFO 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 40zxiApUFvOc for ; Tue, 17 Nov 2020 16:37:28 -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 87BF23A1119 for ; Tue, 17 Nov 2020 16:37:28 -0800 (PST) Received: (qmail 6328 invoked from network); 18 Nov 2020 00:37:27 -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=18b6.5fb46cc7.k2011; bh=wglPqH2Wl871tNUi6AtH5u88S7OIS26+NjVIl1FyJP8=; b=n5gLBaC7egRMpmxqN+tqnbwQSysnm0NBJU3yNq7rSYHREHuw+A1Yi/Yx86mXTwE2Ioy3hLeROl13pmJpa5O+uLGQARQsKS3zEub0k46355yefXdPFHU81AZ6TrOEXVqaoBRV6etjDV1kjd50nE/BEttvPbT8xxwPs3HUe2jr+PCnM0ArG8LbL4sWXB+tBF3wXOSxoYAS6i96FYZ7CrwlmEKMRxrzoZ316BpU/WRnBD9I+ohY1RFUTSS+plzxgByGM/dPGWFaCvxpSzl9p3DggC0XtOj14xbFyvd9WSKd1dFVaZ3rkKHrRx/SAepD8hiy57Gg3+qj5488Z94KgBzuZg== 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=18b6.5fb46cc7.k2011; bh=wglPqH2Wl871tNUi6AtH5u88S7OIS26+NjVIl1FyJP8=; b=MjEmJKFO6yo57e70jKc/OKx3VeRvV7WODjmWa5lhVnpc+QgmoQs/PlGQhfqqi/Uaa38SMdDg4FA54xTF6WVvHm7KIlxpwA4iRAAabZZA2RZRl3rqGKWD4GNOZAxF4c10qdWEHjy9ZYsJeMsLw9mB1ptq/QVLs7bKtjFTC9xervr+m7IlS0jlaN1IiyYYi+lve1qsP8evB8P3KXE4pE7H/zmLQQc2gUMImZ7Z0jgWrXwOoIT8j/e5HyzaKbIM0KkccJYWfU1ebB/tpoAQWg2EHjmLR295L+EWowrZ7yOQnwW2L2JPhj9U+1ApLY4k0zEIXxMV/vc24lCMDOLVFwFOMQ== 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; 18 Nov 2020 00:37:26 -0000 Received: by ary.qy (Postfix, from userid 501) id 2EC6B2782C29; Tue, 17 Nov 2020 19:37:25 -0500 (EST) Date: 17 Nov 2020 19:37:25 -0500 Message-Id: <20201118003726.2EC6B2782C29@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: ned.freed@mrochek.com In-Reply-To: <01RS3UPGOLZI005PTU@mauve.mrochek.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] =?utf-8?q?Ticket_=2327=3A_Erratum_4315=3A_IPv6_ABNF_?= =?utf-8?q?needs_updating_to_align_with_RFC_5952_and_RFC_3986?= 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, 18 Nov 2020 00:37:30 -0000 In article <01RS3UPGOLZI005PTU@mauve.mrochek.com> you write: >> > Given this context, it would be a serious understatement To say I see no value >> > in worrying about canonical forms for IPv6 in domain literals. >> > >> > tl;dr. The proposed change provides nothing of value and may have some >> > cost. It should be rejected. > >> Ok, fair point. I suggest we keep John's change to match RFC 3986 (URI spec), >> but don't do anything else to comply with RFC 5952. We can also add some text >> to the A/S draft saying that IPv6 syntax is not necessarily canonical, so it >> doesn't follow recommendations from RFC 5952. > >Works for me. OK with me too. I'm certainly not going to change the code that produces and parses v6 literals in Received headers which is where they mostly appear in the mail I see. R's, John From nobody Tue Nov 17 18:48:24 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 B75D03A12CC for ; Tue, 17 Nov 2020 18:48:22 -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=OGwupqPO; dkim=pass (2048-bit key) header.d=taugh.com header.b=NuYQelgi 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 FKz9iYgCi9Dg for ; Tue, 17 Nov 2020 18:48:21 -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 145A33A09FC for ; Tue, 17 Nov 2020 18:48:20 -0800 (PST) Received: (qmail 34141 invoked from network); 18 Nov 2020 02:48:17 -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=855a.5fb48b71.k2011; bh=9Y83+bJBWEbcsQ0wgUpPFxUnDxjZ5D3YS/tF9HoiaaA=; b=OGwupqPO1fafd8ijs+Eft6loIPgnpwpdVWQZBZWUnUGxtRTSfPbbW4dSAyHEq0rTpTSWQ29mU7Pl3i1yvgYYTebNKQOBLwvQXYnczdkMSsOutl8XB+C29R3rSuAwycHB4zHBXGG+jayTKy+UMIQPDraXfyfnrxWZkv3aDVNkkHy0YJ8+pmdMialVEfdK0XhiZPbdlaEmWaaodIYpd+Nmc3Pxv0mx5NfVci41FYgKBZf+Ay/s8l1U1Km/ve1gMIEZs3s9GlL6iZwr9rTb6zgYCoKw0jcokgbbuZNGJl++cmUnzDIoTmjT9n6gV/yYrLKJaShja851d8cKOUTt3N9B4g== 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=855a.5fb48b71.k2011; bh=9Y83+bJBWEbcsQ0wgUpPFxUnDxjZ5D3YS/tF9HoiaaA=; b=NuYQelgiWvEab3p/v9ln4lKx76dSJD2pHGP7m4+bmOmzFJW4giwiWIS6voVtCTKE82zFAM/3H4XncCuIqfd/Ztn8yAzhU/ly6ZijkVaBf1sxEFfRmWj1FnJ6tOrTK/VtYcsC4SbduH0sRt7wL9JaZqF1+8bc0USVIE1xKb1hL0HuueCK+tSMNClaiTt5hfxsZrk6REZdG8gmtsNsPqLJkuIeGWU3QaDoh9knxwURsBc2sz6Ah8Ub24DA3ak8DemL5lAIqfaTVvXBZwLd59HCl/Nt/LJg53FiZftVrpQnMoqlSejb3Ilt7RSjlcvTisDbpU1gn8F6YTKeRJT8l1oGVw== 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; 18 Nov 2020 02:48:17 -0000 Received: by ary.qy (Postfix, from userid 501) id 19F3A278400F; Tue, 17 Nov 2020 21:48:16 -0500 (EST) Date: 17 Nov 2020 21:48:16 -0500 Message-Id: <20201118024817.19F3A278400F@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <660d8af5-2b83-3507-00aa-a792eb9d2118@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Obnoxious, 11th hour, appeal of the decision to hold an emailcore meeting 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, 18 Nov 2020 02:48:23 -0000 In article <660d8af5-2b83-3507-00aa-a792eb9d2118@dcrocker.net> you write: >The Meetecho folks are great and they tend to make good usability >choices.  But they have never been a serious business. So it is not >surprising that that industry has run right past them, especially with >the current usage pressures, driving aggressive enhancement. Unfortunate but quite true. R's, John From nobody Tue Nov 17 18:54: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 13A203A1243 for ; Tue, 17 Nov 2020 18:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=VPPca85h; dkim=pass (2048-bit key) header.d=taugh.com header.b=OgB+m6nZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_s74vqPixrW for ; Tue, 17 Nov 2020 18:54:25 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0BE03A102D for ; Tue, 17 Nov 2020 18:54:24 -0800 (PST) Received: (qmail 35753 invoked from network); 18 Nov 2020 02:54:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=8ba7.5fb48ce0.k2011; bh=L4noSD4R7hFrtr9wPW7Fh+CcUgdknqktK4FoZMASnrA=; b=VPPca85hFwUiu7qAZ1zPGYm1zBfKaHKtRsTmpUgrfLWFfraFh6+RtnWF1BARJ38imDmhAYTuJikMSjxbfOWBPNLq68+H0mSnE4KN055shKht2193GtuBbs8uBX/5S8BvwqrX4vBPsQWxIH5TlSHtemfFycC9/0pIN7uxzc/zewt8TaHn/8+HDcACyWDiw+jY6DncK+zL97z94X6XOsMqzCboZ7RPkfhg3e+FebcwTpKT7c06aW6nr1rRykZJV73X5St+uZtxd7aSLr/0mu7xLQqrRAzx3myLQhrCN2AgjB6DsKXJLmmd0TqzOx49pi5zIf6afvfRTjkb6KyoJngKQg== 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=8ba7.5fb48ce0.k2011; bh=L4noSD4R7hFrtr9wPW7Fh+CcUgdknqktK4FoZMASnrA=; b=OgB+m6nZ89UeBMyzFLpH1EY3ZLD02Pd5SRvQB9wspaoXA+SPsRbG0zjgW0RT97TiQIRneSa/IP4bBAo2f5um2tlaCM5WWkCigv02dS/Ghzgka/th/yJVT8N4X+/pX5GTW7AZ3+4m5ul2pgUDdbDRXLg4uUSJozdpgwo5mcUdz+Ni8oKZW+rJDrb8h+5X2tExEk/DkMQUZV5Lx1jG9TnT/bkm0BAabNHPYZ7+vCY3V1eVJ/xjmSk1k2W5qPRtrwpVPOpoLzaglen6NgeyzSB5VDVlWh7q9TI1i+5MJcq5QvR+9r4iWlNc4nzjpPwVW43bD5esgBtyFt7OmrmoaemVUg== 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; 18 Nov 2020 02:54:23 -0000 Received: by ary.qy (Postfix, from userid 501) id 3ADF827840B1; Tue, 17 Nov 2020 21:54:22 -0500 (EST) Date: 17 Nov 2020 21:54:22 -0500 Message-Id: <20201118025423.3ADF827840B1@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: ned.freed@mrochek.com In-Reply-To: <01RS3ULW3EE6005PTU@mauve.mrochek.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #8: Need a registry of header fields that are Ok to add after submission 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, 18 Nov 2020 02:54:27 -0000 In article <01RS3ULW3EE6005PTU@mauve.mrochek.com> you write: >> On 16/11/2020 18:10, Alexey Melnikov wrote: >> > >> > IANA is requested to create a new subregistry for email header fields that can >> > be added to a message header section by a “relay” and/or “delivery” SMTP >> > system. The new subregistry would show whether a header field can be added by a >> > “relay”, “delivery” system or both. This is, as I think is fairly obvious, really the same topic as the forwarding and mailing list headers one. I think we can come up with a fairly short list of headers that are fixed by submission time (I agree we don't try to distinguish between MUA and MSA.) Anything else can be added when a message is relayed or delivered up to the maxmum number of each header allowed, typically one. I also don't think it's useful to try to distinguish at this level between relay and delivery since for a lot of MTAs (mine for example) the distinction is pretty fuzzy. There is a very short list of headers that can be deleted or replaced when a message is relayed, currently just Authentication-Results. This has approximately nothing to do with mailing lists which create a new message by editing the incoming message in all of the fun and exciting ways we know. R's, John From nobody Tue Nov 17 19:11:15 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 5B85D3A1319; Tue, 17 Nov 2020 19:11:12 -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 9gPZkuqY7ilg; Tue, 17 Nov 2020 19:11:10 -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 8E0923A1324; Tue, 17 Nov 2020 19:11:10 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kfDsD-000Ffg-Ba; Tue, 17 Nov 2020 22:11:09 -0500 Date: Tue, 17 Nov 2020 22:11:03 -0500 From: John C Klensin To: emailcore-chairs@ietf.org cc: emailcore@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Emailcore] Request to participants and WG Chairs 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, 18 Nov 2020 03:11:12 -0000 Hi. Interesting as many of us find this particular thread/ argument (and without singling out any particular message or sender), it is far off-topic and out of scope for this WG (and bears no semblance to the subject line I started). Could people either take it elsewhere or would the Chairs please shut it down? john ---------- Forwarded Message ---------- Date: Tuesday, November 17, 2020 21:48 -0500 From: John Levine To: emailcore@ietf.org Cc: dcrocker@bbiw.net Subject: Re: [Emailcore] Obnoxious, 11th hour, appeal of the decision to hold an emailcore meeting In article <660d8af5-2b83-3507-00aa-a792eb9d2118@dcrocker.net> you write: > The Meetecho folks are great and they tend to make good > usability choices.=C2=A0 But they have never been a serious > business. So it is not surprising that that industry has run > right past them, especially with the current usage pressures, > driving aggressive enhancement. Unfortunate but quite true. R's, John --=20 Emailcore mailing list Emailcore@ietf.org https://www.ietf.org/mailman/listinfo/emailcore ---------- End Forwarded Message ---------- From nobody Wed Nov 18 05:11:24 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 2B7B83A1884 for ; Wed, 18 Nov 2020 05:11:24 -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, NICE_REPLY_A=-0.001, 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 (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id me_k2oonY5mm for ; Wed, 18 Nov 2020 05:11:22 -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 8B2E03A1206 for ; Wed, 18 Nov 2020 05:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1605705079; bh=ogNYa3REIoxgjTmwaY2UM/3E8k5Fv3sxGs5ZYU2+fzI=; l=2628; h=To:Cc:References:From:Date:In-Reply-To; b=CiD5ysIkvJQRBjhCIjx0w8COMehGTjGGegzO1Zrbwt2/34/M7EohBqvWYNipVoa8g Pmo8/w4yR44WH5b0cKYux6ihbd6+TkzLCKUxrBeh2N3TdN7TVrQ2rtfAH99LU1Pl+F o+zOUhmEvFDawCmDUwH9CgHUzoI/0m33xJ6B8W/V4CMG8x1mnWrkXS/oaw59F Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Original-Cc: emailcore@ietf.org 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 00000000005DC083.000000005FB51D75.000070E5; Wed, 18 Nov 2020 14:11:17 +0100 To: Ned Freed Cc: emailcore@ietf.org References: <240e4ce1-d90b-285e-8878-d79c9cad70c2@isode.com> <0b6ea1c2-2c17-5060-b981-eae166ccc1fd@tana.it> <01RS3UGHA8B8005PTU@mauve.mrochek.com> From: Alessandro Vesely Message-ID: <5de2659d-e2d2-802b-0f90-e738fbc28fa0@tana.it> Date: Wed, 18 Nov 2020 14:11:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <01RS3UGHA8B8005PTU@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #4: Exploders seem to be prohibited from adding List-* header fields 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, 18 Nov 2020 13:11:24 -0000 On 17/11/2020 14:13, Ned Freed wrote: >> On 16/11/2020 17:53, Alexey Melnikov wrote: >>> >>> I would like us to discuss the following ticket for rfc5321bis: >>> >>> 3.9. Mailing Lists and Aliases > > >> Can we change that title?  It is itself misleading.  I'd propose "Forwarding". > > The terms agree with those in the email architecture document, and the NOTARY > documents before that. What would be misleading is to switch to different > terms after ~25 years. RFC 5598 treats mailing list and aliases as two of five cases of "Mediators". In that sense, it is much more general. The NOTARY documents seem to derive from Section 5.3.6 of RFC 1123, which seems to describe some oldish software and is not general at all. Nowadays mailing list managers are well detached from MTA software. Perhaps, the best resolution is to drop Section 3.9 entirely, as Dave suggested in December last year[*]. Otherwise, focusing it on terminology can be useful to straighten out some basic email concepts. "Forwarding", for example, deserves a definition. For standardization concerns, in neither case any existing implementation would be affected by changing that section of the document. >> IMHO, aliasing to internal users, such as Sales => Mike, Bob, is very different >> from aliasing to external addresses, such as is done for email address >> portability. > > In what way is it different? What semantic changes are involved? Please > be very specific. Deliverability. >>> Strawman proposal how to address this issue: >>> >>> OLD: >>> >>>      However, in this case, the message header section (RFC 5322 [11]) >>>      MUST be left unchanged; in particular, the "From" field of the header >>> >>> NEW: >>> >>>      However, in this case, the message header section (RFC 5322 [11]) >>>      MUST NOT be modified, except for adding header fields related to >>>      mailing list processing (e.g. List-* [RFC4021][RFC8058]) and/or trace >>>      header fields [rfc5322bis]; [...] >>> >>> Please discuss if the proposed text is an improvement and whether it can be >>> further improved. > >> I'd drop the MUST NOT altogether.  The MAIL FROM discussion is pristine. >> Trying to limit what part of a message an MDA can change makes no sense. > > In the list case, yes, I agree. The alias case is more subtle, and I for one > think we have a problem with how we've defined it that goes beyond this > text. Agreed. Best Ale -- [*] bullet 4 in: https://mailarchive.ietf.org/arch/msg/ietf-smtp/K1MpIrubUzq6-90Ikdl4yuh7n3o From nobody Sat Nov 21 13:55:23 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 EF6EE3A07D7 for ; Sat, 21 Nov 2020 13:55:21 -0800 (PST) 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=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 WfAr2ykDY2rD for ; Sat, 21 Nov 2020 13:55:20 -0800 (PST) Received: from haven.eyrie.org (haven.eyrie.org [IPv6:2001:470:30:84:e276:63ff:fe62:3539]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597E03A07D3 for ; Sat, 21 Nov 2020 13:55:20 -0800 (PST) Received: from lothlorien.eyrie.org (96-90-234-101-static.hfc.comcastbusiness.net [96.90.234.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by haven.eyrie.org (Postfix) with ESMTPS id 0983A11820C for ; Sat, 21 Nov 2020 13:55:18 -0800 (PST) Received: by lothlorien.eyrie.org (Postfix, from userid 1000) id E0074B40E4C; Sat, 21 Nov 2020 13:55:17 -0800 (PST) From: Russ Allbery To: emailcore@ietf.org In-Reply-To: <01RS3KCZXVQW005PTU@mauve.mrochek.com> (Ned Freed's message of "Mon, 16 Nov 2020 23:31:44 -0800 (PST)") Organization: The Eyrie References: <240e4ce1-d90b-285e-8878-d79c9cad70c2@isode.com> <01RS3KCZXVQW005PTU@mauve.mrochek.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Date: Sat, 21 Nov 2020 13:55:17 -0800 Message-ID: <87h7pi4bp6.fsf@hope.eyrie.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Ticket #4: Exploders seem to be prohibited from adding List-* header fields 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, 21 Nov 2020 21:55:22 -0000 Ned Freed writes: > And of course once you want to talk about aliases, you have to > distinguish them from mailing lists. With all that implies. If there is a reason to retain this section to talk about behavior in the alias case (and I think there might be, although I'm not certain), then drawing this distinction, although difficult, seems worthwhile. Given current practice, I think SMTP should treat a managed mailing list as a final recipient of a message. The message is delivered to the mailing list, at which point SMTP's responsibilities end. The mailing list may then choose send a new message with a remarkable similarity to the original message to all the list members in a way akin to aliasing. But it may also add new headers, remove headers, rewrite the From and/or Reply-To headers, change the Subject header, merge multiple messages together into a digest message, selectively discard some messages, hold messages for moderation, remove elements from the body of the message, add elements to the body of the message, decrypt the body and re-encrypt it with different keys, interpret the message as control commands, and many other things, all of which are seen in practice and which seem likely to continue. In other words, I think the transformations commonly seen in practice (and desired by mailing list members and administrators) go considerably beyond the topic of this ticket. I think it's relatively obvious there's no way to model all of that behavior in the SMTP standards, particularly given the narrow goal of the current work. If someone wanted to document best practices for mailing lists, that seems much better done as an entirely separate document. So, therefore, I think the question is whether to retain something like the current language but limit its scope in some way to clarify that this is only about "simple aliasing" (which we'd have to define), or decide that the benefits of describing aliasing behavior outweigh the effort in distinguishing that from more complex list handling. -- Russ Allbery (eagle@eyrie.org) From nobody Sun Nov 29 09:33:54 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 7B45B3A0A1E for ; Sun, 29 Nov 2020 09:33:52 -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 VBK3ub1jMxGD for ; Sun, 29 Nov 2020 09:33:51 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 0E74A3A0A1F for ; Sun, 29 Nov 2020 09:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1606671230; d=isode.com; s=june2016; i=@isode.com; bh=MANIGDwZ6jqj2s4f1FMf0OinjfUHBGlKSFWS1NVwlUA=; 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=jmeV5xgSNhCoCKGHrxIb/QEF+b2cfiRi2FvzQTVuKVcy+f5MGYaVbtu+cFKg2m5Yi4gKqU CU5y8JYqHmW3VD2P93rkhic5i/V5mLeP3ia2KJ6I0cTv49ye1Cf4uuMa5mwR72dihDCEwI X4iIjFgYXkFdIUmRXuud7lZS3FlkFVI=; Received: from [192.168.0.5] ((unknown) [176.252.130.164]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 29 Nov 2020 17:33:50 +0000 X-SMTP-Protocol-Errors: NORDNS To: emailcore@ietf.org References: <35ab0a5a-2758-4c64-9f66-3a5f3d8d7a26@isode.com> <01RS3HYELTKW005PTU@mauve.mrochek.com> <649b287b-81ca-48a5-af8b-dcbe6670fcc6@www.fastmail.com> <01RS3UPGOLZI005PTU@mauve.mrochek.com> From: Alexey Melnikov Message-ID: <2b1588e7-a0b8-0d71-2ff4-002abfdfee7b@isode.com> Date: Sun, 29 Nov 2020 17:33:53 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 In-Reply-To: <01RS3UPGOLZI005PTU@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: [Emailcore] RESOLVED: Ticket #27: Erratum 4315: IPv6 ABNF needs updating to align with RFC 5952 and RFC 3986 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2020 17:33:53 -0000 On 17/11/2020 13:27, Ned Freed wrote: >> On Tue, Nov 17, 2020, at 6:51 AM, Ned Freed wrote: >> [snip] >>> Given this context, it would be a serious understatement To say I see no value >>> in worrying about canonical forms for IPv6 in domain literals. >>> >>> tl;dr. The proposed change provides nothing of value and may have some >>> cost. It should be rejected. >> Ok, fair point. I suggest we keep John's change to match RFC 3986 (URI spec), >> but don't do anything else to comply with RFC 5952. We can also add some text >> to the A/S draft saying that IPv6 syntax is not necessarily canonical, so it >> doesn't follow recommendations from RFC 5952. > Works for me. Based on the mailing list discussion I declare consensus on this ticket as per the proposal above (i.e. no further change is needed to rfc5321bis). Best Regards, Alexey, as a co-chair From nobody Sun Nov 29 10:27:04 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 91E5A3A0B18 for ; Sun, 29 Nov 2020 10:27:02 -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 jVRYUgSBAl23 for ; Sun, 29 Nov 2020 10:27:01 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 595213A0B17 for ; Sun, 29 Nov 2020 10:27:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1606674420; d=isode.com; s=june2016; i=@isode.com; bh=ryCLGOCx3Phi8oUtpdeMjho/r3L+vEn37IKmRqpO71g=; 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=Ja55vfWpFjWPlAWxbVR8GZ4995v4rS2rhCWl/RocNPlRj7ZVzzrqg221myMmZyzBJyjfaI H39mtW+hDK9wqVHi4qknl0DCPjGCYgC+6m9HqQV+cf/a9VNgfi6uelFqBq4/HkEsAC831Q GOnyY6+lXaLKIRdzr33TwrCeYtzOK2M=; Received: from [192.168.0.5] ((unknown) [176.252.130.164]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 29 Nov 2020 18:26:59 +0000 X-SMTP-Protocol-Errors: NORDNS From: Alexey Melnikov To: emailcore@ietf.org Message-ID: Date: Sun, 29 Nov 2020 18:27:03 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [Emailcore] Ticket #4: Exploders seem to be prohibited from adding List-* header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2020 18:27:03 -0000 Dear collegues, After some discussion of this ticket during IETF 109 and on the mailing=20 list it became clear that there was no consensus for my earlier strawman=20 proposal. I would like to make a new strawman proposal: 3.9. Mailing Lists and Aliases =C2=A0=C2=A0=C2=A0 [...] When a message is =C2=A0=C2=A0=C2=A0 delivered or forwarded to each address of an expanded li= st form, the =C2=A0=C2=A0=C2=A0 return address in the envelope ("MAIL FROM:") MUST be ch= anged to be =C2=A0=C2=A0=C2=A0 the address of a person or other entity who administers = the list. =C2=A0=C2=A0=C2=A0 However, in this case, the message header section (RFC 5= 322 [11]) =C2=A0=C2=A0=C2=A0 MUST be left unchanged; in particular, the "From" field = of the header =C2=A0=C2=A0=C2=A0 section is unaffected. As John Klensin pointed out, the last MUST is still correct for aliases.=20 So my new strawman proposal is as follows: In Section 3.9: REMOVE: =C2=A0=C2=A0=C2=A0 However, in this case, the message header section (RFC 5= 322 [11]) =C2=A0=C2=A0=C2=A0 MUST be left unchanged; in particular, the "From" field = of the header =C2=A0=C2=A0=C2=A0 section is unaffected. The current Section 3.9.1 reads: > 3.9.1.=C2=A0 Alias > > =C2=A0=C2=A0 To expand an alias, the recipient mailer simply replaces the = pseudo- > =C2=A0=C2=A0 mailbox address in the envelope with each of the expanded add= resses > =C2=A0=C2=A0 in turn; the rest of the envelope and the message body are le= ft > =C2=A0=C2=A0 unchanged.=C2=A0 The message is then delivered or forwarded t= o each > =C2=A0=C2=A0 expanded address. ADD after it the following text: =C2=A0=C2=A0=C2=A0 Aliases MUST leave the message header section (RFC 5322 = [11]) =C2=A0=C2=A0=C2=A0 unchanged; in particular, the "From" field of the header =C2=A0=C2=A0=C2=A0 section is unaffected. (Section 3.9.2 talks about mailing lists and already has text that=20 contradicts this MUST in section 3.9. So removing text from 3.9 will=20 address that contradiction). Best Regards, Alexey, as a co-chair From nobody Sun Nov 29 11:12:59 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 7AC9E3A0C57 for ; Sun, 29 Nov 2020 11:12:58 -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, 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 H8HUaRysIuB3 for ; Sun, 29 Nov 2020 11:12:55 -0800 (PST) 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 59D453A0C4C for ; Sun, 29 Nov 2020 11:12:55 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0ATJGV0T002805 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 29 Nov 2020 11:16:31 -0800 Reply-To: dcrocker@bbiw.net To: Alexey Melnikov , emailcore@ietf.org References: From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Sun, 29 Nov 2020 11:12:46 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #4: Exploders seem to be prohibited from adding List-* header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2020 19:12:59 -0000 On 11/29/2020 10:27 AM, Alexey Melnikov wrote: > I would like to make a new strawman proposal: I will, instead, suggest first having a clear, focused discussion that produces architectural consensus on why the specification for the Internet mail transfer protocol needs to have text about the treatment of mail after delivery, concerning re-posting. An author specifies a recipient address. The mail reaches that address. The receiving site has a mechanism that is under the control of the specified addressee, not the author or the originator, which then submits the message for further processing. The fact that one version of this mechanism is implemented in software that also performs MTA functions does not make it an MTA function. At best, it's an MDA function. That is, it is entirely outside the scope of SMTP. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Nov 29 12:26:31 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 EDB723A0E0F for ; Sun, 29 Nov 2020 12:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=gJdViriI; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=f0u145jw 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 Z458fX40tSPj for ; Sun, 29 Nov 2020 12:26:27 -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 F257D3A03FC for ; Sun, 29 Nov 2020 12:26:26 -0800 (PST) Received: (qmail 59241 invoked by uid 100); 29 Nov 2020 20:26:22 -0000 Date: 29 Nov 2020 20:26:21 -0000 Message-ID: From: "John Levine" To: emailcore@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=e760.5fc403ee.k2011; i=news@user.iecc.com; bh=/Jq2n9Cbr7k9CeEIiDRvJ6cpBkMDjF+5BGJB/yZ3v60=; b=gJdViriIsUyC88Xz1sfrlLbmM5VrhnFHC2ZOysAskUaN8l4RQYynI0RkPRJdI8VutXxNzHqVXVLP8waM5Y1BHzFArtqueA6WA/3ZgJL7pZNVIPv00ttEslDFGZBsPqJGZUflNfZUCFJdeK2v2xfGbbM0ZfvO34jnQ2lqdBg/JUT6ikV6Nq3ZTL/RKRGJaPyJaxrnEgkpWY1IOrWkJ34I41Zy7aVcU8l1D3G7Levrk0rzuoKiwO+eKHqcFH6+8GmpQjNgJjszkFV9EJWeczTFlkB+8LOZjxqO+3TivoNPPCaNLjPe4mkIflbXblyFrwFz7pucduPigddAMYWstLkTSA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=e760.5fc403ee.k2011; olt=news@user.iecc.com; bh=/Jq2n9Cbr7k9CeEIiDRvJ6cpBkMDjF+5BGJB/yZ3v60=; b=f0u145jw3m969vN00bBALyynFocwwerA813pYdIm5KqwpnZ1L3l/E6HnHB4hyskYH/tc2SEWmw/B/JK9IboYHBXcgyKiCH7CoRD/AztbiD3EYvKU5ib5YiH1ufSAvIOx7A+bPvKyqADHmLQC07xlSVRyGoG75YQE7ZCr7x0CQTkNK4SpIO9SbKFxB79X9OriO6+Oy6uUTpxWjBtNDlGYBI99enBO8BWIUPRXJ/2nHCjpKvtZhvJc52ws0cYzvoENqFGD2vJzA1FH0ahn4mexH8DIvY9AbNxB+yBBjUuIxDjqLtwd6mQjPqKJtDu8UuOHrAdQ6RN2EB+oxNwevBb+0w== Organization: Taughannock Networks References: In-Reply-To: Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [Emailcore] Ticket #4: Exploders seem to be prohibited from adding List-* header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2020 20:26:30 -0000 In article , Dave Crocker wrote: >On 11/29/2020 10:27 AM, Alexey Melnikov wrote: >> I would like to make a new strawman proposal: >I will, instead, suggest first having a clear, focused discussion that >produces architectural consensus on why the specification for the >Internet mail transfer protocol needs to have text about the treatment >of mail after delivery, concerning re-posting. > >An author specifies a recipient address. The mail reaches that address. > The receiving site has a mechanism that is under the control of the >specified addressee, not the author or the originator, which then >submits the message for further processing. I'm not sure that's the right answer but I think we agree that sec 3.9 no longer describes the way that mail systems work today. I'd take out everything about mailing lists in 3.9.2 other than the observation that they act as full MUAs. There is certainly still a lot of alias style forwarding happening and the question is whether there's anything useful to say about it. The implicit advice not to change the envelope bounce address seems likely to cause as many problems as it solves. ("Why am I getting bounces from bob@example.com when I sent mail to sales@example.org?") The advice not to change the other headers seems more like local policy than interoperability. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Nov 30 00:38:41 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 917803A1124 for ; Mon, 30 Nov 2020 00:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niwOYYn_ERA4 for ; Mon, 30 Nov 2020 00:38:37 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403723A115E for ; Mon, 30 Nov 2020 00:38:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606725515; bh=9darcdz2AjmtoP1KLQ9D9/rdem6dpbM8tmkMKY5R1dc=; l=2299; h=To:References:From:Date:In-Reply-To; b=AKxuPXavTb5nftSEQrmU32BSszPoiRPSNEo0DZRdGGoMwj4OFGEJiPWQv3AXqo3ZO Nkis+BS074iHBzwo9FH9gTKMXa7mCoo0jOC93KecYEqimwLqAsdRz02JjuulDzpVsd 3xf4JZgarlxNxsU+1ausaEgVQrd7jQnBNxekq7CrUmxMIs3sD4JbtRQ1IPLgZ 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 00000000005DC07C.000000005FC4AF8A.0000142B; Mon, 30 Nov 2020 09:38:34 +0100 To: John Levine , emailcore@ietf.org References: From: Alessandro Vesely Message-ID: <317337f7-018b-bf3f-d73c-ec5e04f823de@tana.it> Date: Mon, 30 Nov 2020 09:38:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #4: Exploders seem to be prohibited from adding List-* header fields 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, 30 Nov 2020 08:38:40 -0000 On 29/11/2020 21:26, John Levine wrote: > In article , > Dave Crocker wrote: >>On 11/29/2020 10:27 AM, Alexey Melnikov wrote: >>> I would like to make a new strawman proposal: > >>I will, instead, suggest first having a clear, focused discussion that >>produces architectural consensus on why the specification for the >>Internet mail transfer protocol needs to have text about the treatment >>of mail after delivery, concerning re-posting. The spec must clarify the semantic meaning of a Mailbox. Putting forth the concept of forwarding and exemplifying a couple of its instantiations delivers an important aspect of that. For example, a lawmaker wishing to regulate responsibilities for sending and accepting SMTP messages has to be well aware of this point. (Yes, I fantasize that lawmakers read technical specs.) >>An author specifies a recipient address. The mail reaches that address. >> The receiving site has a mechanism that is under the control of the >>specified addressee, not the author or the originator, which then >>submits the message for further processing. > > I'm not sure that's the right answer but I think we agree that sec 3.9 > no longer describes the way that mail systems work today. +1 > I'd take out everything about mailing lists in 3.9.2 other than the > observation that they act as full MUAs. Section 3.9.2 uses the term MUA. I don't think it's correct, as the "U" for "user" suggests human interaction. Could we use MLM, as in RFC 6377? > There is certainly still a lot of alias style forwarding happening and the > question is whether there's anything useful to say about it. The implicit > advice not to change the envelope bounce address seems likely to cause as > many problems as it solves. ("Why am I getting bounces from bob@example.com > when I sent mail to sales@example.org?") Also "Aha, mail sent to bob@freemail.example bounces from bob@his.secret.place". > The advice not to change the other headers seems more like local policy than > interoperability. Limiting to trace fields could be set as an MTA peculiarity. That is, SMTP manages the envelope, not the content, except for trace fields. Best Ale -- From nobody Mon Nov 30 05:38:59 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 9EF893A0B0A for ; Mon, 30 Nov 2020 05:38:57 -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, 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 e6pOnJ4godLc for ; Mon, 30 Nov 2020 05:38:55 -0800 (PST) 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 EE4693A0B08 for ; Mon, 30 Nov 2020 05:38:54 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0AUDgX40014837 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 30 Nov 2020 05:42:33 -0800 Reply-To: dcrocker@bbiw.net To: Alessandro Vesely , John Levine , emailcore@ietf.org References: <317337f7-018b-bf3f-d73c-ec5e04f823de@tana.it> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <6e617fa2-345f-1efb-3b50-41741d607145@dcrocker.net> Date: Mon, 30 Nov 2020 05:38:47 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <317337f7-018b-bf3f-d73c-ec5e04f823de@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #4: Exploders seem to be prohibited from adding List-* header fields 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, 30 Nov 2020 13:38:58 -0000 On 11/30/2020 12:38 AM, Alessandro Vesely wrote: > On 29/11/2020 21:26, John Levine wrote: >> In article , >> Dave Crocker  wrote: >>> On 11/29/2020 10:27 AM, Alexey Melnikov wrote: >>>> I would like to make a new strawman proposal: >> >>> I will, instead, suggest first having a clear, focused discussion >>> that produces architectural consensus on why the specification for >>> the Internet mail transfer protocol needs to have text about the >>> treatment of mail after delivery, concerning re-posting. > > > The spec must clarify the semantic meaning of a Mailbox.  Putting forth It is a bad idea to have multiple specifications defining the same thing: RFC 5598, 3.1 Mailbox: > "A mailbox receives mail. It is a conceptual entity that does not > necessarily pertain to file storage." [RFC5322] > > A mailbox is specified as an Internet Mail address . > the concept of forwarding and exemplifying a couple of its > instantiations delivers an important aspect of that. Already done in RFC 5598. So... > 2.2.2. Relay ... > In other words, email scenarios can involve three distinct > architectural layers, each providing its own type of data of store- > and-forward service: > > * User Mediators > > * MHS Relays > > * Packet Switches and > 3.4.1. Message-ID ... > o If a message is forwarded by a Recipient, what is forwarded is a > new message. and > 5. Mediators ... > Basic message transfer from Author to Recipients is accomplished by > using an asynchronous store-and-forward communication infrastructure > in a sequence of independent transmissions through some number of > MTAs. A very different task is a sequence of postings and deliveries > through Mediators. A Mediator forwards a message through a > re-posting process. and > 5.1. Alias > > One function of an MDA is to determine the internal location of a > mailbox in order to perform delivery. An Alias is a simple > re-addressing facility that provides one or more new Internet Mail > addresses, rather than a single, internal one; the message continues > through the transfer service, for delivery to one or more alternate > addresses. Although typically implemented as part of an MDA, this > facility is a Recipient function. It resubmits the message, although > all handling information except the envelope Recipient > (rfc5321.RcptTo) address is retained. In particular, the Return > Address (rfc5321.MailFrom) is unchanged. > > What is distinctive about this forwarding mechanism is how closely it > resembles normal MTA store-and-forward relaying. (please take special note of those last two lines. /d) >> I'd take out everything about mailing lists in 3.9.2 other than the >> observation that they act as full MUAs. > > > Section 3.9.2 uses the term MUA.  I don't think it's correct, as the "U" > for "user" suggests human interaction.  Could we use MLM, as in RFC 6377? The UA/MTA distinction has been used since roughly 1980. Its use does not automatically mean direct user interaction but, rather, acting on behalf of the user. Hence, 'agent'. Again... RFC 5598, Section 4.2.1 Message User Agent (MUA) > A Message User Agent (MUA) works on behalf of User Actors and User > applications. It is their representative within the email service. The IETF spent 5 years developing RFC 5598. It should use it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net