From nobody Fri Jul 2 15:06:27 2021 Return-Path: X-Original-To: emailcore@ietf.org Delivered-To: emailcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB1E3A0AD3; Fri, 2 Jul 2021 15:02:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: emailcore@ietf.org, superuser@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162526337970.26814.1130543904085539880@ietfa.amsl.com> Date: Fri, 02 Jul 2021 15:02:59 -0700 Archived-At: Subject: [Emailcore] emailcore - Requested session has been scheduled for IETF 111 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 22:03:11 -0000 Dear Alexey Melnikov, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. emailcore Session 1 (1:00 requested) Tuesday, 27 July 2021, Session II 1430-1530 Room Name: Room 2 size: 502 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/111/sessions/emailcore.ics Request Information: --------------------------------------------------------- Working Group Name: Revision of core Email specifications Area Name: Applications and Real-Time Area Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: People who must be present: Alexey Melnikov Dr. John C. Klensin Murray Kucherawy Pete Resnick Todd Herr Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Jul 5 10:24:52 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F133A200F for ; Mon, 5 Jul 2021 10:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 c5N3i8DUNKiN for ; Mon, 5 Jul 2021 10:24:45 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 65BE73A200C for ; Mon, 5 Jul 2021 10:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1625505882; d=isode.com; s=june2016; i=@isode.com; bh=5z/Vtfgw1e9261ckUPUCs8saPUJBPkYU1PJIBt1DkJw=; 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=IvIXUfkACiiGwT2CGWsw3e9QwsLi/4XYpXnZNVtTgsZwtuYDzdulI+VtEp8YNWeGQf14OD iv8Nk5doX4OWPjg5KsFkB3vgTFc++w2uNAljna5MN8+G45e8pP+tWe/ldgvitF/W1NC5Mz w8XcSP6jVjFrwyz+pEH3s2/XXifs7tI=; Received: from [192.168.1.222] (host5-81-100-22.range5-81.btcentralplus.com [5.81.100.22]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 5 Jul 2021 18:24:41 +0100 To: emailcore@ietf.org From: Alexey Melnikov Message-ID: Date: Mon, 5 Jul 2021 18:24:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.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 #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 05 Jul 2021 17:24:50 -0000 draft-ietf-emailcore-rfc5321bis-02 currently says: 3.3.=C2=A0 Mail Transactions =C2=A0=C2=A0 There are three steps to SMTP mail transactions.=C2=A0 The tra= nsaction =C2=A0=C2=A0 starts with a MAIL command that gives the sender identificatio= n.=C2=A0 (In =C2=A0=C2=A0 general, the MAIL command may be sent only when no mail transa= ction =C2=A0=C2=A0 is in progress; see Section 4.1.4.)=C2=A0 A series of one or m= ore RCPT =C2=A0=C2=A0 commands follows, giving the receiver information.=C2=A0 Then,= a DATA =C2=A0=C2=A0 command initiates transfer of the mail data and is terminated = by the =C2=A0=C2=A0 "end of mail" data indicator, which also confirms the transact= ion. =C2=A0=C2=A0 Mail transactions are also terminated by the RSET command =C2=A0=C2=A0 (Section 4.1.1.5), the sending of an EHLO command (Section 3.2= ), or =C2=A0=C2=A0 the sending of a QUIT command (Section 3.8) which terminates b= oth any =C2=A0=C2=A0 active mail transaction and the SMTP connection. 4.1.4.=C2=A0 Order of Commands =C2=A0 [...] =C2=A0=C2=A0 The MAIL command begins a mail transaction.=C2=A0 Once started= , a mail =C2=A0=C2=A0 transaction consists of a transaction beginning command, one o= r more =C2=A0=C2=A0 RCPT commands, and a DATA command, in that order.=C2=A0 A mail= transaction =C2=A0=C2=A0 may be aborted by the RSET, a new EHLO, or the QUIT command. T= here =C2=A0=C2=A0 may be zero or more transactions in a session.=C2=A0 MAIL MUST= NOT be sent =C2=A0=C2=A0 if a mail transaction is already open, i.e., it should be sent= only =C2=A0=C2=A0 if no mail transaction had been started in the session, or if = the =C2=A0=C2=A0 previous one successfully concluded with a successful DATA com= mand, =C2=A0=C2=A0 or if the previous one was aborted, e.g., with a RSET or new E= HLO. Ticket #11 suggests that 3.3 can be improved by being more specific=20 about where mail transactions begin and end. And section 4.1.4 has a=20 note "comment about changing this convoluted discussion to talk about=20 'mail transaction' above." Looking at these 2 sections, I observe that 3.3 talks about how a=20 transaction starts, but can be slightly improved by clarifying how it=20 terminates. To that end, I propose changing the last sentence of the 1st=20 paragraph of 3.3 to read: OLD: =C2=A0=C2=A0 Then, a DATA =C2=A0=C2=A0 command initiates transfer of the mail data and is terminated = by the =C2=A0=C2=A0 "end of mail" data indicator, which also confirms the transact= ion. NEW: =C2=A0=C2=A0 Then, a DATA =C2=A0=C2=A0 command initiates transfer of the mail data and is terminated = by the =C2=A0=C2=A0 "end of mail" data indicator, which also confirms (and termina= tes)=20 the transaction. Basically this clarifies that "end of mail" data indicator always=20 terminates the transaction. (Paragraph 2 of 3.3 is already clear that=20 RSET/EHLO/QUIT also terminate the transaction. I think the text in 4.1.4 is pretty clear, but it does contain some=20 duplication in comparison to 3.3. We can either leave it as is or=20 possibly shorten it to avoid duplication. Here is a strawman proposal to do the latter: =C2=A0=C2=A0 The MAIL command begins a mail transaction.=C2=A0 Once started= , a mail =C2=A0=C2=A0 transaction consists of a transaction beginning command, one o= r more =C2=A0=C2=A0 RCPT commands, and a DATA command, in that order.=C2=A0 A mail= transaction =C2=A0=C2=A0 may be aborted by the RSET, a new EHLO, or the QUIT command. T= here =C2=A0=C2=A0 may be zero or more transactions in a session.=C2=A0 MAIL MUST= NOT be sent =C2=A0=C2=A0 if a mail transaction is already open, i.e., it should be sent= only =C2=A0=C2=A0 if no mail transaction had been started in the session, or if = the =C2=A0=C2=A0 previous one successfully concluded, or if the previous one wa= s aborted. =C2=A0=C2=A0 See Section 3.3. for more details. Any opinions about the above? Best Regards, Alexey From nobody Mon Jul 5 11:15:43 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2123A0A3F for ; Mon, 5 Jul 2021 11:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 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.338, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=Ov2LjMu2; dkim=pass (2048-bit key) header.d=wizmail.org header.b=QjCSoICD 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 6GNp78B5BQPv for ; Mon, 5 Jul 2021 11:15:35 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078EC3A0A3E for ; Mon, 5 Jul 2021 11:15:34 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=rZ9xaVpXEoYobN7hKSaJwWDhpjC4lV0r+7MnZPDjzdQ=; b=Ov2LjMu2YUmhm6KDuNWbtaSgu6 JQIJToXdaV6GY9wY8W57iHWfPXjoEtteIptGwgzz9QsuvbE6ITmv61iIOFDA==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=rZ9xaVpXEoYobN7hKSaJwWDhpjC4lV0r+7MnZPDjzdQ=; b=QjCSoICDpiPoFB6hCYI+Y3aZkC 9O7YZjdZWBz097RaPJmUg64gtAbSdaYPsj5uiqevSfvS0eDfU6u4+/gRNchZBRTZDKNZqD/RaZUn7 MAWtEA7Qqmxr3DBQ31FaMhlfmC8Ehc+XuS/pzGDTl4a43c9vb6/AEb2mNYsFaDrpANkNgTB3mYAou peNT+TTndh/GKsKrywyds7z3OL26PXYro13iLMS/FpWfVqf8qWJXO5uo9Ti0RRbgygdM7Qd5X76YU ewN10aHg1hXRyv/p+Zdef83J8avmq4vk/KoLgqcryMIwEK25eFJxpNgJ1GlZnuSuAQHNUimHhFYQX g0O5N97Q==; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.94.128) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1m0T7z-000YV1-6Z for emailcore@ietf.org (return-path ); Mon, 05 Jul 2021 18:15:31 +0000 To: emailcore@ietf.org References: From: Jeremy Harris Message-ID: Date: Mon, 5 Jul 2021 19:15:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 05 Jul 2021 18:15:42 -0000 On 05/07/2021 18:24, Alexey Melnikov wrote: > Here is a strawman proposal to do the latter: > >    The MAIL command begins a mail transaction.  Once started, a mail >    transaction consists of a transaction beginning command, one or more >    RCPT commands, and a DATA command, in that order.  A mail transaction >    may be aborted by the RSET, a new EHLO, or the QUIT command. There >    may be zero or more transactions in a session.  MAIL MUST NOT be sent >    if a mail transaction is already open, i.e., it should be sent only >    if no mail transaction had been started in the session, or if the >    previous one successfully concluded, or if the previous one was aborted. > >    See Section 3.3. for more details. > > Any opinions about the above? Shouldn't the transaction be open until the _response_ to any of those client-end actions? -- Cheers, Jeremy From nobody Tue Jul 6 14:43:39 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AB63A13F0 for ; Tue, 6 Jul 2021 14:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id minWxZHzOP7P for ; Tue, 6 Jul 2021 14:43:34 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 CE8193A13F3 for ; Tue, 6 Jul 2021 14:43:34 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 22377D47A0; Tue, 6 Jul 2021 17:43:33 -0400 (EDT) Date: Tue, 6 Jul 2021 17:43:33 -0400 From: Viktor Dukhovni To: emailcore@ietf.org Message-ID: Reply-To: emailcore@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 06 Jul 2021 21:43:37 -0000 On Mon, Jul 05, 2021 at 07:15:30PM +0100, Jeremy Harris wrote: > >    The MAIL command begins a mail transaction.  Once started, a mail > >    transaction consists of a transaction beginning command, one or more > >    RCPT commands, and a DATA command, in that order.  A mail transaction > >    may be aborted by the RSET, a new EHLO, or the QUIT command. There > >    may be zero or more transactions in a session.  MAIL MUST NOT be sent > >    if a mail transaction is already open, i.e., it should be sent only > >    if no mail transaction had been started in the session, or if the > >    previous one successfully concluded, or if the previous one was aborted. > > > >    See Section 3.3. for more details. > > > > Any opinions about the above? > > Shouldn't the transaction be open until the _response_ to any > of those client-end actions? I was wondering the same thing, but on reflection I think it is clear that nothing in the server reply can extend the scope of the transaction. The transaction may succeed, fail, be terminated, or lead to an error state (a rejected RSET or EHLO presumably precludes continuing with subsequent transactions). So termination here refers to *commands* that terminate a transaction. The fact that the client typically awaits a response is implicit. (Clients might not wait for a QUIT response, and might drop a connection after a successful RSET if despite anticipating more traffic no further messages are queued for the peer). -- Viktor. From nobody Tue Jul 6 15:45:27 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8445D3A19AA for ; Tue, 6 Jul 2021 15:45:25 -0700 (PDT) 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 8oyHaLHi-nWQ for ; Tue, 6 Jul 2021 15:45:20 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B589C3A19A6 for ; Tue, 6 Jul 2021 15:45:20 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m0tod-000BmJ-6g; Tue, 06 Jul 2021 18:45:19 -0400 Date: Tue, 06 Jul 2021 18:45:12 -0400 From: John C Klensin To: Alexey Melnikov , emailcore@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 06 Jul 2021 22:45:26 -0000 --On Monday, July 5, 2021 18:24 +0100 Alexey Melnikov wrote: > draft-ietf-emailcore-rfc5321bis-02 currently says: >=20 > 3.3.=C2=A0 Mail Transactions >=20 > =C2=A0=C2=A0 There are three steps to SMTP mail = transactions.=C2=A0 The > transaction > =C2=A0=C2=A0 starts with a MAIL command that gives the sender > identification.=C2=A0 (In > =C2=A0=C2=A0 general, the MAIL command may be sent only when = no mail > transaction > =C2=A0=C2=A0 is in progress; see Section 4.1.4.)=C2=A0 A = series of one or > more RCPT > =C2=A0=C2=A0 commands follows, giving the receiver = information.=C2=A0 > Then, a DATA > =C2=A0=C2=A0 command initiates transfer of the mail data and = is > terminated by the > =C2=A0=C2=A0 "end of mail" data indicator, which also = confirms the > transaction. > =C2=A0=C2=A0 Mail transactions are also terminated by the = RSET command > =C2=A0=C2=A0 (Section 4.1.1.5), the sending of an EHLO = command > (Section 3.2), or > =C2=A0=C2=A0 the sending of a QUIT command (Section 3.8) = which > terminates both any > =C2=A0=C2=A0 active mail transaction and the SMTP connection. >=20 > 4.1.4.=C2=A0 Order of Commands >=20 > =C2=A0 [...] >=20 > =C2=A0=C2=A0 The MAIL command begins a mail = transaction.=C2=A0 Once > started, a mail > =C2=A0=C2=A0 transaction consists of a transaction beginning = command, > one or more > =C2=A0=C2=A0 RCPT commands, and a DATA command, in that = order.=C2=A0 A > mail transaction > =C2=A0=C2=A0 may be aborted by the RSET, a new EHLO, or the = QUIT > command. There > =C2=A0=C2=A0 may be zero or more transactions in a = session.=C2=A0 MAIL > MUST NOT be sent > =C2=A0=C2=A0 if a mail transaction is already open, i.e., it = should > be sent only > =C2=A0=C2=A0 if no mail transaction had been started in the = session, > or if the > =C2=A0=C2=A0 previous one successfully concluded with a = successful > DATA command, > =C2=A0=C2=A0 or if the previous one was aborted, e.g., with a = RSET or > new EHLO. >=20 > Ticket #11 suggests that 3.3 can be improved by being more > specific about where mail transactions begin and end. And > section 4.1.4 has a note "comment about changing this > convoluted discussion to talk about 'mail transaction' above." >=20 > Looking at these 2 sections, I observe that 3.3 talks about > how a transaction starts, but can be slightly improved by > clarifying how it terminates. To that end, I propose changing > the last sentence of the 1st paragraph of 3.3 to read: >=20 > OLD: >=20 > =C2=A0=C2=A0 Then, a DATA > =C2=A0=C2=A0 command initiates transfer of the mail data and = is > terminated by the > =C2=A0=C2=A0 "end of mail" data indicator, which also = confirms the > transaction. >=20 > NEW: >=20 > =C2=A0=C2=A0 Then, a DATA > =C2=A0=C2=A0 command initiates transfer of the mail data and = is > terminated by the > =C2=A0=C2=A0 "end of mail" data indicator, which also = confirms (and > terminates) the transaction. >=20 > Basically this clarifies that "end of mail" data indicator > always terminates the transaction. (Paragraph 2 of 3.3 is > already clear that RSET/EHLO/QUIT also terminate the > transaction. This seems right to me. It probably makes things a bit better; clearly it does not make them any worse. > I think the text in 4.1.4 is pretty clear, but it does contain > some duplication in comparison to 3.3. We can either leave it > as is or possibly shorten it to avoid duplication. >=20 > Here is a strawman proposal to do the latter: > The MAIL command begins a mail transaction.=C2=A0 Once = started, a > mail transaction consists of a transaction beginning command, > one or more RCPT commands, and a DATA command, in that > order.=C2=A0 A mail transaction may be aborted by the RSET, a = new > EHLO, or the QUIT command. There may be zero or more > transactions in a session.=C2=A0 MAIL MUST NOT be sent if a = mail > transaction is already open, i.e., it should be sent only if > no mail transaction had been started in the session, or if the > previous one successfully concluded, or if the previous one > was aborted. > =C2=A0=C2=A0 See Section 3.3. for more details. >=20 > Any opinions about the above? Alternative if you (and others) want to trim and get the redundancies out. This also improves on what is now an odd relationship between "MUST NOT" and "should" New: The MAIL command begins a mail transaction.=C2=A0 Once started, a mail transaction consists of a transaction beginning command, one or more RCPT commands, and a DATA command, in that order.=C2=A0 Mail transactions are defined and terminated as described in Section 3.3. MAIL MUST NOT be sent if a mail transaction is already open, i.e., it is permitted only if no mail transaction had been started in the session, or if the previous one successfully concluded, or was aborted. I am ok with either but do think the cross-reference is useful. best, john From nobody Tue Jul 6 15:50:50 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D3F3A1A18 for ; Tue, 6 Jul 2021 15:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 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.338, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aYxFGiPufxu for ; Tue, 6 Jul 2021 15:50:44 -0700 (PDT) Received: from dormouse.elm.relay.mailchannels.net (dormouse.elm.relay.mailchannels.net [23.83.212.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBAD43A1A1A for ; Tue, 6 Jul 2021 15:50:43 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 989EB642BB7; Tue, 6 Jul 2021 22:50:42 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (100-96-16-95.trex-nlb.outbound.svc.cluster.local [100.96.16.95]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 55F87642A37; Tue, 6 Jul 2021 22:50:41 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.16.95 (trex/6.3.3); Tue, 06 Jul 2021 22:50:42 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Trade-Chief: 4df2d77f0bf3cd25_1625611842296_494480201 X-MC-Loop-Signature: 1625611842296:3273155253 X-MC-Ingress-Time: 1625611842296 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 5807C10E9CC2; Tue, 6 Jul 2021 22:50:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1625611840; bh=rpfdy2HV32KuUEF5dY8n4mSMzS1Uag0dWiPO+RJQdQU=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=rpyJkQ38FhADW18xPmCabB4wsrWQQpQLTq/CRWzK2CRYNajQOw9uVxo0gdhhbWQ/8 AgTD+XR1+H5HPSv/ACm3ou0GxYcLnmAoGQ0s1KhcmzbtUa4m80gb8Shq36MT5vHndL LvUEblKj5JAwla4+etqKreOHNU0DBzImJEcnyc9Z5/7grZ7ByVltE03zqR8T8+tK98 s/dReYjB6G+GJJWyAaVAm6RKHYF/65UH1XwP/LysoEW7Ah5hkZ/MbXE99yP0etuOp2 43l1yT64G89W7mZJrXQHyzYhDlXZ+0KESkx4AbCTuuPc8wbl2vvFZ+CIIRMRRcu2CZ mS4tQIQ9h/RgA== Reply-To: dcrocker@bbiw.net To: John C Klensin , Alexey Melnikov , emailcore@ietf.org References: From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> Date: Tue, 6 Jul 2021 15:50:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.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 #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 06 Jul 2021 22:50:49 -0000 On 7/6/2021 3:45 PM, John C Klensin wrote: > The MAIL command begins a mail transaction.  Once > started, a mail transaction consists of a transaction > beginning command, As written, the above text is confusing and I'm not sure what it means. If the MAIL command begins a mail transaction, then the next thing -- what is currently described as "a transaction beginning command" -- takes place after the mail transaction has begun. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 6 16:19:52 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4733A09AF for ; Tue, 6 Jul 2021 16:19:51 -0700 (PDT) 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 DPkdlHeMuUe8 for ; Tue, 6 Jul 2021 16:19:47 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202EE3A09A5 for ; Tue, 6 Jul 2021 16:19:46 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m0uLx-000Bt8-AH for emailcore@ietf.org; Tue, 06 Jul 2021 19:19:45 -0400 Date: Tue, 06 Jul 2021 19:19:38 -0400 From: John C Klensin To: emailcore@ietf.org Message-ID: <5C50F3E6361F9E5AE613727B@PSB> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 06 Jul 2021 23:19:52 -0000 --On Tuesday, July 6, 2021 17:43 -0400 Viktor Dukhovni wrote: > On Mon, Jul 05, 2021 at 07:15:30PM +0100, Jeremy Harris wrote: >=20 >> > =C2=A0=C2=A0 The MAIL command begins a mail = transaction.=C2=A0 Once >> > started, a mail =C2=A0=C2=A0 transaction consists of a = transaction >> > beginning command, one or more =C2=A0=C2=A0 RCPT commands, = and a >> > DATA command, in that order.=C2=A0 A mail transaction = =C2=A0=C2=A0 may >> > be aborted by the RSET, a new EHLO, or the QUIT command. >> > There =C2=A0=C2=A0 may be zero or more transactions in a >> > session.=C2=A0 MAIL MUST NOT be sent =C2=A0=C2=A0 if a = mail >> > transaction is already open, i.e., it should be sent only >> > =C2=A0=C2=A0 if no mail transaction had been started in = the >> > session, or if the =C2=A0=C2=A0 previous one successfully >> > concluded, or if the previous one was aborted. >> >=20 >> > =C2=A0=C2=A0 See Section 3.3. for more details. >> >=20 >> > Any opinions about the above? >>=20 >> Shouldn't the transaction be open until the _response_ to any >> of those client-end actions? >=20 > I was wondering the same thing, but on reflection I think it > is clear that nothing in the server reply can extend the scope > of the transaction. The transaction may succeed, fail, be > terminated, or lead to an error state (a rejected RSET or EHLO > presumably precludes continuing with subsequent transactions). Exactly. I suppose we could clarify further by saying that the server MUST respond to any of those commands/conditions with a 2yz code but Section 4.3 basically already says that. =20 > So termination here refers to *commands* that terminate a > transaction. The fact that the client typically awaits a > response is implicit. (Clients might not wait for a QUIT > response, and might drop a connection after a successful RSET > if despite anticipating more traffic no further messages are > queued for the peer). Actually the current text requires (or is intended to require) that clients to wait except under unusual circumstances and then (deliberately) hand-waves about the definition of "unusual". I think that just strengthens your point. So, anyone want to argue that clarification is needed for this and, if it is, that it is important enough to justify added text? If so, proposed text would be appreciated because your friendly editor thinks it is fairly clear. john From nobody Tue Jul 6 16:55:15 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7A83A045E for ; Tue, 6 Jul 2021 16:55:14 -0700 (PDT) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiLDiUbARPff for ; Tue, 6 Jul 2021 16:55:13 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 003603A07CE for ; Tue, 6 Jul 2021 16:55:12 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 92173D48E0; Tue, 6 Jul 2021 19:55:11 -0400 (EDT) Date: Tue, 6 Jul 2021 19:55:11 -0400 From: Viktor Dukhovni To: emailcore@ietf.org Message-ID: Reply-To: emailcore@ietf.org References: <5C50F3E6361F9E5AE613727B@PSB> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5C50F3E6361F9E5AE613727B@PSB> Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 06 Jul 2021 23:55:15 -0000 On Tue, Jul 06, 2021 at 07:19:38PM -0400, John C Klensin wrote: > > I was wondering the same thing, but on reflection I think it > > is clear that nothing in the server reply can extend the scope > > of the transaction. The transaction may succeed, fail, be > > terminated, or lead to an error state (a rejected RSET or EHLO > > presumably precludes continuing with subsequent transactions). > > Exactly. I suppose we could clarify further by saying that the > server MUST respond to any of those commands/conditions with a > 2yz code but Section 4.3 basically already says that. Well, not always 2yz, since ".", "RSET" or "EHLO" could fail or be refused. IIRC it is "QUIT" for which "2yz" is the only expected outcome. > > So termination here refers to *commands* that terminate a > > transaction. The fact that the client typically awaits a > > response is implicit. (Clients might not wait for a QUIT > > response, and might drop a connection after a successful RSET > > if despite anticipating more traffic no further messages are > > queued for the peer). > > Actually the current text requires (or is intended to require) > that clients to wait except under unusual circumstances and then > (deliberately) hand-waves about the definition of "unusual". I > think that just strengthens your point. FWIW, this is another one of those things where practice diverges from theory. Clients *DO* disconnect without waiting for a "QUIT" response, and this is in practice well justified. Clients also abruptly drop connections after a successful "RSET" without sending "QUIT", when e.g. a cached connection times out without new messages to send. Neither behaviour will change in, e.g., Postfix no matter what the specification says. The server must be prepared to handle lost connections, e.g. because of transport or network layer issues, and the client may from time to time elect to unilaterally close the transport. > So, anyone want to argue that clarification is needed for this > and, if it is, that it is important enough to justify added > text? If so, proposed text would be appreciated because your > friendly editor thinks it is fairly clear. I'm fine with the text re connection termination as-is. -- Viktor. From nobody Tue Jul 6 17:12:32 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5103A103A for ; Tue, 6 Jul 2021 17:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDK8pMYF4leX for ; Tue, 6 Jul 2021 17:12:26 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE2083A1039 for ; Tue, 6 Jul 2021 17:12:25 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m0vAt-000C0a-7D; Tue, 06 Jul 2021 20:12:23 -0400 Date: Tue, 06 Jul 2021 20:12:16 -0400 From: John C Klensin To: dcrocker@bbiw.net, Alexey Melnikov , emailcore@ietf.org Message-ID: In-Reply-To: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 07 Jul 2021 00:12:31 -0000 --On Tuesday, July 6, 2021 15:50 -0700 Dave Crocker wrote: > On 7/6/2021 3:45 PM, John C Klensin wrote: >> The MAIL command begins a mail transaction.=C2=A0 Once >> started, a mail transaction consists of a transaction >> beginning command, >=20 > As written, the above text is confusing and I'm not sure what > it means. >=20 > If the MAIL command begins a mail transaction, then the next > thing -- what is currently described as "a transaction > beginning command" -- takes place after the mail transaction > has begun. As indicated in various notes in the rfc5321bis draft, I've never been really happy with the convolutions there. They arose, IIR, from concern that someone might someday introduce an extension that would provide an alternative to the MAIL command (e.g., a HCTS (Here Comes he Stuff) command) and/or as a nod to SOML or SAML. Any of those presumably would start a mail transaction although naming them and giving more details than are already present would be out of the scope of 2821/5321/5321bis. In particular, while Section 2 of RFC 821 discusses mail transaction initiation only in terms of the MAIL command (just as 5321 does in different words), Section 3.4 (which defined SEND, SOML and SAML) says "used in the mail transaction instead of the MAIL command". Since we have deprecated them, that does not mean much other than this is a very old problem and that, in principle, nothing would prevent an extension that puts them back in. On the other hand, note that Appendix F.6 of RFC 5321/ 5321bis allows servers to support them and, if one does so, it MUST advertise them in the EHLO response. My conclusion is (1) Despite your confusion and my distaste for the text, the observation that there have apparently been no complaints in the last decade or two might tell us something. (2) We better go very carefully if we decide to start recasting those definitions. That said, it occurs to me that the text could probably be improved by replacing Old: The MAIL command begins a mail transaction.=C2=A0 Once started, a mail transaction consists of a transaction beginning command,... New (alternative 1): The MAIL command begins a mail transaction.=C2=A0 Once a mail transaction is thus initiated, it then consists of... ( or s/thus initiated/begun/ ) New (alternative 2): A mail transaction begins with a MAIL command and then consists of ... Neither of those is particularly friendly to future extensions that might introduce new transaction-starting commands, but, given that there have been, IIR, no serious proposals for such commands (much less adoption and deployment) since 1993, maybe it is sensible to ignore that problem and pass the burden of sorting things out onto anyone who proposes such a thing in the future. Do you feel better about either of those alternatives than about the existing text? Other suggestions? thanks, john From nobody Tue Jul 6 18:09:28 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F050C3A1251 for ; Tue, 6 Jul 2021 18:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 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.338, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u74CU1drNwas for ; Tue, 6 Jul 2021 18:09:20 -0700 (PDT) Received: from camel.birch.relay.mailchannels.net (camel.birch.relay.mailchannels.net [23.83.209.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471EB3A124F for ; Tue, 6 Jul 2021 18:09:19 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E55826421B7; Wed, 7 Jul 2021 01:09:16 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (100-96-16-95.trex-nlb.outbound.svc.cluster.local [100.96.16.95]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 766AF641C8B; Wed, 7 Jul 2021 01:09:15 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (35.45.192.35.bc.googleusercontent.com [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.16.95 (trex/6.3.3); Wed, 07 Jul 2021 01:09:16 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Turn-Trouble: 6c1d31a56247ec08_1625620156634_2264734722 X-MC-Loop-Signature: 1625620156633:799932721 X-MC-Ingress-Time: 1625620156633 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 32A0D310E1EE; Wed, 7 Jul 2021 01:09:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1625620154; bh=5U2Pd1GGbf64Rc5B1c7xsg2ma34541o0rRkbEJpA+Fk=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=cygy2yH/uPeigYZr6tS1bgcEcnw8hDm5ZJ5a5P6A1T9rvcYuLRHlAVX9hhivCJ4gT vbjq66ANZBElWnxQHHaLFb7MytWQ6d7j2ZxXvD+nGpPcCaFA/00ihOgtjw7L3wZQ8V NlTPMYNbm3yeGDwUvcA2t7yY1hzXzl6DSeBY4fpAadLSnA1/UnV8A5rdTBgvamV6cC zGwaXphqHavWJOTYKEvA4ivoB3foCvr2QwnVK6Ye9bS2PqSWR/KvL39GUPfdgrR73M H+1VmEzQ9S6tz4icDFKDtehlF22iMhAiK6cB4C8bwIWNqr217TdiUplwNJCgAJ21pJ +tclJL7AYW+DA== Reply-To: dcrocker@bbiw.net To: John C Klensin , dcrocker@bbiw.net, Alexey Melnikov , emailcore@ietf.org References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <74703549-98c2-c084-289c-b0147d274d76@dcrocker.net> Date: Tue, 6 Jul 2021 18:09:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.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 #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 07 Jul 2021 01:09:26 -0000 On 7/6/2021 5:12 PM, John C Klensin wrote: > My conclusion is (1) Despite your confusion and my distaste for > the text, the observation that there have apparently been no > complaints in the last decade or two might tell us something. > (2) We better go very carefully if we decide to start recasting > those definitions. If text makes no sense, then it makes no sense. The idea that it is in any way acceptable to retain text that makes no sense... makes no sense. The absence of prior complaints, for something like this, means very little. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 6 22:55:36 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956B23A0F22 for ; Tue, 6 Jul 2021 22:55:33 -0700 (PDT) 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 i8dVdXk261kH for ; Tue, 6 Jul 2021 22:55:29 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD693A0FE2 for ; Tue, 6 Jul 2021 22:55:28 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m10Wq-000E6h-BJ; Wed, 07 Jul 2021 01:55:24 -0400 Date: Wed, 07 Jul 2021 01:55:19 -0400 From: John C Klensin To: dcrocker@bbiw.net, Alexey Melnikov , emailcore@ietf.org Message-ID: In-Reply-To: <74703549-98c2-c084-289c-b0147d274d76@dcrocker.net> References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> <74703549-98c2-c084-289c-b0147d274d76@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 07 Jul 2021 05:55:35 -0000 Dave, Some observations (and you may want to ignore the first one)... --On Tuesday, July 6, 2021 18:09 -0700 Dave Crocker wrote: > On 7/6/2021 5:12 PM, John C Klensin wrote: >> My conclusion is (1) Despite your confusion and my distaste >> for the text, the observation that there have apparently been >> no complaints in the last decade or two might tell us >> something. (2) We better go very carefully if we decide to >> start recasting those definitions. > > If text makes no sense, then it makes no sense. The idea that > it is in any way acceptable to retain text that makes no > sense... makes no sense. > > The absence of prior complaints, for something like this, > means very little. Sure. Except that the text in question was carefully examined by a WG (a WG in which, IIR, you participated), went through WG Last Call and IETF Last Call and then through an IESG that did a good deal of nit-picking and then the RFC Editor. That creates at least a small presumption that many readers were able to deduce what the text was intended to mean, not that it "makes no sense". Certainly you are entitled to your opinion about the latter, but that history (including the absence of prior complaints), does not suggest anything nearly so absolute as a community conclusion that the text makes no sense. Could it be more clear? I think so, have said so, and suggested alternate text. Should it have been caught while YAM was active or in the subsequent years? Probably, but, at least IMO, debating that or trying to figure out not is not particularly helpful at this stage... except, again, to suggest that there is not universal agreement that the current wording "makes no sense". Finally, I did suggest some options for alternate wording. Do you have comments about either of them, or do you just find it more useful to make assertions about what does or does not make any sense? thanks, john From nobody Wed Jul 7 03:00:46 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45213A1AC6 for ; Wed, 7 Jul 2021 03:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 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.338, 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 D_idORpFdGVJ for ; Wed, 7 Jul 2021 03:00:40 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6CC3A1AC4 for ; Wed, 7 Jul 2021 03:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1625652034; d=isode.com; s=june2016; i=@isode.com; bh=Dp6b5Qc6j+8hLayM7bMd971nt8kfFEDFT1YAPZsQHyE=; 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=V2jlWAFuMcuW64dq+xrBKlk23Qd79H/cNYNjRzi3V8QHHVEe8GcTXeIEoBgjdNhMkC2OT1 /mwrwrD+eITuIT3gAWUbYdQH+VEdFTspfs537wmwDb88LqJgQ53FLQ+zbdHD/fDQV+acw+ +/2DyfZ7Ayowhve+TnWAD/Ffw6Wv9/4=; Received: from [192.168.1.222] (host5-81-100-22.range5-81.btcentralplus.com [5.81.100.22]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 7 Jul 2021 11:00:32 +0100 To: John C Klensin , emailcore@ietf.org References: From: Alexey Melnikov Message-ID: <1a1ea530-e33a-6c27-b41f-d026fb238305@isode.com> Date: Wed, 7 Jul 2021 10:59:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 07 Jul 2021 10:00:45 -0000 Hi John, On 06/07/2021 23:45, John C Klensin wrote: > --On Monday, July 5, 2021 18:24 +0100 Alexey Melnikov > wrote: > >> draft-ietf-emailcore-rfc5321bis-02 currently says: >> >> 3.3.=C2=A0 Mail Transactions >> >> =C2=A0=C2=A0 There are three steps to SMTP mail transactions.=C2=A0 The >> transaction >> =C2=A0=C2=A0 starts with a MAIL command that gives the sender >> identification.=C2=A0 (In >> =C2=A0=C2=A0 general, the MAIL command may be sent only when no mail >> transaction >> =C2=A0=C2=A0 is in progress; see Section 4.1.4.)=C2=A0 A series of one = or >> more RCPT >> =C2=A0=C2=A0 commands follows, giving the receiver information. >> Then, a DATA >> =C2=A0=C2=A0 command initiates transfer of the mail data and is >> terminated by the >> =C2=A0=C2=A0 "end of mail" data indicator, which also confirms the >> transaction. >> =C2=A0=C2=A0 Mail transactions are also terminated by the RSET command >> =C2=A0=C2=A0 (Section 4.1.1.5), the sending of an EHLO command >> (Section 3.2), or >> =C2=A0=C2=A0 the sending of a QUIT command (Section 3.8) which >> terminates both any >> =C2=A0=C2=A0 active mail transaction and the SMTP connection. >> >> 4.1.4.=C2=A0 Order of Commands >> >> =C2=A0 [...] >> >> =C2=A0=C2=A0 The MAIL command begins a mail transaction.=C2=A0 Once >> started, a mail >> =C2=A0=C2=A0 transaction consists of a transaction beginning command, >> one or more >> =C2=A0=C2=A0 RCPT commands, and a DATA command, in that order.=C2=A0 A >> mail transaction >> =C2=A0=C2=A0 may be aborted by the RSET, a new EHLO, or the QUIT >> command. There >> =C2=A0=C2=A0 may be zero or more transactions in a session.=C2=A0 MAIL >> MUST NOT be sent >> =C2=A0=C2=A0 if a mail transaction is already open, i.e., it should >> be sent only >> =C2=A0=C2=A0 if no mail transaction had been started in the session, >> or if the >> =C2=A0=C2=A0 previous one successfully concluded with a successful >> DATA command, >> =C2=A0=C2=A0 or if the previous one was aborted, e.g., with a RSET or >> new EHLO. >> >> Ticket #11 suggests that 3.3 can be improved by being more >> specific about where mail transactions begin and end. And >> section 4.1.4 has a note "comment about changing this >> convoluted discussion to talk about 'mail transaction' above." >> >> Looking at these 2 sections, I observe that 3.3 talks about >> how a transaction starts, but can be slightly improved by >> clarifying how it terminates. To that end, I propose changing >> the last sentence of the 1st paragraph of 3.3 to read: >> >> OLD: >> >> =C2=A0=C2=A0 Then, a DATA >> =C2=A0=C2=A0 command initiates transfer of the mail data and is >> terminated by the >> =C2=A0=C2=A0 "end of mail" data indicator, which also confirms the >> transaction. >> >> NEW: >> >> =C2=A0=C2=A0 Then, a DATA >> =C2=A0=C2=A0 command initiates transfer of the mail data and is >> terminated by the >> =C2=A0=C2=A0 "end of mail" data indicator, which also confirms (and >> terminates) the transaction. >> >> Basically this clarifies that "end of mail" data indicator >> always terminates the transaction. (Paragraph 2 of 3.3 is >> already clear that RSET/EHLO/QUIT also terminate the >> transaction. > This seems right to me. It probably makes things a bit better; > clearly it does not make them any worse. > >> I think the text in 4.1.4 is pretty clear, but it does contain >> some duplication in comparison to 3.3. We can either leave it >> as is or possibly shorten it to avoid duplication. >> >> Here is a strawman proposal to do the latter: >> >> The MAIL command begins a mail transaction.=C2=A0 Once started, a >> mail transaction consists of a transaction beginning command, >> one or more RCPT commands, and a DATA command, in that >> order.=C2=A0 A mail transaction may be aborted by the RSET, a new >> EHLO, or the QUIT command. There may be zero or more >> transactions in a session.=C2=A0 MAIL MUST NOT be sent if a mail >> transaction is already open, i.e., it should be sent only if >> no mail transaction had been started in the session, or if the >> previous one successfully concluded, or if the previous one >> was aborted. >> >> =C2=A0=C2=A0 See Section 3.3. for more details. >> >> Any opinions about the above? > Alternative if you (and others) want to trim and get the > redundancies out. This also improves on what is now an odd > relationship between "MUST NOT" and "should" > > New: > > The MAIL command begins a mail transaction.=C2=A0 Once > started, a mail transaction consists of a transaction > beginning command, one or more RCPT commands, and a DATA > command, in that order.=C2=A0 Mail transactions are defined > and terminated as described in Section 3.3. MAIL MUST > NOT be sent if a mail transaction is already open, i.e., > it is permitted only if no mail transaction had been > started in the session, or if the previous one > successfully concluded, or was aborted. > > I am ok with either but do think the cross-reference is useful. I like your version better, but I am happy with either. Alexey (as a participant). From nobody Wed Jul 7 03:01:47 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE3B3A1AD3 for ; Wed, 7 Jul 2021 03:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 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.338, 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 d51NsQMG_8oP for ; Wed, 7 Jul 2021 03:01:40 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id AB5963A1AD1 for ; Wed, 7 Jul 2021 03:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1625652095; d=isode.com; s=june2016; i=@isode.com; bh=G5cci6rtf3YbZImKumKhCnYBhJWRIFO9ktSW2wyk8zU=; 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=UnDcNG3b2SojYAq1rFWYeDA98pOlb4AZQatQ5cowX31Dj5v6VV2vHjC4CKwqoFmkxiGGbP h256QaoExZjArLFbXFU6xqqoivd7bgwtmqX2mvto0k4BfAzyw89YV42Y/ydsSH7m1r3ZRK fAqegZbsmtpuhfP97tZ4CdDQ3Thv8bo=; Received: from [192.168.1.222] (host5-81-100-22.range5-81.btcentralplus.com [5.81.100.22]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 7 Jul 2021 11:01:35 +0100 To: dcrocker@bbiw.net, John C Klensin , emailcore@ietf.org References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> From: Alexey Melnikov Message-ID: Date: Wed, 7 Jul 2021 11:01:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 07 Jul 2021 10:01:45 -0000 Hi Dave, On 06/07/2021 23:50, Dave Crocker wrote: > On 7/6/2021 3:45 PM, John C Klensin wrote: >> The MAIL command begins a mail transaction.=C2=A0 Once >> =C2=A0=C2=A0=C2=A0=C2=A0started, a mail transaction consists of a transac= tion >> =C2=A0=C2=A0=C2=A0=C2=A0beginning command, > > As written, the above text is confusing and I'm not sure what it means. > > If the MAIL command begins a mail transaction, then the next thing --=20 > what is currently described as "a transaction beginning command" --=20 > takes place after the mail transaction has begun. You are right, this can be made clearer. I think it is probably a=20 leftover from times when there were more than one way to initiate the=20 transaction. Best Regards, Alexey From nobody Wed Jul 7 03:16:20 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A19D3A1BE3 for ; Wed, 7 Jul 2021 03:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 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.338, 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 D2XrdE3I-aie for ; Wed, 7 Jul 2021 03:16:13 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBDC3A1BDF for ; Wed, 7 Jul 2021 03:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1625652972; d=isode.com; s=june2016; i=@isode.com; bh=i2AdrnLbWv5XZT7NNTPUi9id6E5ISyBQKIaxzYSQYPA=; 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=Yv39jLxbOJAMOmEDDCGQFflwjcabLhoC8vqZQGpmm+ngoT446qFFxzrNg3R151Yo7c2PU8 +qMjy1PQLG7dVjoPNhmqwpRVS5ZReonaY2/pU9WfnDvTUbFwYtLBWYWk9sGQ+4YqD/mPIl NscRuugCyTYRPEyralsdIvL4f3glPtQ=; Received: from [192.168.1.222] (host5-81-100-22.range5-81.btcentralplus.com [5.81.100.22]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 7 Jul 2021 11:16:12 +0100 To: John C Klensin References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> From: Alexey Melnikov Cc: dcrocker@bbiw.net, emailcore@ietf.org Message-ID: Date: Wed, 7 Jul 2021 11:16:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 07 Jul 2021 10:16:18 -0000 Hi John, On 07/07/2021 01:12, John C Klensin wrote: > --On Tuesday, July 6, 2021 15:50 -0700 Dave Crocker > wrote: > >> On 7/6/2021 3:45 PM, John C Klensin wrote: >>> The MAIL command begins a mail transaction.=C2=A0 Once >>> started, a mail transaction consists of a transaction >>> beginning command, >> As written, the above text is confusing and I'm not sure what >> it means. >> >> If the MAIL command begins a mail transaction, then the next >> thing -- what is currently described as "a transaction >> beginning command" -- takes place after the mail transaction >> has begun. > As indicated in various notes in the rfc5321bis draft, I've > never been really happy with the convolutions there. They > arose, IIR, from concern that someone might someday introduce an > extension that would provide an alternative to the MAIL command > (e.g., a HCTS (Here Comes he Stuff) command) and/or as a nod to > SOML or SAML. Any of those presumably would start a mail > transaction although naming them and giving more details than > are already present would be out of the scope of > 2821/5321/5321bis. > > In particular, while Section 2 of RFC 821 discusses mail > transaction initiation only in terms of the MAIL command (just > as 5321 does in different words), Section 3.4 (which defined > SEND, SOML and SAML) says "used in the mail transaction instead > of the MAIL command". Since we have deprecated them, that does > not mean much other than this is a very old problem and that, in > principle, nothing would prevent an extension that puts them > back in. On the other hand, note that Appendix F.6 of RFC 5321/ > 5321bis allows servers to support them and, if one does so, it > MUST advertise them in the EHLO response. > > My conclusion is (1) Despite your confusion and my distaste for > the text, the observation that there have apparently been no > complaints in the last decade or two might tell us something. > (2) We better go very carefully if we decide to start recasting > those definitions. > > That said, it occurs to me that the text could probably be > improved by replacing > > Old: > The MAIL command begins a mail transaction.=C2=A0 Once > started, a mail transaction consists of a transaction > beginning command,... > > New (alternative 1): > The MAIL command begins a mail transaction.=C2=A0 Once a > mail transaction is thus initiated, it then consists > of... > > ( or s/thus initiated/begun/ ) > =09 > New (alternative 2): > A mail transaction begins with a MAIL command and then > consists of ... I think this is an improvment and I prefer your 2nd alternative. > Neither of those is particularly friendly to future extensions > that might introduce new transaction-starting commands, but, > given that there have been, IIR, no serious proposals for such > commands (much less adoption and deployment) since 1993, maybe > it is sensible to ignore that problem and pass the burden of > sorting things out onto anyone who proposes such a thing in the > future. Fair enough. I briefly considered pointing out that extensions already change how=20 transactions are terminated (e.g. BDAT/BURL commands), so maybe this is=20 a separate ticket. But not addressing it is fine. > Do you feel better about either of those alternatives than about > the existing text? Other suggestions? > > thanks, > john > From nobody Wed Jul 7 08:45:12 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2FF3A1C90 for ; Wed, 7 Jul 2021 08:45:02 -0700 (PDT) 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 mTM3XsyDOBW3 for ; Wed, 7 Jul 2021 08:44:57 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC7B83A1C71 for ; Wed, 7 Jul 2021 08:44:57 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m19jI-000Ixh-NB; Wed, 07 Jul 2021 11:44:52 -0400 Date: Wed, 07 Jul 2021 11:44:47 -0400 From: John C Klensin To: Alexey Melnikov cc: dcrocker@bbiw.net, emailcore@ietf.org Message-ID: In-Reply-To: References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 07 Jul 2021 15:45:10 -0000 Alexey, --On Wednesday, July 7, 2021 11:16 +0100 Alexey Melnikov wrote: >... >> That said, it occurs to me that the text could probably be >> improved by replacing >>=20 >> Old: >> The MAIL command begins a mail transaction.=C2=A0 Once >> started, a mail transaction consists of a transaction >> beginning command,... >... >> New (alternative 2): >> A mail transaction begins with a MAIL command and then >> consists of ... > I think this is an improvment and I prefer your 2nd > alternative. I'm going to drop that into the working draft unless someone objects soon, noting that after having upgraded "confusing and I'm not sure what it means" to "makes no sense", Dave has not responded to the suggested alternatives. =20 >> Neither of those is particularly friendly to future = extensions >> that might introduce new transaction-starting commands, but, >> given that there have been, IIR, no serious proposals for = such >> commands (much less adoption and deployment) since 1993, = maybe >> it is sensible to ignore that problem and pass the burden of >> sorting things out onto anyone who proposes such a thing in >> the future. >=20 > Fair enough. >=20 > I briefly considered pointing out that extensions already > change how transactions are terminated (e.g. BDAT/BURL > commands), so maybe this is a separate ticket. But not > addressing it is fine. Additional suggestion to avoid additional tickets and more confusion: How about we add, two sentences to explicitly deal with those cases, =20 Old: A mail transaction may be aborted by the RSET, a new EHLO, or the QUIT command. New: A mail transaction may be aborted by the RSET, a new EHLO, or the QUIT command. SMTP extensions (see Section 2.2) may create substitutions for any of those commands or may define new ones. Their documentation is expected to be very precise about if, or how, they affect the mail transaction state. That paragraph would probably benefit from additional wordsmithing and suggestions are welcome. In particular, I think (at least right now) that text is more useful here than added to Section 2.2 although a different alternative would be to add text to Section 2.2.3 explicitly calling out changes to the transaction and/or session definitions. Or we could do both. I'm not convinced this needs a ticket and a long discussion, but I'll leave that up to you and Todd. best,=20 john From nobody Wed Jul 7 20:27:10 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697E83A0DFF for ; Wed, 7 Jul 2021 20:27:08 -0700 (PDT) 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 8xqviih9wTzP for ; Wed, 7 Jul 2021 20:27:03 -0700 (PDT) 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 3C2DB3A0DFB for ; Wed, 7 Jul 2021 20:27:03 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S14QJY1WZK00B3JX@mauve.mrochek.com> for emailcore@ietf.org; Wed, 7 Jul 2021 18:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1625709384; bh=hZ11RbUvbeDXhxMvATNbbnH0wdvgsBfpFz+zU5Iu4mc=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Oy6RGTweubn3A6enjLErGtPbiYCEdfo+pTEZXdYDOyu8GF1kQKC5DXYn+b5Q8WLZP ujN1+TM2eLK112PxnMPr5iOtBY6Woj1roSeWkPTypBbCCrHxnCfpakJThaZPM3i6WD nu8IB9t0HiICenAzI9jq3aUV36KKeVmKYVT2h8DM= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S0F3SXH38G005PTU@mauve.mrochek.com>; Wed, 7 Jul 2021 18:56:22 -0700 (PDT) Cc: Alexey Melnikov , emailcore@ietf.org, dcrocker@bbiw.net Message-id: <01S14QJWN146005PTU@mauve.mrochek.com> Date: Wed, 07 Jul 2021 18:50:28 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 07 Jul 2021 11:44:47 -0400" References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> To: John C Klensin Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 03:27:08 -0000 > Alexey, > --On Wednesday, July 7, 2021 11:16 +0100 Alexey Melnikov > wrote: > >... > >> That said, it occurs to me that the text could probably be > >> improved by replacing > >> > >> Old: > >> The MAIL command begins a mail transaction.  Once > >> started, a mail transaction consists of a transaction > >> beginning command,... > >... > >> New (alternative 2): > >> A mail transaction begins with a MAIL command and then > >> consists of ... > > I think this is an improvment and I prefer your 2nd > > alternative. > I'm going to drop that into the working draft unless someone > objects soon, noting that after having upgraded "confusing and > I'm not sure what it means" to "makes no sense", Dave has not > responded to the suggested alternatives. +1 to putting it in the draft. > >> Neither of those is particularly friendly to future extensions > >> that might introduce new transaction-starting commands, but, > >> given that there have been, IIR, no serious proposals for such > >> commands (much less adoption and deployment) since 1993, maybe > >> it is sensible to ignore that problem and pass the burden of > >> sorting things out onto anyone who proposes such a thing in > >> the future. > > > > Fair enough. > > > > I briefly considered pointing out that extensions already > > change how transactions are terminated (e.g. BDAT/BURL > > commands), so maybe this is a separate ticket. But not > > addressing it is fine. > Additional suggestion to avoid additional tickets and more > confusion: How about we add, two sentences to explicitly deal > with those cases, > Old: > A mail transaction may be aborted by the RSET, a new > EHLO, or the QUIT command. > New: > A mail transaction may be aborted by the RSET, a new > EHLO, or the QUIT command. SMTP extensions (see Section > 2.2) may create substitutions for any of those commands > or may define new ones. Their documentation is expected > to be very precise about if, or how, they affect the > mail transaction state. > That paragraph would probably benefit from additional > wordsmithing and suggestions are welcome. How about something like: A mail transaction may be aborted by the RSET, a new EHLO, or the QUIT command. SMTP extensions (see Section 2.2) may create additional commands that abort or end the transaction. More generally, any new command MUST clearly document any effect it has on the transaction state. > In particular, I > think (at least right now) that text is more useful here than > added to Section 2.2 although a different alternative would be > to add text to Section 2.2.3 explicitly calling out changes to > the transaction and/or session definitions. Or we could do > both. I'm not convinced this needs a ticket and a long > discussion, but I'll leave that up to you and Todd. it seems like we should be able to nail this down fairly easily. Ned From nobody Wed Jul 7 21:00:44 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF693A1255 for ; Wed, 7 Jul 2021 21:00:41 -0700 (PDT) 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 XPhDcCJ59rJs for ; Wed, 7 Jul 2021 21:00:37 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946A03A1251 for ; Wed, 7 Jul 2021 21:00:37 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m1LDF-000OKg-B7; Thu, 08 Jul 2021 00:00:33 -0400 Date: Thu, 08 Jul 2021 00:00:27 -0400 From: John C Klensin To: Ned Freed cc: Alexey Melnikov , emailcore@ietf.org, dcrocker@bbiw.net Message-ID: In-Reply-To: <01S14QJWN146005PTU@mauve.mrochek.com> References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> <01S14QJWN146005PTU@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 04:00:42 -0000 --On Wednesday, July 7, 2021 18:50 -0700 Ned Freed wrote: >... >> Additional suggestion to avoid additional tickets and more >> confusion: How about we add, two sentences to explicitly deal >> with those cases, > >> Old: >> A mail transaction may be aborted by the RSET, a new >> EHLO, or the QUIT command. > >> New: >> A mail transaction may be aborted by the RSET, a new >> EHLO, or the QUIT command. SMTP extensions (see Section >> 2.2) may create substitutions for any of those commands >> or may define new ones. Their documentation is expected >> to be very precise about if, or how, they affect the >> mail transaction state. > >> That paragraph would probably benefit from additional >> wordsmithing and suggestions are welcome. > > How about something like: > > A mail transaction may be aborted by the RSET, a new > EHLO, or the QUIT command. SMTP extensions (see Section > 2.2) may create additional commands that abort or > end the transaction. > > More generally, any new command MUST clearly document any > effect it has on the transaction state. I like it. Clearer and more succinct than my fussy-headed first cut. Copied into the working draft. I hope to get that draft up Friday or Saturday at the latest rather than waiting for the cutoff, so, if anyone objects, please do so soon if you want your comments reflected in the next I-D. >> In particular, I >> think (at least right now) that text is more useful here than >> added to Section 2.2 although a different alternative would be >> to add text to Section 2.2.3 explicitly calling out changes >> to the transaction and/or session definitions. Or we could do >> both. I'm not convinced this needs a ticket and a long >> discussion, but I'll leave that up to you and Todd. > > it seems like we should be able to nail this down fairly > easily. Concur. My current working editor's hypothesis is is to do this and not mess with 2.2.3 other than being sure there are adequate cross references. Other ideas welcoem. thanks, john From nobody Wed Jul 7 21:03:43 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7799A3A129A for ; Wed, 7 Jul 2021 21:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maVEhr3EAxsV for ; Wed, 7 Jul 2021 21:03:37 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D8D63A1290 for ; Wed, 7 Jul 2021 21:03:37 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m1LGB-000ONR-QL for emailcore@ietf.org; Thu, 08 Jul 2021 00:03:35 -0400 Date: Thu, 08 Jul 2021 00:03:29 -0400 From: John C Klensin To: emailcore@ietf.org Message-ID: <3671BE36CC3C4816D351883B@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] 5321bis referencing glitchwrt, RFCx 3463 and Appendix G.8 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 04:03:41 -0000 Hi, This is probably a small issue, but one to which we should probably pay attention well before we enter the home stretch. RFC 5321 has many citations of RFC 3463 (Enhanced Status Codes), which is listed as Informational. However, in the run-up to producing that document in YAM, many constructions that used to say that XYZ is preferred over some other option were changed to say that XYZ SHOULD be used. I think that use of 3463 in contexts that specify its use in a SHOULD make the reference normative. I will make that change unless someone objects, but it raises the importance of the discussion in G.8 because, with that move, we either need to get 3463 to Internet Standard (it is almost certainly deployed widely enough and shown to be interoperable) or we need to attach a downref disclaimer to the Last Call announcement for 5321bis when we get that far. I have slightly modified G.8 in the working draft so we don't lose track of this. john From nobody Wed Jul 7 21:19:19 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D571F3A07D6 for ; Wed, 7 Jul 2021 21:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 SuOfLikR6Jej for ; Wed, 7 Jul 2021 21:19:12 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 F0F203A07D3 for ; Wed, 7 Jul 2021 21:19:11 -0700 (PDT) Received: from smtpclient.apple (unknown [192.168.1.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 556C0D58E7 for ; Thu, 8 Jul 2021 00:19:10 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Viktor Dukhovni In-Reply-To: <3671BE36CC3C4816D351883B@PSB> Date: Thu, 8 Jul 2021 00:19:10 -0400 Content-Transfer-Encoding: 7bit Reply-To: emailcore@ietf.org Message-Id: <191A5254-41C5-486F-8B7F-34D40B69CAFC@dukhovni.org> References: <3671BE36CC3C4816D351883B@PSB> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Emailcore] 5321bis referencing glitchwrt, RFCx 3463 and Appendix G.8 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 04:19:17 -0000 > On 8 Jul 2021, at 12:03 am, John C Klensin wrote: > > RFC 5321 has many citations of RFC 3463 (Enhanced Status Codes), > which is listed as Informational. That's not what I see: https://datatracker.ietf.org/doc/html/rfc3463 ------- From: draft-vaudreuil-1893bis-03 Draft Standard Updated by: 3886, 4468, 4865, 4954, 5248 Errata exist Network Working Group G. Vaudreuil Request for Comments: 3463 Lucent Technologies Obsoletes: 1893 January 2003 Category: Standards Track Enhanced Mail System Status Codes ------- I've always treated it as normative, and the datatracker concurs. -- Viktor. From nobody Thu Jul 8 05:42:14 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A273A15C2 for ; Thu, 8 Jul 2021 05:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 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.338, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 OyfJ4RWNfjCC for ; Thu, 8 Jul 2021 05:42:08 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 501F13A15C1 for ; Thu, 8 Jul 2021 05:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1625748127; d=isode.com; s=june2016; i=@isode.com; bh=RibEwnrI1wv9IG0Mw3gLJs8nYeKcU7QG+lrc3uyVv/g=; 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=OeAPVKvJ6N/T5PXWemPyZtZhEEHx3oPlkNiZESXuDaahgC1SzRP/eetJpnDdyw/UQycs6d NDxj0TySmcJmySDG9dIrR/IEd1o1pM7dpa4RyuJ5kMHSzH6GBm0OUeQIjwQuY3BW4BCY72 nFHyqplX57w44yf0Q/x3wVMC6EM3mUc=; Received: from [192.168.1.222] (host5-81-100-22.range5-81.btcentralplus.com [5.81.100.22]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 8 Jul 2021 13:42:07 +0100 To: John C Klensin , Ned Freed Cc: emailcore@ietf.org, dcrocker@bbiw.net References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> <01S14QJWN146005PTU@mauve.mrochek.com> From: Alexey Melnikov Message-ID: Date: Thu, 8 Jul 2021 13:41:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 12:42:13 -0000 On 08/07/2021 05:00, John C Klensin wrote: > --On Wednesday, July 7, 2021 18:50 -0700 Ned Freed > wrote: > >> ... >>> Additional suggestion to avoid additional tickets and more >>> confusion: How about we add, two sentences to explicitly deal >>> with those cases, >>> Old: >>> A mail transaction may be aborted by the RSET, a new >>> EHLO, or the QUIT command. >>> New: >>> A mail transaction may be aborted by the RSET, a new >>> EHLO, or the QUIT command. SMTP extensions (see Section >>> 2.2) may create substitutions for any of those commands >>> or may define new ones. Their documentation is expected >>> to be very precise about if, or how, they affect the >>> mail transaction state. >>> That paragraph would probably benefit from additional >>> wordsmithing and suggestions are welcome. >> How about something like: >> >> A mail transaction may be aborted by the RSET, a new >> EHLO, or the QUIT command. SMTP extensions (see Section >> 2.2) may create additional commands that abort or >> end the transaction. >> >> More generally, any new command MUST clearly document any >> effect it has on the transaction state. > I like it. Clearer and more succinct than my fussy-headed first > cut. Copied into the working draft. +1. > I hope to get that draft up Friday or Saturday at the latest > rather than waiting for the cutoff, so, if anyone objects, > please do so soon if you want your comments reflected in the > next I-D. > >>> In particular, I >>> think (at least right now) that text is more useful here than >>> added to Section 2.2 although a different alternative would be >>> to add text to Section 2.2.3 explicitly calling out changes >>> to the transaction and/or session definitions. Or we could do >>> both. I'm not convinced this needs a ticket and a long >>> discussion, but I'll leave that up to you and Todd. >> it seems like we should be able to nail this down fairly >> easily. > Concur. My current working editor's hypothesis is is to do this > and not mess with 2.2.3 other than being sure there are adequate > cross references. Other ideas welcoem. Sounds like a good plan to me. From nobody Thu Jul 8 05:55:24 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762793A16FF for ; Thu, 8 Jul 2021 05:55:23 -0700 (PDT) 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 Ho1LUn7MPTFH for ; Thu, 8 Jul 2021 05:55:19 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E65603A16F9 for ; Thu, 8 Jul 2021 05:55:18 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m1TYj-0001lq-5U for emailcore@ietf.org; Thu, 08 Jul 2021 08:55:17 -0400 Date: Thu, 08 Jul 2021 08:55:11 -0400 From: John C Klensin To: emailcore@ietf.org Message-ID: In-Reply-To: <191A5254-41C5-486F-8B7F-34D40B69CAFC@dukhovni.org> References: <3671BE36CC3C4816D351883B@PSB> <191A5254-41C5-486F-8B7F-34D40B69CAFC@dukhovni.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] 5321bis referencing glitchwrt, RFCx 3463 and Appendix G.8 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 12:55:23 -0000 Sorry, was having a low-vision night. Trying again: s/ glitchwrt, RFCx 3463/ enhanced status codes, RFC 3463/ s/Informational/Draft Standard/ --On Thursday, July 8, 2021 00:19 -0400 Viktor Dukhovni wrote: >> On 8 Jul 2021, at 12:03 am, John C Klensin >> wrote: >> >> RFC 5321 has many citations of RFC 3463 (Enhanced Status >> Codes), which is listed as Informational. > > That's not what I see: > https://datatracker.ietf.org/doc/html/rfc3463 From nobody Thu Jul 8 07:41:26 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79773A1FF0 for ; Thu, 8 Jul 2021 07:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 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.338, 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 z9Sxa-1PgtHs for ; Thu, 8 Jul 2021 07:41:18 -0700 (PDT) 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 F058D3A1FEE for ; Thu, 8 Jul 2021 07:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1625755272; bh=JGmoak8YJjvvnnU3m7nvilLHOZTm0G6/bYzsPjJerDU=; l=844; h=To:References:From:Date:In-Reply-To; b=B/pZ7cJhm9TmbXbB8D20Gyw9jr1vXdio11vdwd3ybvVDh5X4W5hWZtXgapK1BBV/Z gnzyumAZTAOORZBNVJwCIvXBLJIL/BkmWAsVEMvHcDyYi1G4MTvChSrNMBPinyklJ/ 8e5SG7NtCIWJHbccDVmx2wzoUAINZ1DdRHyDVDTGyGa16lo/Iyghy2kPo0UeI 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 00000000005DC03D.0000000060E70E88.00002CAA; Thu, 08 Jul 2021 16:41:12 +0200 To: John C Klensin , emailcore@ietf.org References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> <01S14QJWN146005PTU@mauve.mrochek.com> From: Alessandro Vesely Message-ID: Date: Thu, 8 Jul 2021 16:41:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.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 #11: G.7.4. Possible clarification about mail transactions and transaction state X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 14:41:24 -0000 On Thu 08/Jul/2021 14:41:56 +0200 Alexey Melnikov wrote: > On 08/07/2021 05:00, John C Klensin wrote: >> --On Wednesday, July 7, 2021 18:50 -0700 Ned Freed >>> How about something like: >>> >>>       A mail transaction may be aborted by the RSET, a new >>>       EHLO, or the QUIT command. SMTP extensions (see Section >>>       2.2) may create additional commands that abort or >>>          end the transaction. Well, since that mentions aborting and ending the transaction, why don't they also mention starting it? >>>     More generally, any new command MUST clearly document any >>>        effect it has on the transaction state. >> I like it.  Clearer and more succinct than my fussy-headed first >> cut. Copied into the working draft. I guess I'm too late... Best Ale -- From nobody Thu Jul 8 08:09:50 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B633A2201 for ; Thu, 8 Jul 2021 08:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 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.338, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhJ4EbU8ehdC for ; Thu, 8 Jul 2021 08:09:44 -0700 (PDT) Received: from cyan.elm.relay.mailchannels.net (cyan.elm.relay.mailchannels.net [23.83.212.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1168C3A21F8 for ; Thu, 8 Jul 2021 08:09:42 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 8EBF4922FFA; Thu, 8 Jul 2021 15:09:38 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (100-96-18-103.trex-nlb.outbound.svc.cluster.local [100.96.18.103]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 3FDAF92307C; Thu, 8 Jul 2021 15:09:37 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.18.103 (trex/6.3.3); Thu, 08 Jul 2021 15:09:38 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Battle-Hook: 4e6d0a740b1c74b5_1625756977698_2579031122 X-MC-Loop-Signature: 1625756977698:2596299892 X-MC-Ingress-Time: 1625756977698 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 55784110F425; Thu, 8 Jul 2021 15:09:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1625756976; bh=BbvCyzzy9TqU15CdoEJSD4HqM3JZaYW9C5+oV8zQsO4=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=Y2h2LJNxancdHtTckMm2lMPlX52fC0MUvVCh+s2Vo+TKYadmZqv6Xekrx8oPiXYGb CGHYPJZRWxzJaf48KWynBhV0ilX9Dx91N1QXgIkUDC9IpBcP7NUJcS011Mg9bhzxtP eQngPav737wsmoNVNS1doULZ76J53M0aL32xVxdSpmqDIqFwWbNisNFRPqewFpKOiV MH/9GJ/QgNM5D6pNOpuncZSPE4OiX9untshhQD9yCKvh6uN3mIRltI2dj/6uHEQvlM haBRKS+7BETkY4hCirsdiA9igKm9WTtrGYLxq5dB74sPGJctgcE83Pmf+Oll126XlI UyYtUSbJtSFLw== Reply-To: dcrocker@bbiw.net To: Alessandro Vesely , John C Klensin , emailcore@ietf.org References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> <01S14QJWN146005PTU@mauve.mrochek.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <6744a11f-ca83-f824-838d-189c21076d5e@dcrocker.net> Date: Thu, 8 Jul 2021 08:09:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.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 #11: G.7.4. Possible clarification about mail transactions and transaction state X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 15:09:50 -0000 On 7/8/2021 7:41 AM, Alessandro Vesely wrote: > On Thu 08/Jul/2021 14:41:56 +0200 Alexey Melnikov wrote: >> On 08/07/2021 05:00, John C Klensin wrote: >>> --On Wednesday, July 7, 2021 18:50 -0700 Ned Freed >>>> How about something like: >>>> >>>>       A mail transaction may be aborted by the RSET, a new >>>>       EHLO, or the QUIT command. SMTP extensions (see Section >>>>       2.2) may create additional commands that abort or >>>>          end the transaction. Hmm. Nevermind the usual hassle about using 'may' in a non-normative way, it's simple English meaning introduces ambiguity, since it implies that the transaction might /not/ be aborted. More direct and clearer: Receipt of an RSET, a QUIT, or a new EHLO terminates the current mail transaction. The second sentence is a classic non-specification that purports to be a specification. It's essentially giving permission for a hypothetical, as if the permission were necessary and useful. It is neither. Future specifications will do whatever they do. Whether they are 'legal' will depend upon what the community decides at the time. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jul 8 08:41:32 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D063A24E6 for ; Thu, 8 Jul 2021 08:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 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.338, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WybkuDMXXx-q for ; Thu, 8 Jul 2021 08:41:19 -0700 (PDT) Received: from cross.elm.relay.mailchannels.net (cross.elm.relay.mailchannels.net [23.83.212.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5EF03A24E5 for ; Thu, 8 Jul 2021 08:41:18 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 1F71E362C11; Thu, 8 Jul 2021 15:41:17 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (100-98-55-150.trex.outbound.svc.cluster.local [100.98.55.150]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 46482362332; Thu, 8 Jul 2021 15:41:16 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (35.45.192.35.bc.googleusercontent.com [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.98.55.150 (trex/6.3.3); Thu, 08 Jul 2021 15:41:17 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Obese-Occur: 7de7d2ab1c064767_1625758876913_48530654 X-MC-Loop-Signature: 1625758876913:1511059894 X-MC-Ingress-Time: 1625758876913 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 3B74430B5567; Thu, 8 Jul 2021 15:41:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1625758875; bh=fkE/fwxCj1QbSqVJ50BGQlSFC3ie4Qdgn8fQYWRr2Kg=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=jO/zrHr3780iL7FwZ+4X7AiezMnZyTneiFUvbxVfmaubBpslkpyYqKdajkTV9GCe5 psdplNGWx/i7vQewe0Y0nPqAwyhqpqZWyeYkraAMCJdy5cryuUN6OlHKdcwc0yjQKq DALhhrb+u4Q0EulUFsh7fwwtgPCENzEfrqHsFWekaFAnjRxrF9R9FmWvL3o8c/zBZp 8kYNTHY7P7b1ZQzhX9RN9uVmnp/VBlgps1DJkz2Mlwx3MU+O3EoAjLs3iqNuTW/MS4 +bWk22URgMdXHO+gJNTn/VOijkPH2PFKFzw8J3zCA72G/PX2EApbd17MEnGmqTak41 BlzCwueF00MHg== Reply-To: dcrocker@bbiw.net To: Ned Freed Cc: Alessandro Vesely , John C Klensin , emailcore@ietf.org References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> <01S14QJWN146005PTU@mauve.mrochek.com> <6744a11f-ca83-f824-838d-189c21076d5e@dcrocker.net> <01S15ISYGJ00005PTU@mauve.mrochek.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <8bdd2b20-c1da-119a-06f4-76a6bdb44897@dcrocker.net> Date: Thu, 8 Jul 2021 08:41:11 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <01S15ISYGJ00005PTU@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 #11: G.7.4. Possible clarification about mail transactions and transaction state X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 15:41:30 -0000 On 7/8/2021 8:15 AM, Ned Freed wrote: >> On 7/8/2021 7:41 AM, Alessandro Vesely wrote: >> > On Thu 08/Jul/2021 14:41:56 +0200 Alexey Melnikov wrote: >> >> On 08/07/2021 05:00, John C Klensin wrote: >> >>> --On Wednesday, July 7, 2021 18:50 -0700 Ned Freed >> >>>> How about something like: >> >>>> >> >>>>       A mail transaction may be aborted by the RSET, a new >> >>>>       EHLO, or the QUIT command. SMTP extensions (see Section >> >>>>       2.2) may create additional commands that abort or >> >>>>          end the transaction. > >> Hmm.  Nevermind the usual hassle about using 'may' in a non-normative >> way, it's simple English meaning introduces ambiguity, since it implies >> that the transaction might /not/ be aborted. > >> More direct and clearer: > >>       Receipt of an RSET, a QUIT, or a new EHLO terminates the current >>       mail transaction. > > I have no problem with this, although I'm skeptical as to the claim of > lack of > clarity of the original. > >> The second sentence is a classic non-specification that purports to be a >> specification.  It's essentially giving permission for a hypothetical, >> as if the permission were necessary and useful.  It is neither. > > Strongly disagree. The point of saying this is to tell implementors that > this > list of commands that may terminate a transaction is not complete, and they > need to plan for that eventuality when they code. 1. Saying something akin to your language is more direct and clear than the existing language. If it is really felt to be that important to tell implementers that things can change with future specification, then: The list of actions that can terminate a mail transaction is extensible and subject to expansion with future specifications. > > Decades of experience with implementors getting this sort of thing wrong > and > then saying "nothing in the specification said this was possible" says this > *is* useful information. 2. Do we have any evidence, over 50 years of protocol specification, that such guidance has useful effect on the bulk of implementers? I suspect not, but would be delighted to hear otherwise. Yes they get it wrong, but that's different from saying we have any hope of getting them to do better with bits of language like this. As for their using the excuse the cite, they will always find an excuse. Trying to write specifications that anticipate every hypothetical implementation design error is a lost cause. > >> Future specifications will do whatever they do.  Whether they are >> 'legal' will depend upon what the community decides at the time. > > True but irrelevant. The purpose of the text is not to give permission, > it's to > remind people of a possibility. Of course at this point we're lucky if > implementors even bother to get a copy of the specification, let alone > read it, > but that's not an excuse to fail to make the point. I suspect it would then be far more effective to show a state diagram, with extensibility made explicit. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jul 8 08:55:29 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C013A25DB for ; Thu, 8 Jul 2021 08:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=fjxFwv3b; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Te/pPQgY 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 fldN5EyXO5am for ; Thu, 8 Jul 2021 08:55:22 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F313A25D6 for ; Thu, 8 Jul 2021 08:55:21 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id B9C3B320091F; Thu, 8 Jul 2021 11:55:19 -0400 (EDT) Received: from imap42 ([10.202.2.92]) by compute6.internal (MEProxy); Thu, 08 Jul 2021 11:55:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=NRbZo ZA+hSuP50hiYHx3XD5SzXZwL+U7kWRHofBmnHg=; b=fjxFwv3bEPUGJhYros4Xw iNEteXbgxCz7rRgyM0IpkqdxVorjd6/jqaZPhl7tteehjzsDyMx8ZOLycaKwAgro 3Qs46HPLCQ3Mrh29gCIQqXN/JvlLvLlUXB7jav8GFPOCr/rDiePTQi3BfqDs9MxZ pI9s4Rcl5hHOPIFjs9V25J5+DSfYpD/fCXn1buv0hNUHgcXsn/8CcV6OFO5ZjmaH xPzVuh2NSdEtkr4t1CSCNtyGHGdxVTT723DofVHIUCs6SKAuxOnpcqGjXQ5tW//R xyiwP7Nlsz+AXeiQkCivZEpJSgdBdxIhj/naBlltY2xJLgCMtIvql30oTDGni+Jc w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=NRbZoZA+hSuP50hiYHx3XD5SzXZwL+U7kWRHofBmn Hg=; b=Te/pPQgYcjN77CwWKZIPCtLNEyYgxnfOeMV1FBb3l1UiCctRpUGIEA41n l7DWyMKvvAXAajObqzuiuw7LovXHbO1pj1drqjK73I38XRLC9hu/UsXVWIcvhvjv tMigSRZyThoHGgUdb6u/zDrjFGWJvNjx66UQbziEj/n8wRxquUvlZ+Ererhs5HXV Cl8GiqcG7ySyQZ6dBiik9JeXNYDdu8CopX8eD9WDREs+1fQGYwB+OTQqZ6NTfu3B oTJkHxlhGdl6ynrCcu77XgxrBSx1E3RODIVyWyHxJ8LnLwdfAudHD/qv0DEAgXFV YyVsKyqKCAoAYPjgYPWNjszs+v7yw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrtdeggdelvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuggftrfgrthhtvghrnhepleeiffelueeufeekleejfeeiheegjedtvddtudff ueefveevfedtfeekueduveffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7B4632180062; Thu, 8 Jul 2021 11:55:18 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-531-g1160beca77-fm-20210705.001-g1160beca Mime-Version: 1.0 Message-Id: <4577662a-b930-40cb-97a3-d626334472b7@www.fastmail.com> In-Reply-To: <6744a11f-ca83-f824-838d-189c21076d5e@dcrocker.net> References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> <01S14QJWN146005PTU@mauve.mrochek.com> <6744a11f-ca83-f824-838d-189c21076d5e@dcrocker.net> Date: Thu, 08 Jul 2021 16:54:58 +0100 From: "Alexey Melnikov" To: "Dave Crocker" , "Alessandro Vesely" , "John C Klensin" , emailcore@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] =?utf-8?q?Ticket_=2311=3A_G=2E7=2E4=2E_Possible_clar?= =?utf-8?q?ification_about_mail_transactions_and_transaction_state?= X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 15:55:28 -0000 On Thu, Jul 8, 2021, at 4:09 PM, Dave Crocker wrote: > On 7/8/2021 7:41 AM, Alessandro Vesely wrote: > > On Thu 08/Jul/2021 14:41:56 +0200 Alexey Melnikov wrote: > >> On 08/07/2021 05:00, John C Klensin wrote: > >>> --On Wednesday, July 7, 2021 18:50 -0700 Ned Freed > >>>> How about something like: > >>>> > >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A mail transaction may be aborted = by the RSET, a new > >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EHLO, or the QUIT command. SMTP ex= tensions (see Section > >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.2) may create additional command= s that abort or > >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 end the transact= ion. >=20 > Hmm. Nevermind the usual hassle about using 'may' in a non-normative=20= > way, it's simple English meaning introduces ambiguity, since it implie= s=20 > that the transaction might /not/ be aborted. >=20 > More direct and clearer: >=20 > Receipt of an RSET, a QUIT, or a new EHLO terminates the current= > mail transaction. Yes, this is better. > The second sentence is a classic non-specification that purports to be= a=20 > specification. It's essentially giving permission for a hypothetical,= =20 > as if the permission were necessary and useful. It is neither. Actually, I disagree, as we have existing extensions that can end transa= ctions (BDAT/BURL). So pointing out that this should be considered by re= aders of the base spec is a good thing. > Future specifications will do whatever they do. Whether they are=20 > 'legal' will depend upon what the community decides at the time. Best Regards, Alexey From nobody Thu Jul 8 09:01:44 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BB83A2675 for ; Thu, 8 Jul 2021 09:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 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.338, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7j-1hiKjnsDg for ; Thu, 8 Jul 2021 09:01:31 -0700 (PDT) Received: from purple.birch.relay.mailchannels.net (purple.birch.relay.mailchannels.net [23.83.209.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83683A2684 for ; Thu, 8 Jul 2021 09:01:30 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 6B35218263A; Thu, 8 Jul 2021 16:01:27 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (100-96-16-95.trex-nlb.outbound.svc.cluster.local [100.96.16.95]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 6A96A182BFA; Thu, 8 Jul 2021 16:01:26 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (35.45.192.35.bc.googleusercontent.com [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.16.95 (trex/6.3.3); Thu, 08 Jul 2021 16:01:27 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Macabre-Bottle: 6e38758f087f6cef_1625760087033_4091143125 X-MC-Loop-Signature: 1625760087033:157369573 X-MC-Ingress-Time: 1625760087033 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 2023930B110C; Thu, 8 Jul 2021 16:01:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1625760085; bh=Kntwt3f31IGSDidDYf3mcqh6ntxGw6J1g8GH8CeI7X0=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=NUFTSjW0SCIh3hIByno78Dah/Dyu0k5FQd1N4d4y3Px71Iu856k2ok8BbuW6CsSns meBw7uXd0R9cKT0CMKzo6MOjlCJbYKaRAW2w73aJRN1jrsT176beaHsnyRAfCiDPc5 TzbfdJrw71rlnmIGB4JA7CGNscALrixPk8B0XyZP630BavKdKvkWS3jeA3vyERLWYy NAMtLCo4PMFJreIZ3Da9Q4/pXh7jN++PJMg7mTjUnh4nhsVvzVM6qWrsZ0P/XWbB58 I5q6nHvOyoxBrgpSCT4OR9qCZKIEEyJiiBC5Y3NqIx/5TAvqMSmQvpuTxSLFGa/13A bKl+lgHYYwzjg== Reply-To: dcrocker@bbiw.net To: Alexey Melnikov , Dave Crocker , Alessandro Vesely , John C Klensin , emailcore@ietf.org References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> <01S14QJWN146005PTU@mauve.mrochek.com> <6744a11f-ca83-f824-838d-189c21076d5e@dcrocker.net> <4577662a-b930-40cb-97a3-d626334472b7@www.fastmail.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Thu, 8 Jul 2021 09:01:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <4577662a-b930-40cb-97a3-d626334472b7@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 16:01:43 -0000 On 7/8/2021 8:54 AM, Alexey Melnikov wrote: >>>>>> A mail transaction may be aborted by the RSET, a new >>>>>>       EHLO, or the QUIT command. SMTP extensions (see Section >>>>>>       2.2) may create additional commands that abort or >>>>>>          end the transaction. ... >> The second sentence is a classic non-specification that purports to be a >> specification. It's essentially giving permission for a hypothetical, >> as if the permission were necessary and useful. It is neither. > Actually, I disagree, as we have existing extensions that can end transactions (BDAT/BURL). So pointing out that this should be considered by readers of the base spec is a good thing. Ahh, yeah, I missed that completely. But I still think the proposed sentence does not serve the intended goal sufficiently. Perhaps: The list of actions that terminate a mail transactions is extensible; it currently includes some SMTP extensions and might be expanded by later extensions. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jul 8 09:11:17 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2A93A2703 for ; Thu, 8 Jul 2021 09:11:09 -0700 (PDT) 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 eLzwx6WAC2PH for ; Thu, 8 Jul 2021 09:11:05 -0700 (PDT) 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 DAD1B3A273D for ; Thu, 8 Jul 2021 09:11:04 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S15K7YFD0000GGU3@mauve.mrochek.com> for emailcore@ietf.org; Thu, 8 Jul 2021 09:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1625760344; bh=rsEksp61ou+360JJmFpDB0CoeXwlUiuICP0DhwuTjUU=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=pNe2R6BHD4wLqzfbCPKihfaTBDQMj4NIwh0ZzKwMnCUCE82TIrNmLfeFwk0YpE6nZ rdr0cKRBOSQ2OUOyBqdOVTTJKdh57trPhrZmIo1voWcO1HCgdCqhB1WSA5eBxhW8eE mTTnuBCuNMH/o/hfojUpwA18YuOkPechHrWXYiGI= 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 <01S0F3SXH38G005PTU@mauve.mrochek.com>; Thu, 8 Jul 2021 09:05:40 -0700 (PDT) Cc: Ned Freed , emailcore@ietf.org, John C Klensin , Alessandro Vesely Message-id: <01S15K7VIEC2005PTU@mauve.mrochek.com> Date: Thu, 08 Jul 2021 08:51:00 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 08 Jul 2021 08:41:11 -0700" <8bdd2b20-c1da-119a-06f4-76a6bdb44897@dcrocker.net> References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> <01S14QJWN146005PTU@mauve.mrochek.com> <6744a11f-ca83-f824-838d-189c21076d5e@dcrocker.net> <01S15ISYGJ00005PTU@mauve.mrochek.com> <8bdd2b20-c1da-119a-06f4-76a6bdb44897@dcrocker.net> To: Dave Crocker Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 16:11:16 -0000 > On 7/8/2021 8:15 AM, Ned Freed wrote: > >> On 7/8/2021 7:41 AM, Alessandro Vesely wrote: > >> > On Thu 08/Jul/2021 14:41:56 +0200 Alexey Melnikov wrote: > >> >> On 08/07/2021 05:00, John C Klensin wrote: > >> >>> --On Wednesday, July 7, 2021 18:50 -0700 Ned Freed > >> >>>> How about something like: > >> >>>> > >> >>>>       A mail transaction may be aborted by the RSET, a new > >> >>>>       EHLO, or the QUIT command. SMTP extensions (see Section > >> >>>>       2.2) may create additional commands that abort or > >> >>>>          end the transaction. > > > >> Hmm.  Nevermind the usual hassle about using 'may' in a non-normative > >> way, it's simple English meaning introduces ambiguity, since it implies > >> that the transaction might /not/ be aborted. > > > >> More direct and clearer: > > > >>       Receipt of an RSET, a QUIT, or a new EHLO terminates the current > >>       mail transaction. > > > > I have no problem with this, although I'm skeptical as to the claim of > > lack of > > clarity of the original. > > > >> The second sentence is a classic non-specification that purports to be a > >> specification.  It's essentially giving permission for a hypothetical, > >> as if the permission were necessary and useful.  It is neither. > > > > Strongly disagree. The point of saying this is to tell implementors that > > this > > list of commands that may terminate a transaction is not complete, and they > > need to plan for that eventuality when they code. > 1. Saying something akin to your language is more direct and clear than > the existing language. If it is really felt to be that important to > tell implementers that things can change with future specification, then: > The list of actions that can terminate a mail transaction is > extensible and subject to expansion with future specifications. > > > > Decades of experience with implementors getting this sort of thing wrong > > and > > then saying "nothing in the specification said this was possible" says this > > *is* useful information. > 2. Do we have any evidence, over 50 years of protocol specification, > that such guidance has useful effect on the bulk of implementers? MIME has a lot of such notes. Feedback on those has been uniformly positive. To the extent there has been negative feedback, it's been to say we needed more of them. I myself find such notes quite useful - they have saved me from making invalid simplifying assumptions on more than one occasion. > I > suspect not, but would be delighted to hear otherwise. Yes they get it > wrong, but that's different from saying we have any hope of getting them > to do better with bits of language like this. As for their using the > excuse the cite, they will always find an excuse. Trying to write > specifications that anticipate every hypothetical implementation design > error is a lost cause. Yes, but there's a difference between trying to list every eventuality and trying to hit the really high points. This is a really high point. > > > >> Future specifications will do whatever they do.  Whether they are > >> 'legal' will depend upon what the community decides at the time. > > > > True but irrelevant. The purpose of the text is not to give permission, > > it's to > > remind people of a possibility. Of course at this point we're lucky if > > implementors even bother to get a copy of the specification, let alone > > read it, > > but that's not an excuse to fail to make the point. > I suspect it would then be far more effective to show a state diagram, > with extensibility made explicit. As luck would have it, I recently stumbled across an SMTP state diagram that I drew many years ago when this idea occurred to me. It's a lot more complicated than you'd suspect, so much so it's ability to inform is limited. This is true even when you limit things to the transaction part of the protocol. And representing extensibility in such a diagram means either adding additional boxes or adding text to existing boxes. Neither works very well IME. Ned From nobody Thu Jul 8 09:18:18 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFE33A271E for ; Thu, 8 Jul 2021 09:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=xXNkw7PN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LVRDmLEK 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 7xKbP5hBcZwg for ; Thu, 8 Jul 2021 09:18:11 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E07B3A271F for ; Thu, 8 Jul 2021 09:18:11 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 7EC94320090D; Thu, 8 Jul 2021 12:18:08 -0400 (EDT) Received: from imap42 ([10.202.2.92]) by compute6.internal (MEProxy); Thu, 08 Jul 2021 12:18:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=kMWCf g4d93sNVEhr4GU0ekWuWDTb6RKrhtZ2h5Jh7jc=; b=xXNkw7PNCfIYajS/A6u6n gMtTtwDLnHG+e65gr7mJTq9pEWVNotPb7qL/FHHCFVgU1Woj+YTKzktAPQszjZ97 oGwAT6xfWkB/ZtxBM42R2+t7fa68h3VwajvfkV4ZrMTuJnl/K43Oml771HRLg3xN tvchsLwq+dmXQYQG4cW1KsPZO3ebzoV8+qZxV9DFIDyjuk5jt0UYZl9i6QHrOgbO /PVylrf5h08DnYO7rvx7cHYYzQqCj/1huSlC5/ZE4BSt1ANC6ocgcndSw3AJSNbj 6xR2HO6fjHDKqx81bmHAdx+KfFlhZ8nq1KpSWXmlMAae/Olx2agxbMD9yeVG9rLg Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=kMWCfg4d93sNVEhr4GU0ekWuWDTb6RKrhtZ2h5Jh7 jc=; b=LVRDmLEKMg7SzBFnwP+CAeA3Dkce4NSZwy4gtxKZYdNMydpK1vsk8fsnc MDPq9Wx8lNGB95ooSZ70vHLjd7O7ki5vGYH/F+s1EJLlff1QthymAyW6dV2iix/t cTtt5yVrPmJzNXne9EO+5dMR2XNTUcTiC4n6XvtOMT9+zhOPRO1AKb9oBYS0nzEp njtCc33sQxjGJpKgS0o3EYUE9MQ+PxIZS+ZqBT0rv6Cuh/miK4vVaEuxUpPJZDcT 9rtoqovweLDs+yeX2XBRMcEjhX1phH1TX1847ySk50Fe/QSeWZn55v1fwWFAAdlg ci1o6B3PUAoPLM39ePAXhZaC/C/pw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrtdeggdeljecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuggftrfgrthhtvghrnhepleeiffelueeufeekleejfeeiheegjedtvddtudff ueefveevfedtfeekueduveffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A85812180062; Thu, 8 Jul 2021 12:18:07 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-531-g1160beca77-fm-20210705.001-g1160beca Mime-Version: 1.0 Message-Id: In-Reply-To: References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> <01S14QJWN146005PTU@mauve.mrochek.com> <6744a11f-ca83-f824-838d-189c21076d5e@dcrocker.net> <4577662a-b930-40cb-97a3-d626334472b7@www.fastmail.com> Date: Thu, 08 Jul 2021 17:17:47 +0100 From: "Alexey Melnikov" To: "Dave Crocker" , "Alessandro Vesely" , "John C Klensin" , emailcore@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] =?utf-8?q?Ticket_=2311=3A_G=2E7=2E4=2E_Possible_clar?= =?utf-8?q?ification_about_mail_transactions_and_transaction_state?= X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 16:18:17 -0000 On Thu, Jul 8, 2021, at 5:01 PM, Dave Crocker wrote: > On 7/8/2021 8:54 AM, Alexey Melnikov wrote: > >>>>>> A mail transaction may be aborted by the RSET, a new > >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EHLO, or the QUIT command. SMTP= extensions (see Section > >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.2) may create additional comm= ands that abort or > >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 end the trans= action. > ... > >> The second sentence is a classic non-specification that purports to= be a > >> specification. It's essentially giving permission for a hypothetic= al, > >> as if the permission were necessary and useful. It is neither. > > Actually, I disagree, as we have existing extensions that can end tr= ansactions (BDAT/BURL). So pointing out that this should be considered b= y readers of the base spec is a good thing. >=20 > Ahh, yeah, I missed that completely. But I still think the proposed=20= > sentence does not serve the intended goal sufficiently. >=20 > Perhaps: >=20 > The list of actions that terminate a mail transactions is=20 > extensible; it currently includes some SMTP extensions and might be=20= > expanded by later extensions. That would work as well. From nobody Thu Jul 8 09:26:40 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F26A3A27FD for ; Thu, 8 Jul 2021 09:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 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.338, RCVD_IN_DNSWL_MED=-2.3, 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 FHUCVkc_QcJq for ; Thu, 8 Jul 2021 09:26:33 -0700 (PDT) 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 61F0B3A27F8 for ; Thu, 8 Jul 2021 09:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1625761590; bh=rorBuxmSdv6rDG+JyVPrREOxNORmvAdmk3ZGwnRtSg8=; l=552; h=To:References:From:Date:In-Reply-To; b=DSBEbjPhSTbQVW0XE3NUzgm5/ulI2a6Nup2mnqlko1l6+Zf90w3RwJAfn9ERKMsyV Mx43fooz2DH5UTJjZUlQOoABIQrHLD6jPHLaAWlL8CF92z6HsTp/iAOHghX95tQfht cke6/HuovnBCMtjNSaKpRtqNOmIJwtXoi5hh2dgXKT9GoRqDEeuB7iDRgBPUG 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 00000000005DC026.0000000060E72736.00003D5C; Thu, 08 Jul 2021 18:26:30 +0200 To: emailcore@ietf.org References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> <01S14QJWN146005PTU@mauve.mrochek.com> <6744a11f-ca83-f824-838d-189c21076d5e@dcrocker.net> <01S15ISYGJ00005PTU@mauve.mrochek.com> <8bdd2b20-c1da-119a-06f4-76a6bdb44897@dcrocker.net> From: Alessandro Vesely Message-ID: <666163bc-8d4b-39e2-1ba0-a7091b9524c8@tana.it> Date: Thu, 8 Jul 2021 18:26:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <8bdd2b20-c1da-119a-06f4-76a6bdb44897@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 16:26:38 -0000 On Thu 08/Jul/2021 17:41:11 +0200 Dave Crocker wrote: > >     The list of actions that can terminate a mail transaction is >     extensible and subject to expansion with future specifications. That's clear and clean! Maybe s/can terminate/can operate on/ so as to include beginning and middle stuff. > Yes they get it wrong, but that's different from saying we have any hope of > getting them to do better with bits of language like this. That text is also useful to inspire future SMTP extension designers. Best Ale -- From nobody Thu Jul 8 12:28:03 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2723A1740 for ; Thu, 8 Jul 2021 12:28:01 -0700 (PDT) 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 4cpbi-rrNhFy for ; Thu, 8 Jul 2021 12:27:57 -0700 (PDT) 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 4168C3A173D for ; Thu, 8 Jul 2021 12:27:57 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S15IT1N1FK00ANF6@mauve.mrochek.com> for emailcore@ietf.org; Thu, 8 Jul 2021 08:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1625757929; bh=RFve0C7JVys/bnmzKilfkS1FacwfmX+MB+Jii2B0JAA=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=fcd9R3nJdaICjU5JY/kJRJ8jZC8/PNNRvxF4a6391zhvC38CkPBmu4ko8tbPqlsqo 6cEJ6BvG/PWgp25qR6EJ7Zs7ITfoGkuxa27SBD1OZ4n8cerR4AahDKkClVFOB9WA/H paBUr+Y26yUWvaQ5iWg0/nlzabdmsix6+KXGVXSo= 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 <01S0F3SXH38G005PTU@mauve.mrochek.com>; Thu, 8 Jul 2021 08:25:24 -0700 (PDT) Cc: Alessandro Vesely , John C Klensin , emailcore@ietf.org Message-id: <01S15ISYGJ00005PTU@mauve.mrochek.com> Date: Thu, 08 Jul 2021 08:15:48 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 08 Jul 2021 08:09:33 -0700" <6744a11f-ca83-f824-838d-189c21076d5e@dcrocker.net> References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> <01S14QJWN146005PTU@mauve.mrochek.com> <6744a11f-ca83-f824-838d-189c21076d5e@dcrocker.net> To: Dave Crocker Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 19:28:02 -0000 > On 7/8/2021 7:41 AM, Alessandro Vesely wrote: > > On Thu 08/Jul/2021 14:41:56 +0200 Alexey Melnikov wrote: > >> On 08/07/2021 05:00, John C Klensin wrote: > >>> --On Wednesday, July 7, 2021 18:50 -0700 Ned Freed > >>>> How about something like: > >>>> > >>>>       A mail transaction may be aborted by the RSET, a new > >>>>       EHLO, or the QUIT command. SMTP extensions (see Section > >>>>       2.2) may create additional commands that abort or > >>>>          end the transaction. > Hmm. Nevermind the usual hassle about using 'may' in a non-normative > way, it's simple English meaning introduces ambiguity, since it implies > that the transaction might /not/ be aborted. > More direct and clearer: > Receipt of an RSET, a QUIT, or a new EHLO terminates the current > mail transaction. I have no problem with this, although I'm skeptical as to the claim of lack of clarity of the original. > The second sentence is a classic non-specification that purports to be a > specification. It's essentially giving permission for a hypothetical, > as if the permission were necessary and useful. It is neither. Strongly disagree. The point of saying this is to tell implementors that this list of commands that may terminate a transaction is not complete, and they need to plan for that eventuality when they code. Decades of experience with implementors getting this sort of thing wrong and then saying "nothing in the specification said this was possible" says this *is* useful information. > Future specifications will do whatever they do. Whether they are > 'legal' will depend upon what the community decides at the time. True but irrelevant. The purpose of the text is not to give permission, it's to remind people of a possibility. Of course at this point we're lucky if implementors even bother to get a copy of the specification, let alone read it, but that's not an excuse to fail to make the point. Ned From nobody Thu Jul 8 12:28:09 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706D33A1740 for ; Thu, 8 Jul 2021 12:28:03 -0700 (PDT) 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 25uWAUY0fKfB for ; Thu, 8 Jul 2021 12:27:59 -0700 (PDT) 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 281F83A173E for ; Thu, 8 Jul 2021 12:27:58 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S15IWOEJR400ANF6@mauve.mrochek.com> for emailcore@ietf.org; Thu, 8 Jul 2021 08:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1625758104; bh=O9dKwwFIvf/SB2kJcz7cWli3Jxta764u+qvDpUCEyMU=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=MkjZ1iA66Pk2XOeapmdzsi32sp+3moAPyLmXtR3Hw7r/kSt0BFmdYL7xwH58hzH4h HajhMEd543tlOQT3UKpUhw8mzG+8mWoAI0EUktwxwW+XKZy9OKmM3VncgpiztHlX3M WWmMJGuTWVRvpMzgUrkEup/tf9jM4/3mUROsl/a4= 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 <01S0F3SXH38G005PTU@mauve.mrochek.com>; Thu, 8 Jul 2021 08:27:07 -0700 (PDT) Cc: John C Klensin , emailcore@ietf.org Message-id: <01S15IV3PJV0005PTU@mauve.mrochek.com> Date: Thu, 08 Jul 2021 08:25:56 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 08 Jul 2021 16:41:12 +0200" References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> <01S14QJWN146005PTU@mauve.mrochek.com> To: Alessandro Vesely Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 19:28:04 -0000 > On Thu 08/Jul/2021 14:41:56 +0200 Alexey Melnikov wrote: > > On 08/07/2021 05:00, John C Klensin wrote: > >> --On Wednesday, July 7, 2021 18:50 -0700 Ned Freed > >>> How about something like: > >>> > >>>       A mail transaction may be aborted by the RSET, a new > >>>       EHLO, or the QUIT command. SMTP extensions (see Section > >>>       2.2) may create additional commands that abort or > >>>          end the transaction. > Well, since that mentions aborting and ending the transaction, why don't they > also mention starting it? Very true. I would suggest changing the text to say "start, abort, or end" and moving the sentence to a separate paragraph. Ned > -- > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore From nobody Fri Jul 9 05:49:51 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163343A2039 for ; Fri, 9 Jul 2021 05:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 dVA6Js3uTsVC for ; Fri, 9 Jul 2021 05:49:44 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id B207E3A2035 for ; Fri, 9 Jul 2021 05:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1625834980; d=isode.com; s=june2016; i=@isode.com; bh=WqMgad0IZd3CJoQZP84L0RWYzkNvQSraGqYYv1dpA1c=; 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=OVxM9Rj1Z+IJLK6PkGjc+Uj+JyWH64dpA2WjO8pdo2ZK0DS5vzTI0qHLLQR6KhEdhBl5Ma Rbpvm/vu9hpYc6H1FMx+OBjhJi65sXyYKzcURUvQjBj7SvPEitV0XX7hBgyP5a+JAF3xQk G1dnkLPVAbuSKz47MHRmGeeQxc2iYjw=; Received: from [192.168.1.222] (host5-81-100-22.range5-81.btcentralplus.com [5.81.100.22]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 9 Jul 2021 13:49:39 +0100 To: emailcore@ietf.org, Ned Freed From: Alexey Melnikov Message-ID: <7da76485-2472-4807-d10c-73ced365e672@isode.com> Date: Fri, 9 Jul 2021 13:49:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.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 #7: trace header fields - lone Return-Path case X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 12:49:49 -0000 Hi all, Following up on the discussion at IETF 110: I think we settled on the=20 text (what is currently in draft-ietf-emailcore-rfc5322bis-01), but=20 there are still a couple of issues about ABNF that we need to resolve.=20 One of them is whether the current ABNF for trace header fields is correct: =C2=A0=C2=A0 trace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =3D=C2=A0=C2=A0 [return] =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1*received In particular, this disallows the lone Return-Path case. I would like to poll the WG about whether messages with lone=20 Return-Paths are generated in the wild. If they are, the ABNF should=20 probably be relaxed. Best Regards, Alexey From nobody Fri Jul 9 06:11:45 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2F53A20DA for ; Fri, 9 Jul 2021 06:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 hYvGTKnsp87H for ; Fri, 9 Jul 2021 06:11:39 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAA93A20D8 for ; Fri, 9 Jul 2021 06:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1625836298; d=isode.com; s=june2016; i=@isode.com; bh=OH+ty5dIjNHeuKFigzWJkW/o1mIiUVTKcUx9h3hM4iI=; 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=p2DaPh1GLk4l+XU1H3ayqVsHbQyHcfFjspY5QFiUc0KwP097n0Og3l9lNoD0bPCf6qbCf7 YDnxq0eVGOH1zg7zcqyZgSuxhn8cbldIcQvZ/6hqeN2AFpJwEach3Ytqx8EVbAF3aBF7fe IBmawtIhBdfZ1pjbH2BTD2VRVTe07a4=; Received: from [192.168.1.222] (host5-81-100-22.range5-81.btcentralplus.com [5.81.100.22]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 9 Jul 2021 14:11:38 +0100 To: emailcore@ietf.org From: Alexey Melnikov Message-ID: Date: Fri, 9 Jul 2021 14:11:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.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 #42: G.12. Extension Keywords Starting in 'X-' X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 13:11:44 -0000 Dear WG participants, I would like to start a discussion on ticket #42 says: =C2=A0 Section 2.2.2 contains a discussion of SMTP keywords starting in "X"= . =C2=A0 Given general experience with such things and RFC 6648, is there any =C2=A0 reason to not deprecate that practice entirely and remove that text? =C2=A0 If we do so, should Section 4.1.5 be dropped or rewritten to make =C2=A0 clear this is an obsolete practice? We were faced with the same issue in the EXTRA WG when revising=20 IMAP4rev1 and we basically removed any text about "X-", so now even an=20 extension starting with "X-" can be registered in IMAP. Below I quote all sections that mention "X" prefix and provide a=20 strawman on what to change: Last 2 paragraphs of Section 2.2.2 ("Definition and Registration of=20 Extensions"): OLD: =C2=A0=C2=A0 In addition, any EHLO keyword value starting with an upper or = lower =C2=A0=C2=A0 case "X" refers to a local SMTP service extension used exclusi= vely =C2=A0=C2=A0 through bilateral agreement.=C2=A0 Keywords beginning with "X"= MUST NOT be =C2=A0=C2=A0 used in a registered service extension.=C2=A0 Conversely, keyw= ord values =C2=A0=C2=A0 presented in the EHLO response that do not begin with "X" MUST =C2=A0=C2=A0 correspond to a Standard, Standards-Track, or IESG-approved =C2=A0=C2=A0 Experimental SMTP service extension registered with IANA.=C2= =A0 A =C2=A0=C2=A0 conforming server MUST NOT offer non-"X"-prefixed keyword valu= es that =C2=A0=C2=A0 are not described in a registered extension. =C2=A0=C2=A0 Additional verbs and parameter names are bound by the same rul= es as =C2=A0=C2=A0 EHLO keywords; specifically, verbs beginning with "X" are loca= l =C2=A0=C2=A0 extensions that may not be registered or standardized. Convers= ely, =C2=A0=C2=A0 verbs not beginning with "X" must always be registered. Possible NEW: =C2=A0=C2=A0 Keyword values presented in the EHLO response SHOULD =C2=A0=C2=A0 correspond to a Standard, Standards-Track, or IESG-approved =C2=A0=C2=A0 Experimental SMTP service extension registered with IANA. (Note that I changed original MUST to SHOULD, taking into consideration=20 that none of "X" extensions would be registered with IANA.) OLD: 4.1.5.=C2=A0 Private-Use Commands =C2=A0=C2=A0 As specified in Section 2.2.2, commands starting in "X" may be= used =C2=A0=C2=A0 by bilateral agreement between the client (sending) and server =C2=A0=C2=A0 (receiving) SMTP agents.=C2=A0 An SMTP server that does not re= cognize such =C2=A0=C2=A0 a command is expected to reply with "500 Command not recognize= d".=C2=A0 An =C2=A0=C2=A0 extended SMTP server MAY list the feature names associated wit= h these =C2=A0=C2=A0 private commands in the response to the EHLO command. =C2=A0=C2=A0 Commands sent or accepted by SMTP systems that do not start wi= th "X" =C2=A0=C2=A0 MUST conform to the requirements of Section 2.2.2. NEW - drop the whole section? I am not sure if any of the above is=20 useful if "X" prefix is not special anymore, in particular developers=20 can figure out to use "500 Command not recognized" for unrecognized=20 commands. 2nd paragraph of Section 8 ("IANA Considerations"): OLD: =C2=A0=C2=A0 o=C2=A0 The first, "Simple Mail Transfer Protocol (SMTP) Servi= ce =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Extensions" [49], consists of SMTP service e= xtensions with the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 associated keywords, and, as needed, paramet= ers and verbs. As =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 specified in Section 2.2.2, no entry may be = made in this registry =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that starts in an "X".=C2=A0 Entries may be = made only for service =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 extensions (and associated keywords, paramet= ers, or verbs) that =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 are defined in Standards-Track or Experiment= al RFCs specifically =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 approved by the IESG for this purpose. NEW: =C2=A0=C2=A0 o=C2=A0 The first, "Simple Mail Transfer Protocol (SMTP) Servi= ce =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Extensions" [49], consists of SMTP service e= xtensions with the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 associated keywords, and, as needed, paramet= ers and verbs. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Entries may be made only for service =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 extensions (and associated keywords, paramet= ers, or verbs) that =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 are defined in Standards-Track or Experiment= al RFCs specifically =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 approved by the IESG for this purpose. Thoughts? Best Regards, Alexey From nobody Fri Jul 9 08:39:11 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275B33A253A for ; Fri, 9 Jul 2021 08:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 IliSGxDJY3cy for ; Fri, 9 Jul 2021 08:39:04 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 923193A252E for ; Fri, 9 Jul 2021 08:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1625845143; d=isode.com; s=june2016; i=@isode.com; bh=4mmCo9jYN0LEayQodbHfo+LgTBpddnHukA9nKNAIbYk=; 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=UQx9WS+PwJPON4KPbqWWznwwmiQw0BM2NLYjgsn1c6HBsIPJWc5eNm9u/vExLF7XYc94Mo FiRH2mAszkgWq5kROQhlJQjMwlLIeVbExgfmQbu7EvEfYb/UxIpeO9vttda/MNaaeNv7bt dLWAkynqxe62Ar+akiKMxY2ZmknLkXI=; Received: from [192.168.1.222] (host5-81-100-22.range5-81.btcentralplus.com [5.81.100.22]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 9 Jul 2021 16:39:03 +0100 To: emailcore@ietf.org From: Alexey Melnikov Message-ID: Date: Fri, 9 Jul 2021 16:38:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.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 #20: G.7.13. Possible SEND, SAML, SOML Loose End X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 15:39:09 -0000 Dear WG participants, Ticket #20 is asking whether the document needs any further discussion=20 of SEND/SAML/SOML other than in the Appendix F.6 quoted below: F.6.=C2=A0 Sending versus Mailing =C2=A0=C2=A0 In addition to specifying a mechanism for delivering messages = to =C2=A0=C2=A0 user's mailboxes, RFC 821 provided additional, optional, comma= nds to =C2=A0=C2=A0 deliver messages directly to the user's terminal screen.=C2=A0= These =C2=A0=C2=A0 commands (SEND, SAML, SOML) were rarely implemented, and chang= es in =C2=A0=C2=A0 workstation technology and the introduction of other protocols= may =C2=A0=C2=A0 have rendered them obsolete even where they are implemented. =C2=A0=C2=A0 [[5321bis Editor's Note: does this need a stronger reference t= o 821, =C2=A0=C2=A0 2821, and/or 5321?=C2=A0 Also, is anything else needed given t= he removal =C2=A0=C2=A0 of these commands and comments about, e.g., their opening mail =C2=A0=C2=A0 transaction sessions, from the mail body of the text?]] =C2=A0=C2=A0 Clients SHOULD NOT provide SEND, SAML, or SOML as services. Se= rvers =C2=A0=C2=A0 MAY implement them.=C2=A0 If they are implemented by servers, = the =C2=A0=C2=A0 implementation model specified in RFC 821 MUST be used and the =C2=A0=C2=A0 command names MUST be published in the response to the EHLO co= mmand. My strawman is to remove the Editor's note above and close this ticket.=20 Any further thoughts on this topic? Best Regards, Alexey From nobody Fri Jul 9 10:28:11 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FF13A288F for ; Fri, 9 Jul 2021 10:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 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.338, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1770acd1FAe for ; Fri, 9 Jul 2021 10:28:03 -0700 (PDT) Received: from flamingo.ash.relay.mailchannels.net (flamingo.ash.relay.mailchannels.net [23.83.222.60]) (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 3D03B3A2896 for ; Fri, 9 Jul 2021 10:28:01 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E26AF101B72; Fri, 9 Jul 2021 17:27:56 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (100-101-162-69.trex.outbound.svc.cluster.local [100.101.162.69]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 439BE101FF2; Fri, 9 Jul 2021 17:27:56 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.101.162.69 (trex/6.3.3); Fri, 09 Jul 2021 17:27:56 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Plucky-Bottle: 60db7f0d17c5d71c_1625851676648_4228560361 X-MC-Loop-Signature: 1625851676647:847340657 X-MC-Ingress-Time: 1625851676647 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 697D5110F425; Fri, 9 Jul 2021 17:27:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1625851675; bh=M4lM13Jvvh1gZL02E1pGUxN8xN/fmJm2EEHaO2rExU0=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=hCeB3VPJnTXO7wB/JPxxg5YuxFKevKvyyx78aeGw2GIUoq1ftjpfjawIunF4Gk5VA CCqYra8RFSp1JBSM+VDwXN8/t5tFGuzGGs4kWSYz+0poHOMu5uMnb+nEJ/9i2Q5N78 h8b2AdH7MUiXVYBoP0OR+46wVRMKBePjayhw/CAE86d+V5om2hIEltclR5J5x64DtF uUlyBKNBgM1tzDbxfweINrvZN6zA1CygmnsFRR/66RVfvXXTDkGOXcVRTAeOpNDzkA oifj53qTNSd5f3Pl1xHRsFj+JpOnqT/5UprOoC1di+aav2kdOC/1PJPg+J7W/J5S7a UnK8EizyX9E8w== Reply-To: dcrocker@bbiw.net To: Alexey Melnikov , emailcore@ietf.org References: From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Fri, 9 Jul 2021 10:27:55 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.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 #42: G.12. Extension Keywords Starting in 'X-' X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 17:28:09 -0000 On 7/9/2021 6:11 AM, Alexey Melnikov wrote: > I would like to start a discussion on ticket #42 says: When X- was suggested, during RFC 822's development -- and I wish I could remember who came up with the idea -- it seemed clever and useful. I still think it was clever, but we learned that it had problematic downsides. Hence the later deprecation. The entire idea of syntactic support for 'private' constructs has proved problematic. And so, yes, it should be removed, wherever possible. Also wherever possible, we've learned that the simplest and most constructive model is for: 1. Extensible naming 2. An ability (but not requirement) for registering names and associating a specification, with registration reserving the name and its meaning. 3. Standardization of names that are, or are expected to be, important to service operation 4. A meta-rule to ignore a name that is not undersstood. As such, the 'SHOULD' that is suggested here seems to go farther than necessary. SHOULD is supposed to be for things that will break, if you don't conform to the should, unless you /really/ know what you are doing. This doesn't seem to be a case of that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jul 9 11:49:18 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39F23A2B0D for ; Fri, 9 Jul 2021 11:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1TNvZMtHrnd for ; Fri, 9 Jul 2021 11:49:12 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 09BF23A2B09 for ; Fri, 9 Jul 2021 11:49:11 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id j14so5018059qvu.6 for ; Fri, 09 Jul 2021 11:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=AQPMCNdlWZ1nlBvSLmvb5R+olg7+Ugl9K1knuX4yDYc=; b=VSIfxSaouIZWnU4Ywh5E0qhQNhEFd69k3tqxP1eEG2zJxKw+jMOldKiznmCeMTmq1n gKU30q6eCKizWJAahXm3d+9LabgZ1Yc5l6vYIP5PQQZ+4T5EEdSqxBayQt2jGtnnQWwF vp0amlpJlKwSFIE4jZTSNVZIvISaEnWWKIVKwTdbYQFuzE7fK7ah4j1O4jfRWBFyehcy yzLs/oslVdyJ8bwQ1KtYsGGrnyJvJtEZPF9NVvfVRPhfLDD3+65h0fec72f7xvfyqZvo 0/jVgC4i1KHEWiuKU1N19gyuFxh3Qe/yOvSfwgSXvKrtBSQej+lhLkgY1Xw8MXPSTv1l Vm6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AQPMCNdlWZ1nlBvSLmvb5R+olg7+Ugl9K1knuX4yDYc=; b=ctYDlBDukWh+iqwMfUYBETI2ph6u+CtBD/L9CvnO9T6CaS978N6Gq6LOfSxRDXw8+d TIbxaPeKH//NaOmZpYrChyaTjAg48knNaWuyr+pTw+/8RLuwBvtNzMBJ+IignBsVvsZi GBQ1sSfS6yFL7B97O3LrfFkl19ZlTOnJkYA3pZFu3q8YapfRy57iVq0/SSK1YXvEg04Q K7/RO46caVgKs1MyD/rLCoEN7M8UWmC3+9gESmTfkard7g1zBLEcTZbOt7xYcJiFRrPb aiNRCRaqzrJ3oleqp/4QdTwk7hgMrZxRbgNc8nOO+lIYtg7cqILJcn6Xu2feU8Ja5c1J VGEg== X-Gm-Message-State: AOAM5333EHV/2+NjnlJluJlyTYYUlLpEKU3iSX0S8x+CRSh5Yl/+HuaR VVildfD7Lw9vWNKIeYarvAeeV27QlOvIYKRBpN01SjZpAQE8SQ== X-Google-Smtp-Source: ABdhPJxe7NwaVawkRgyMRhjEEVSpYILzivQ+cn1HSRLvbcol6F/dM9v967IWxCLOzlju9/NX7gEppuPFcdR9m6l0U5o= X-Received: by 2002:ad4:4a6c:: with SMTP id cn12mr37710817qvb.39.1625856550120; Fri, 09 Jul 2021 11:49:10 -0700 (PDT) MIME-Version: 1.0 From: Todd Herr Date: Fri, 9 Jul 2021 14:48:54 -0400 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000203fc605c6b53aaa" Archived-At: Subject: [Emailcore] Ticket #10: Meaning of "resolvable FQDN" in Section 2.3.5 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 18:49:17 -0000 --000000000000203fc605c6b53aaa Content-Type: text/plain; charset="UTF-8" Greetings. I would like to start a discussion on ticket #10, which reads: In other words, names that can be resolved to MX RRs or address (i.e., A or > AAAA) RRs (as discussed in Section 5) are permitted, as are CNAME RRs > whose targets can be resolved, in turn, to MX or address RRs. > > It is not clear whether "In other words" really meant "for example" or it > is was (sic) intended that the only labels permitted are those that own > records in one of the above RR types. The proposal here is to change the text, replacing "In other words" with "In particular", as follows: OLD: Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP. *In other words*, names that can be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed in Section 5 ) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs. Local nicknames or unqualified names MUST NOT be used. There are two exceptions to the rule requiring FQDNs: NEW: Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP. *In particular,* names that can be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed in Section 5 ) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs. Local nicknames or unqualified names MUST NOT be used. There are two exceptions to the rule requiring FQDNs: Thoughts? -- *Todd Herr* | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000203fc605c6b53aaa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings.

I would like to start a discussion on ticket #10, = which reads:

In other words, names that = can be resolved to MX RRs or address=C2=A0(i.e., A or AAAA) RRs (as discussed in Section 5) are permitted, as= =C2=A0are CNAME RRs whose targets c= an be resolved, in turn, to MX or=C2=A0address RRs.
=C2=A0
It is not clear whether &= quot;In other words" really meant "for example" or it= is was=C2=A0(sic) intended that the on= ly labels permitted are those that own records in one of the above RR types= .

=
T= he proposal here is to change the text, replacing "In other words"= ; with "In particular", as follows:

OLD:

  Only resolvable, =
fully-qualified domain names (FQDNs) are permitted
   when domain names are used in SMTP.  In other words, names that c=
an
   be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
   in S=
ection 5) are permitted, as are CNAME RRs whose targets can be
   resolved, in turn, to MX or address RRs.  Local nicknames or
   unqualified names MUST NOT be used.  There are two exceptions to the=C2=
=A0
   rule requiring FQ=
DNs:

NEW:

   Only resolvable, fully-qualified domain names (FQDNs=
) are permitted
   when domain names are used in SMTP.  In particular, names that can
   be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
   in S=
ection 5) are permitted, as are CNAME RRs whose targets can be
   resolved, in turn, to MX or address RRs.  Local nicknames or
   unqualified names MUST NOT be used.  There are two exceptions to the=C2=
=A0
   rule r=
equiring FQDNs:

Thoughts?
--

Todd Herr | Technical Director, Stand= ards and Ecosystem
m: 703.220.4153
=

This email and all d= ata transmitted with it contains confidential and/or proprietary informatio= n 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 o= f 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 sy= stem.

--000000000000203fc605c6b53aaa-- From nobody Fri Jul 9 12:02:28 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D703A2B55 for ; Fri, 9 Jul 2021 12:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Et0NpnEsUb39 for ; Fri, 9 Jul 2021 12:02:13 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9EF3A2B77 for ; Fri, 9 Jul 2021 12:02:12 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id c9so4269506qte.6 for ; Fri, 09 Jul 2021 12:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=fYyOMmGbdl9WrACRjzgx20flBsgJd29rWsRYXfaps0E=; b=WiSJ6iF8ORhjUqMtW4D2aWeSR8dDCvgFaFGMGQGp7QMBgUJrZdRGpqUQykFh+FXdcE +rXX/SKWfqMIE5Twc3aP5wi7o1qpC5kCPLyeDrDdN8wQdc8IP7if3b758Yyys7cDJuhk CeTx8Q9LBpCiI5oA/qyHF8eNV5wu47sP5b8nr9UPlV4S7v3cwL9rFA0CY/dunHUFfwT9 1yLsr2WsDCkBU3OwXqRnwNENAop7JSo+w+kVFAigP/C0P3YQ2iqx86Wd1Alh+4aOerEl QKfs6B/C8dlSJcQKJqdU7jKg0rxsRdNsdkvwcM4UBt86IHyIjH6Mo5dD0IY2KCZFWijs YXOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fYyOMmGbdl9WrACRjzgx20flBsgJd29rWsRYXfaps0E=; b=Hw9gbEqjJnNS651new5LkWkUc15BSVQhtrulH3XoicZw/+Rh08w/HflzVCih9xAFZR SsZJAeRioEnaycFPo5mf8K/SF17G/kW0JtHzGHx9qDQr9bOWtnC5oUaoSe34vAl/9neY ECtKwu+PF6zq8vAG2+2Ns6Z3+ZPeNlWM+luDLZKo/IkEMs16SdJodd7g7P86wNIsHLT5 s67WvcfobAQJO8u6l6sgkZgabFi8BklMnJxt4MmP7i/iCr+H9/T2afeGAH26qKExzNef BkGtR5M7Gp4enu+/dvhbSNVxF0ghTdPjxidrgpsZJiV5IiGX52cgh1YX/aRhCo2vOU7N U6Iw== X-Gm-Message-State: AOAM532B9xPcmh5NvSINnSNQAqJfVAMAE/VQZ0qGAZDhZtEd+t4xJSBZ 2spR41I9b6gFwaXilLCcC3QoXpS1qGXuJ0Oa8jEEnY4tE2M0Jg== X-Google-Smtp-Source: ABdhPJwxk3+Vb7orJjkq0XP63pUQQK/QJAc7dIq0AyblsZqhOrmHZiH1gb8GPbK0P7PFielrRdw678f7hwE+gjjucmE= X-Received: by 2002:ac8:59ca:: with SMTP id f10mr17774134qtf.298.1625857330835; Fri, 09 Jul 2021 12:02:10 -0700 (PDT) MIME-Version: 1.0 From: Todd Herr Date: Fri, 9 Jul 2021 15:01:55 -0400 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000a908c005c6b568cb" Archived-At: Subject: [Emailcore] Ticket #14: G.7.8. Review different size limits X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 19:02:27 -0000 --000000000000a908c005c6b568cb Content-Type: text/plain; charset="UTF-8" Greetings. I would like to start a discussion about ticket #14 - https://trac.ietf.org/trac/emailcore/ticket/14 Section 4.5.3.1 of draft-ietf-emailcore-rfc5321bis reads: 4.5.3.1. Size Limits and Minimums There are several objects that have required minimum/maximum sizes. Every implementation MUST be able to receive objects of at least these sizes. Objects larger than these sizes SHOULD be avoided when possible. However, some Internet mail constructs such as encoded X.400 addresses (RFC 2156 [26]) will often require larger objects. Clients MAY attempt to transmit these, but MUST be prepared for a server to reject them if they cannot be handled by it. To the maximum extent possible, implementation techniques that impose no limits on the length of these objects should be used. Extensions to SMTP may involve the use of characters that occupy more than a single octet each. This section therefore specifies lengths in octets where absolute lengths, rather than character counts, are intended. and ticket 14 asks the question: Given the controversy on the SMTP mailing list between 20191123 and now about maximum lengths, is the above adequate or is further tuning of the limit text below needed? draft-ietf-emailcore-rfc5321bis then goes on to specify length limits in octets, not characters, in each of the following sections: 4.5.3.1.1. Local-part 4.5.3.1.2. Domain 4.5.3.1.3. Path 4.5.3.1.4. Command Line 4.5.3.1.5. Reply Line 4.5.3.1.6. Text Line 4.5.3.1.7. Message Content 4.5.3.1.8. Recipient Buffer Thoughts? -- *Todd Herr* | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000a908c005c6b568cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings.

I would like to start a discussion about ticket #1= 4 -=C2=A0https:/= /trac.ietf.org/trac/emailcore/ticket/14

Section 4.5.3.1 of draft-iet= f-emailcore-rfc5321bis reads:

4.5.3.1.  Size Limits and Minimums

   There are several objects that have required minimum/maximum sizes.
   Every implementation MUST be able to receive objects of at least
   these sizes.  Objects larger than these sizes SHOULD be avoided when
   possible.  However, some Internet mail constructs such as encoded
   X.400 addresses (RFC 2156 [26]) will often require larger objects.
   Clients MAY attempt to transmit these, but MUST be prepared for a
   server to reject them if they cannot be handled by it.  To the
   maximum extent possible, implementation techniques that impose no
   limits on the length of these objects should be used.
   Extensions to SMTP may involve the use of characters that occupy more
   than a single octet each.  This section therefore specifies lengths
   in octets where absolute lengths, rather than character counts, are
   intended.

and ticket 14 asks the question:

<= /div>
=
Given the controversy on the SMTP mailing list betwee= n 20191123 and now about maximum lengths, is the above adequate or is furth= er tuning of the limit text below needed?

draft-ietf-emai= lcore-rfc5321bis then goes on to specify length limits in octets, not chara= cters, in each of the following sections:

4.5.3.1.1. L= ocal-part
4.5.3.1.2. Domain
4.5.3.1.3. Path
4.5.3.1.4. Command Lin= e
4.5.3.1.5. Reply Line
4.5.3.1.6. Text Line
4.5.3.1.7. Message Co= ntent
4.5.3.1.8. Recipient Buffer
<= /blockquote>

Thoughts?

--

<= div style=3D"text-align:left">Todd Herr | Technical Director, Standards and Ecosystem
m: 703= .220.4153

This email and all data transmitted with it contai= ns confidential and/or proprietary information intended solely for the use = of individual(s) authorized to receive it. If you are not an intended and a= uthorized recipient you are hereby notified of any use, disclosure, copying= or distribution of the information included in this transmission is prohib= ited and may be unlawful. Please immediately notify the sender by replying = to this email and then delete it from your system.

=
--000000000000a908c005c6b568cb-- From nobody Fri Jul 9 12:25:16 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62273A2C27 for ; Fri, 9 Jul 2021 12:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuOMO9Y_mRY2 for ; Fri, 9 Jul 2021 12:25:08 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 AB9BB3A2C20 for ; Fri, 9 Jul 2021 12:25:05 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id b18so10432641qkc.5 for ; Fri, 09 Jul 2021 12:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=RQJWPKzaTJO6vdoFzlgC6DglttYe03t5oNX6n5k2VAw=; b=YowfZeF1NL7N7Ik8nlSzcL5h+D2ubtaXOyICJOGA2z5lb5MEZ2Fu85s+iRssuM1NGr zM0f3fcYCCcNA/H0QqndgbIl2QA55GGxOjk/IYaSJX0nXeOHy6fmtkutK80MrTfxa2ka tvt2yZoZox1gf1uQS90PKk+e6pNGd4ZBFl02UWvqV9wFX9QdDfbTtLSzwd30V8B4PiYa uOpcFACBZouJhQQYEczYjdIWsCGTcjwOX1A3ki4PGGQgOpBiBfw+WcbC/efQRESE5ofO aPBOn+O9BKbfDOSGW8yQQRT3DGiLv60U/BBYIbC8BLhflU/9S62CV+jGQ+5QStSKviUP IGYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RQJWPKzaTJO6vdoFzlgC6DglttYe03t5oNX6n5k2VAw=; b=FbKYdM295bKmabWSx6ESJCX+4WJHCac2CXdUpg6r317YOMELPOgZifYjpEENDL7heg SNurcDM4Nl8PQXkMrgQnN2rqOaA7tgZsamvZ2UT298JlKCYq/rBk93uoUifWsv/HfSKC x5VFrHU5MEHHx3hlGL62l3QpjQxUdPJW5FSa9r9rUuUPQhkoG1Irx9Arqfvii25q7Ex6 3X8brUQgD38XDx9Rro1vN98rGog0R4EASx7/tA/ljPm8oz+HHo1FupEdD+MjftRBKyvh kY5uNkvCZKXngnkUWChYU2HY115IHTrTiTuKCiYKsrXPubNLiM02rsaU+rsRmj6Mqy8h 5YmQ== X-Gm-Message-State: AOAM531JYq6Yi0w8petUgzVdfxFfTw6qEHaNTewnj+TfPKfCq9ZPMDE4 rJD+0AqsEnrzX08VKXHzGTa4L+Ev+IUV23edGp945y+ug8bztg== X-Google-Smtp-Source: ABdhPJynZTCSJrVMkmjEePDsRS+bFnb0DX0KK6kJxKJ+JQKoxZSe8hghjDsUTs0LAldiipyEiwxRshZnqaSgG1zLvZs= X-Received: by 2002:a37:b42:: with SMTP id 63mr40470916qkl.325.1625858703058; Fri, 09 Jul 2021 12:25:03 -0700 (PDT) MIME-Version: 1.0 From: Todd Herr Date: Fri, 9 Jul 2021 15:24:47 -0400 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="0000000000007379c505c6b5ba05" Archived-At: Subject: [Emailcore] Ticket #19: G.7.6. Requirements for domain name and/or IP address in EHLO X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 19:25:15 -0000 --0000000000007379c505c6b5ba05 Content-Type: text/plain; charset="UTF-8" Greetings. I would like to begin a discussion on ticket #19 - https://trac.ietf.org/trac/emailcore/ticket/19 - as a long belated follow on to discussion that was had during IETF 110. Section 4.1.4 of draft-ietf-emailcore-5321bis includes this paragraph: An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. [[CREF13: [5321bis] [[Note in draft -- proposed change to "An SMTP server MAY verify that the domain name argument in the EHLO command has an address record matching the IP address of the client." --David MacQuigg, david_macquigg@yahoo.com, Friday, 20090130 0637 -0700]]]] However, if the verification fails, the server MUST NOT refuse to accept a message on that basis. Information captured in the verification attempt is for logging and tracing purposes. Note that this prohibition applies to the matching of the parameter to its IP address only; see Section 7.9 for a more extensive discussion of rejecting incoming connections or mail messages. Discussion at IETF 110 (https://codimd.ietf.org/notes-ietf-110-emailcore) landed on adding text to the Applicability Statement regarding how mail might be rejected if EHLO hostname doesn't resolve in DNS to IP address of SMTP client. I propose the following as a strawman... Change the above paragraph to read as follows: An SMTP server MAY verify that the domain name argument in the EHLO command has an address record matching the IP address of the client. And include the following text in the Applicability Statement: If the domain name argument in the EHLO command does not have an address record in the DNS that matches the IP address of the client, the SMTP server may refuse any mail from the client as part of established anti-abuse practice. Operational experience has demonstrated that the lack of a matching address record for the the domain name argument is at best an indication of a poorly-configured MTA, and at worst that of an abusive host. Thoughts? -- *Todd Herr* | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --0000000000007379c505c6b5ba05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings.

I would like to begin a discussion on ticket #19 -= =C2=A0https://tr= ac.ietf.org/trac/emailcore/ticket/19 - as a long belated follow on to d= iscussion that was had during IETF 110.

Section 4.1.4 of draft-ietf-emai= lcore-5321bis includes this paragraph:

   An SMTP server MAY verif=
y that the domain name argument in the EHLO
   command actually corresponds to the IP address of the client.
   [[CREF13: [5321bis] [[Note in draft -- proposed change to "An SMTP
   server MAY verify that the domain name argument in the EHLO command
   has an address record matching the IP address of the client." --Dav=
id
   MacQuigg, david_macquigg@yah=
oo.com, Friday, 20090130 0637 -0700]]]]
   However, if the verification fails, the server MUST NOT refuse to
   accept a message on that basis.  Information captured in the
   verification attempt is for logging and tracing purposes.  Note that
   this prohibition applies to the matching of the parameter to its IP
   address only; see Section 7.9 for a more extensive discussion of
   rejecting incoming connections or mail messages.
Discussion at I= ETF 110 (https://codimd.ietf.org/notes-ietf-110-emailcore) landed on adding text to the Applicability State= ment regarding how mail might be rejected if EHLO hostname doesn't reso= lve in DNS to IP address of SMTP client.

<= /font>
I propose the following as a strawman...

Change the above paragraph to read as follows:

=C2=A0 =C2=A0An SMTP server MAY verify that the domain name argumen= t in the EHLO
=C2=A0 =C2=A0command has an address record matching the I= P address of the client.

And include the = following text in the Applicability Statement:

=C2=A0 =C2=A0If the domain name argument in the EHLO command does not have= an address
=C2=A0 =C2=A0record in the DNS that matches the IP address o= f the client, the SMTP
=C2=A0 =C2=A0server may refuse any mail from the = client as part of established anti-abuse
=C2=A0 =C2=A0practice. Operatio= nal experience has demonstrated that the lack of a matching
=C2=A0 =C2= =A0address record for the the domain name argument is at best an indication= of
=C2=A0 =C2=A0a poorly-configured MTA, and at worst that of an abusiv= e host.
Thoughts?
-= -

T= odd Herr | Technical Director, Standards and= Ecosystem
<= span style=3D"vertical-align:baseline">e: todd.herr@valimail.com
m:= 703.220.4153

This email and all data trans= mitted with it contains confidential and/or proprietary information intende= d 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 t= ransmission is prohibited and may be unlawful. Please immediately notify th= e sender by replying to this email and then delete it from your system.

--0000000000007379c505c6b5ba05-- From nobody Fri Jul 9 12:31:41 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95243A2C56 for ; Fri, 9 Jul 2021 12:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.937 X-Spam-Level: X-Spam-Status: No, score=-2.937 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_LOW=-0.7, 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 3xT1YDO1icKD for ; Fri, 9 Jul 2021 12:31:34 -0700 (PDT) Received: from mail-ob.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id A25E83A2C52 for ; Fri, 9 Jul 2021 12:31:34 -0700 (PDT) Received: (qmail 38138 invoked from network); 9 Jul 2021 19:31:33 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (AES128-GCM-SHA256 encrypted) SMTP (446a3d2c-e0ec-11eb-89f1-f3cfa853c2cf); Fri, 09 Jul 2021 12:31:33 -0700 To: emailcore@ietf.org References: From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <6df9293d-6d14-d075-1715-2068258addc2@linuxmagic.com> Date: Fri, 9 Jul 2021 12:31:32 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 2.2.x-3.x X-MagicMail-UUID: 446a3d2c-e0ec-11eb-89f1-f3cfa853c2cf 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 #19: G.7.6. Requirements for domain name and/or IP address in EHLO X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 19:31:40 -0000 On 2021-07-09 12:24 p.m., Todd Herr wrote: > I propose the following as a strawman... > > Change the above paragraph to read as follows: > >    An SMTP server MAY verify that the domain name argument in the EHLO >    command has an address record matching the IP address of the client. > > And include the following text in the Applicability Statement: > >    If the domain name argument in the EHLO command does not have an address >    record in the DNS that matches the IP address of the client, the SMTP >    server may refuse any mail from the client as part of established > anti-abuse >    practice. Operational experience has demonstrated that the lack of a > matching >    address record for the the domain name argument is at best an > indication of >    a poorly-configured MTA, and at worst that of an abusive host. > Thoughts? > -- Disagree, the EHLO MAY be an internal identifier, and while operators may choose many forms of validation of EHLO, it should NOT be confused with information related to the IP Address, whereas PTR records are related to the IP Address. They serve different purposes, and should not be cross correlated. And while anyone is able to reject any connection, for any reason they see fit, this should NOT be part of the RFC's. Not to mention, we still see far too many valid uses of EHLO that do not conform to that. Eg, internal delivery farms, where the administrators find that using an internal naming convention, unrelated to their public naming conventions -- "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 Fri Jul 9 12:43:21 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368A83A2CA6 for ; Fri, 9 Jul 2021 12:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0F6laZMOFfdg for ; Fri, 9 Jul 2021 12:43:14 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 483C53A2CA7 for ; Fri, 9 Jul 2021 12:43:14 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id j184so10565543qkd.6 for ; Fri, 09 Jul 2021 12:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=pkCUs9Jc3GxOkWZFyIEdUyXcfS6TsGxZa/zeKPdyF7c=; b=bjN7vXEAQ1+pxsXc96RzmkQenpeRhLb2xIB6yya7QuH2FTnHw7fWGju2838RLW+SMx xr4np/FEafvEVWjWUyL2alvGd3ukWy/HERQiSfKWUv1a5WiEmNEBl6rUHZO2p/XO46/b B50S+kE0s7rRbdWDlkCWnaot/jGXvMkD6T21wXIpSWCK/jKqKpqSiEL4s5Tgym+NCuYJ Ks82C+V1G5c11wLBQOV/sDFMULD2IbgR2Kp63824ut65a+LK+P6sYegIZSfxlLj+gz/g 1xJzkfcBRauKMJbCZixx5cCdUHa7eT4BrWYdbvT7RwZT1YoWQ+IRJK2k/T1b9oQaXgNt Fl1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pkCUs9Jc3GxOkWZFyIEdUyXcfS6TsGxZa/zeKPdyF7c=; b=IasPUk6W3I8aWXSUin3FWa7SAwmxOia7+9zPy+uwiYx6en19kAGI1pT6E35JcESPJk 1X3aONSIbdSNDVJMDm6sM1mTugYj565X2UD2ADLBUf4o+JUyKjn92UMvtGTXChZgN65P 0/fRiQNQ42+kehY+PdlSWoq0GncchQiGh9SUd71KWYGm4VwcHBShx335IXJxXgsZT2wv vdwJUodoVrA5FGzjWIamzzz0QVTE8u6w+JUz33+MAg5ON9SDpQDcqK6oWH4FTovkPGfG c9XIUMlNsYlrZLkMMqg4k58I9WLbxgOLbkIfi6aXOLCU1szU/wmAdiuYlKggpxME//NL owHg== X-Gm-Message-State: AOAM530pi+N6uhIzgOUCo7Fgy63HidMooVXt5p/AtBpFzxUcmyaN/Nld H48rRTfYLQz5UJZfGM82VJ8mkYXXy7rXOQWI5XVs6EUG3kExbQ== X-Google-Smtp-Source: ABdhPJydOsFbgvVG1xraEZScxkLPAstDOPxWzQ0YDc7fuAc/jp8Yx+V0Hll6eJseEFeBDV1+AQhThSHMl6nU4XOymXA= X-Received: by 2002:a37:b42:: with SMTP id 63mr40553205qkl.325.1625859792301; Fri, 09 Jul 2021 12:43:12 -0700 (PDT) MIME-Version: 1.0 From: Todd Herr Date: Fri, 9 Jul 2021 15:42:56 -0400 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="0000000000005ffc8a05c6b5fb7a" Archived-At: Subject: [Emailcore] Ticket #30: Erratum 4055: Description of SPF and DKIM is wrong X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 19:43:19 -0000 --0000000000005ffc8a05c6b5fb7a Content-Type: text/plain; charset="UTF-8" Greetings. I would like to start a discussion of ticket #30 - https://trac.ietf.org/trac/emailcore/ticket/30 Section 3.6.2 in draft-ietf-emailcore-rfc5321bis contains the following paragraph: This specification does not deal with the verification of return paths for use in delivery notifications. Recent work, such as that on SPF [41] and DKIM [43] [44], has been done to provide ways to ascertain that an address is valid or belongs to the person who actually sent the message. [[5321bis Editor's Note: Proposed erratum (4055) suggests that DKIM and SPF have nothing to do with this and that everything after the first sentence should be dropped. An alternative would be to tune the texts. ???]] A server MAY attempt to verify the return path before using its address for delivery notifications, but methods of doing so are not defined here nor is any particular method recommended at this time. The strawman proposal here is to rewrite the paragraph as follows: This specification does not deal with the verification of return paths for use in delivery notifications. A server MAY attempt to verify the return path before using its address for delivery notifications, but methods of doing so are not defined here nor is any particular method recommended at this time. Thoughts? -- *Todd Herr* | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --0000000000005ffc8a05c6b5fb7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings.

I would like to start a discussion of ticket #30 -= =C2=A0https://tr= ac.ietf.org/trac/emailcore/ticket/30

Section 3.6.2 in draft-ietf-ema= ilcore-rfc5321bis contains the following paragraph:

   This specif=
ication does not deal with the verification of return
   paths for use in delivery notifications.  Recent work, such as that
   on SPF [41] and DKIM [43] [44], has been done to provide ways to
   ascertain that an address is valid or belongs to the person who
   actually sent the message.
   [[5321bis Editor's Note: Proposed erratum (4055) suggests that DKIM
   and SPF have nothing to do with this and that everything after the
   first sentence should be dropped.  An alternative would be to tune
   the texts.  ???]]
   A server MAY attempt to verify the return path before using its
   address for delivery notifications, but methods of doing so are not
   defined here nor is any particular method recommended at this time.

The strawman proposal here is to rewrite the paragraph= as follows:

<=
font face=3D"tahoma, sans-serif">   This specification does not deal with t=
he verification of return
   paths for use in delivery notifications.  A server MAY attempt to verify=
 
   the return path before using its address fo=
r delivery notifications, but methods
   of doing so are not defined here nor is any particular method=C2=A0recom=
mended 
   at this time.

<= pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar= gin-bottom:0px;break-before:page;color:rgb(0,0,0)">Thoughts?=
--

Todd Herr | Te= chnical Director, Standards and Ecosystem
<= div style=3D"text-align:left">e:= todd.herr@valimail.com
m: 703.220.4153<= /span>

This email and all data transmitted with it contains confidential and/or = proprietary information intended solely for the use of individual(s) author= ized 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 unlawfu= l. Please immediately notify the sender by replying to this email and then = delete it from your system.

--0000000000005ffc8a05c6b5fb7a-- From nobody Fri Jul 9 13:09:20 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714BE3A2D64 for ; Fri, 9 Jul 2021 13:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.338, 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 s1IC27_hUXo9 for ; Fri, 9 Jul 2021 13:09:08 -0700 (PDT) Received: from mail-ob3.cityemail.com (mail-ob3.cityemail.com [104.128.152.20]) by ietfa.amsl.com (Postfix) with ESMTP id CD48C3A2D63 for ; Fri, 9 Jul 2021 13:09:08 -0700 (PDT) Received: (qmail 18439 invoked from network); 9 Jul 2021 20:09:07 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe3.cityemail.com with (AES128-GCM-SHA256 encrypted) SMTP (83fd78fa-e0f1-11eb-905b-6b3a5ba8b5f3); Fri, 09 Jul 2021 13:09:07 -0700 To: emailcore@ietf.org References: From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <1c88ada6-c9b1-4b5e-7183-cb11094e8af8@linuxmagic.com> Date: Fri, 9 Jul 2021 13:09:07 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: 83fd78fa-e0f1-11eb-905b-6b3a5ba8b5f3 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 #30: Erratum 4055: Description of SPF and DKIM is wrong X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 20:09:15 -0000 Should not verfication be done on the MAIL FROM itself, before the Return-Path header is added? And also, where do you draw the line on discussing verification, and when does this cross over to spam and forgery detection, and not the core of email delivery, I would suggest that line be carefully considered before adding and recommendations, or permissions or suggestions to validation. And of course, there is a whole bundle of considerations, eg validating bounce and other mechanisms like <>. However, I do think that the very basic, eg if not authenticated, or permitted to relay AND a domain part is present, their SHOULD be a valid A or MX record for that domain, that allows for a theoretical bounce or a way to determine a mechanism to notify the administrator responsible for that domain. However, there are many implementations that do not do those basics, eg the admin that is concerned that he might reject email, simply because their DNS or the sender domain DNS server are offline at the moment. Probably should be very clear what to do when validating this information, eg they should only send a 4xx if it is a validation problem, but maybe a 5xx if they can confirm it is a malicious use? Just thoughts to add to this thread. On 2021-07-09 12:42 p.m., Todd Herr wrote: > Greetings. > > I would like to start a discussion of ticket #30 - > https://trac.ietf.org/trac/emailcore/ticket/30 > > > Section 3.6.2 in draft-ietf-emailcore-rfc5321bis contains the following > paragraph: > > This specification does not deal with the verification of return > paths for use in delivery notifications. Recent work, such as that > on SPF [41] and DKIM [43] [44], has been done to provide ways to > ascertain that an address is valid or belongs to the person who > actually sent the message. > [[5321bis Editor's Note: Proposed erratum (4055) suggests that DKIM > and SPF have nothing to do with this and that everything after the > first sentence should be dropped. An alternative would be to tune > the texts. ???]] > A server MAY attempt to verify the return path before using its > address for delivery notifications, but methods of doing so are not > defined here nor is any particular method recommended at this time. > > > The strawman proposal here is to rewrite the paragraph as follows: > > This specification does not deal with the verification of return paths > for use in delivery notifications. A server MAY attempt to verify > > the returnpath before using its address for delivery notifications, but > methods of doing so are not defined here nor is any particular > method recommended > > at this time. > > > Thoughts? > > > -- > > *Todd Herr*| Technical Director, Standards and Ecosystem > *e:*todd.herr@valimail.com > *m:*703.220.4153 > > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is > prohibited and may be unlawful. Please immediately notify the sender by > replying to this email and then delete it from your system. > > -- "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 Fri Jul 9 13:16:34 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CE43A2D96 for ; Fri, 9 Jul 2021 13:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 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.338, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWOPnlmJDbKl for ; Fri, 9 Jul 2021 13:16:28 -0700 (PDT) Received: from donkey.ash.relay.mailchannels.net (donkey.ash.relay.mailchannels.net [23.83.222.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAFDE3A2D8F for ; Fri, 9 Jul 2021 13:16:26 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A42993227BA; Fri, 9 Jul 2021 20:16:21 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (100-101-162-68.trex-nlb.outbound.svc.cluster.local [100.101.162.68]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 82CC33213A7; Fri, 9 Jul 2021 20:16:20 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (35.45.192.35.bc.googleusercontent.com [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.101.162.68 (trex/6.3.3); Fri, 09 Jul 2021 20:16:21 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Celery-Lyrical: 479fe57e7a2678c3_1625861781397_3219532322 X-MC-Loop-Signature: 1625861781397:3710728749 X-MC-Ingress-Time: 1625861781397 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id A0E5D30B5572; Fri, 9 Jul 2021 20:16:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1625861779; bh=8WZlGy3A897xUHe1alcoE7MRt12Sr0psfp/s6vKEegE=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=UkEWnu2CA1rCXozxvzRjoIlxZVOD1tqlQqJm/vk2INYQ4Ni5vGrSeCiue8H23Mgd0 KGQR8wgQ4T2GizGf42IxlhUzNB2OMnFfWIEwwnrAuX12tOcREMSdVF89XjfNVkh5FQ 62SovVs0DMAArefnCHVsim5KySvn87HiXJnLx+HeHtFfF4ed0pMMKMEsNdqTlX5eVq cbcFR42+kY25xai2tSxKQ6In4yTJhXpOlUQE5NTuh1q2YS7KAVZv/4vfaZYJJgzhxO sr1jvVuKZzIcykqBog+bp8k3tNbi67JhliRC03M9Gan3PwSzjIrkZ77lQ0tLmqgXLF UdpByaNCZTiDQ== Reply-To: dcrocker@bbiw.net To: Todd Herr , emailcore@ietf.org References: From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <4d75d10a-baf1-2c44-6c6c-f921eba9c5ff@dcrocker.net> Date: Fri, 9 Jul 2021 13:16:17 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.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 #30: Erratum 4055: Description of SPF and DKIM is wrong X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 20:16:33 -0000 On 7/9/2021 12:42 PM, Todd Herr wrote: > > This specification does not deal with the verification of return paths > for use in delivery notifications. A server MAY attempt to verify > > the returnpath before using its address for delivery notifications, but > methods of doing so are not defined here nor is any particular > method recommended > > at this time. > > > Thoughts? Definitely better. References to details that are outside the actual scope of the current specification create a forward reference that invites problems. But I will suggest that the MAY is a pseudo-specification. It proffers normative language but has not technical substance. Hence, perhaps: This specification does not deal with the verification of a return path for use in delivery notifications. Verification of the return path is outside the scope of this specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jul 9 13:19:56 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A683A2DB4 for ; Fri, 9 Jul 2021 13:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=S2VqxatF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LewVFNdp 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 YZGtczJaeg2e for ; Fri, 9 Jul 2021 13:19:48 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B81133A2DB3 for ; Fri, 9 Jul 2021 13:19:48 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BC2345C00EA; Fri, 9 Jul 2021 16:19:47 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 09 Jul 2021 16:19:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-type:content-transfer-encoding:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; s=fm3; bh=fJ8q1Lb R3JEj41qhAJfK7wikbSIB0wYpAZUVwxGusKk=; b=S2VqxatFRUovylBIlQZeMLZ 9/opLB/OcfJiH/Jn/RoWOrlFaHmIK2AuQ+xtpjrkp88zxZN6Yrglrdbv/C7qyBtw 9P73P9IcGWQ12r9LK0rXAsxKGkfu2Kdp3ZFAormLSiTK1/grRJGNeFVBEujy5XVF KGPS/NPiGqDlBHczvGhyf7q35jNY+FaCu1QcXtrTyoMH/JHHkoV6luk/WyZoW6Me uQ/AuO8ZcC6N9fE0fBy4TWlMk0y9KxV/Ejnm8tFOXSM6qzuZ3WUhdLuyGh+QWtoQ HyDRUorxnJLx75t+aYgxsgwAFPBz2nsxscBE7jL6itbE2f8sV8jaM01DCHGL57w= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=fJ8q1LbR3JEj41qhAJfK7wikbSIB0wYpAZUVwxGus Kk=; b=LewVFNdpwTmofKuC31QnFOettDEhhEEKnECBMe4ruwOcPSBI372kderg4 36aTZQj2XmJGYlqFS2yq30u+LkqcfFnweJ7Io1OHYZmN5xjnt44aglkGh/vCkIOK M3bqWu5o0d4YwKP/b+qlq/6y9kkeZnF0u5ddZyRRqKPcUaxdzZ+liADainIop3eC rPZoZtvfgzRFZMt8eITNyBMH/z5+iwV35ZJbbbkiMr2ZHmfeVj1ydRN4jh5IKF+B lAiNdWCHzZZS0Yetopi+uODbT1hvP+KeJkHjVRdu6jvN7ieqRz82O25TXgK4ZRGs oWPgDD32yfldHVLzYLF92YPWEJzzA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrtdeigddugeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtgfgguffhjgffkfhfvffosehtqh hmtdhhtdejnecuhfhrohhmpeetlhgvgigvhicuofgvlhhnihhkohhvuceorggrmhgvlhhn ihhkohhvsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtthgvrhhnpeekveejteekhf dvgeekhfffhefhffevtefhgedvhfffvdeftefgfeejjedtfefgheenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfh grshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 9 Jul 2021 16:19:46 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Alexey Melnikov In-Reply-To: Date: Fri, 9 Jul 2021 21:19:45 +0100 Cc: Alexey Melnikov , emailcore@ietf.org Message-Id: References: To: dcrocker@bbiw.net X-Mailer: iPad Mail (18F72) Archived-At: Subject: Re: [Emailcore] Ticket #42: G.12. Extension Keywords Starting in 'X-' X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 20:19:55 -0000 Hi Dave, > On 9 Jul 2021, at 18:28, Dave Crocker wrote: >=20 > =EF=BB=BFOn 7/9/2021 6:11 AM, Alexey Melnikov wrote: >> I would like to start a discussion on ticket #42 says: >=20 > When X- was suggested, during RFC 822's development -- and I wish I could r= emember who came up with the idea -- it seemed clever and useful. I still t= hink it was clever, but we learned that it had problematic downsides. Hence= the later deprecation. >=20 > The entire idea of syntactic support for 'private' constructs has proved p= roblematic. And so, yes, it should be removed, wherever possible. >=20 > Also wherever possible, we've learned that the simplest and most construct= ive model is for: >=20 > 1. Extensible naming >=20 > 2. An ability (but not requirement) for registering names and > associating a specification, with registration reserving the name and > its meaning. >=20 > 3. Standardization of names that are, or are expected to be, important > to service operation >=20 > 4. A meta-rule to ignore a name that is not undersstood. Agreed so far. >=20 > As such, the 'SHOULD' that is suggested here seems to go farther than nece= ssary. SHOULD is supposed to be for things that will break, if you don't co= nform to the should, unless you /really/ know what you are doing. This does= n't seem to be a case of that. The SHOULD requirement to register extensions with IANA improves interoperab= ility and general reuse of good ideas, so I think it is warranted. Do you have a counter proposal? Best Regards, Alexey= From nobody Fri Jul 9 13:44:59 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262AD3A2E68 for ; Fri, 9 Jul 2021 13:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 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.338, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiFr00UcbEdb for ; Fri, 9 Jul 2021 13:44:52 -0700 (PDT) Received: from hedgehog.birch.relay.mailchannels.net (hedgehog.birch.relay.mailchannels.net [23.83.209.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159CA3A2E66 for ; Fri, 9 Jul 2021 13:44:51 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 66AA2341A29; Fri, 9 Jul 2021 20:44:50 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (100-96-16-89.trex-nlb.outbound.svc.cluster.local [100.96.16.89]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 118DE342B05; Fri, 9 Jul 2021 20:44:49 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.16.89 (trex/6.3.3); Fri, 09 Jul 2021 20:44:50 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Harmony-Dime: 0045b117126f85f8_1625863489716_3164731075 X-MC-Loop-Signature: 1625863489716:95082471 X-MC-Ingress-Time: 1625863489716 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 8F3E210027FE; Fri, 9 Jul 2021 20:44:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1625863487; bh=2DvlOv2E9f8aHuFzLkooqV5Z3Eb8b55rT9+K+UZy24M=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=mQZQCItle3Of71JeTBqlbF4Z1g5DaaLIDdU7e4tRgjcVgRUpb2NSpx5F4UrhrmZZU MmXn8bkfrprirkB+jb5qfFcC0AdoPgSC3p4xiraJDmb0qUR+2pyxAxPS1j1zE2GCKe gPhI22omva6ubH+k/oeU+R/VDe6hMV1rxd93PzYi7cxJDsGbu9nwwj2KYR5nSy5Xeq OX9EBtTgP+oSvyVoAMxYBhTxyWGoaqZPwKA4uyJJdGttKhg1mmyMjbzn1M3DBfeq5z IqeAZK551+xYrp8iOzQhDsUTt+TTpFiyN0dY6F9Zr7GvGPjwIxSLjvzBYZCbgd0kCM RguCzN4kxjPzg== Reply-To: dcrocker@bbiw.net To: Alexey Melnikov , dcrocker@bbiw.net Cc: Alexey Melnikov , emailcore@ietf.org References: From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Fri, 9 Jul 2021 13:44:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.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 #42: G.12. Extension Keywords Starting in 'X-' X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 20:44:57 -0000 On 7/9/2021 1:19 PM, Alexey Melnikov wrote: >> As such, the 'SHOULD' that is suggested here seems to go farther than necessary. SHOULD is supposed to be for things that will break, if you don't conform to the should, unless you/really/ know what you are doing. This doesn't seem to be a case of that. > The SHOULD requirement to register extensions with IANA improves interoperability and general reuse of good ideas, so I think it is warranted. > > Do you have a counter proposal? We don't have a SHOULD for registering header fields, why have one here? The view that registration improves interoperability has obvious appeal, but the counter is that it imposes a burden to adoption. That is, for someone considering creating an enhancement, they face the SHOULD. Again, a SHOULD makes sense when there is a clear and present danger to non-compliance. But as a general, coercive technique, I think it's actually a net-negative. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jul 9 19:14:54 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEDD3A14E6 for ; Fri, 9 Jul 2021 19:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_LOW=-0.7, 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=ZYiRSulc; dkim=pass (2048-bit key) header.d=taugh.com header.b=sw4on8z0 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 PV3WSQdY4Z4c for ; Fri, 9 Jul 2021 19:14:46 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC633A14E5 for ; Fri, 9 Jul 2021 19:14:45 -0700 (PDT) Received: (qmail 77781 invoked from network); 10 Jul 2021 02:14:43 -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=12fd3.60e90293.k2107; bh=Y+afyUdQTF3vfMwi3KD2ULjHXGs5pm70ordeQsbl5W0=; b=ZYiRSulceSMJD3DCM2cqXHFa+K53tuZ3iOrBajYf0pDNFsj2Jv284oSaY37/gPpKQqf6LoKoYbsCn1MRaD8841E5+qgGDOGSdzVxc4h+yV9obxQHbmM1cUPMYDwvZUblDhlbXoJ2Rub4zZ+E2VWQuNuq2oPsxsYQoS2SyPfcDWM9/wye7k8aGkh5NVFmWvWbSCuw229pTzmg6nANU5mh18IZ5UJjBpet8XVftib2HCZbpjGPsUDYcTWId+GwA1IQ+UWiEnsBzytt1u9DF5hkyxSVZTEuToIaCDqHTqe+Epsrs0opZlLIw7TTqwKTCAz3cNEABiCJjJaUadzjNxLiOw== 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=12fd3.60e90293.k2107; bh=Y+afyUdQTF3vfMwi3KD2ULjHXGs5pm70ordeQsbl5W0=; b=sw4on8z0S/VwIhxTjKNHJA73dw80CIsqDsOBlFO0sC0dCxWomuBBNs/TmvmkWEJys6zF9bnP9ngouxllmPvoIfyWA8vw069qi+U4K0UpLhyVct9iy/ZgNM2GtD9QApVAapYYoyGrjR+c6ZddsmWRd8wBxRMC/YYFujsnsw+vaEhKKwXcw5UBbQV7IGsZT0Q1VZ7QLjTMBBn650u6y4eNbIDggk38KGX7PMH/Y2f510E/mZpAvIU1mKpHOmOdgWQKdSnYI2xU0RBJ7xAhdB5bunaJKmdB0De9gQBrOrYpoQ30jW3XzLJHFOXZmyWGuLuZYngDHL249jbSKfQqlrG4sQ== 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; 10 Jul 2021 02:14:43 -0000 Received: by ary.qy (Postfix, from userid 501) id 767B91F91165; Fri, 9 Jul 2021 22:14:42 -0400 (EDT) Date: 9 Jul 2021 22:14:42 -0400 Message-Id: <20210710021442.767B91F91165@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: alexey.melnikov@isode.com In-Reply-To: <7da76485-2472-4807-d10c-73ced365e672@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 #7: trace header fields - lone Return-Path case 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, 10 Jul 2021 02:14:51 -0000 It appears that Alexey Melnikov said: >I would like to poll the WG about whether messages with lone >Return-Paths are generated in the wild. If they are, the ABNF should >probably be relaxed. Sometimes if they are generated and delivered on the same system. Of course, then they haven't used SMTP. R's, John From nobody Fri Jul 9 19:44:05 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A763A15FE for ; Fri, 9 Jul 2021 19:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 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.338, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-AHaBWP86aB for ; Fri, 9 Jul 2021 19:43:57 -0700 (PDT) Received: from buffalo.birch.relay.mailchannels.net (buffalo.birch.relay.mailchannels.net [23.83.209.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C203A15FF for ; Fri, 9 Jul 2021 19:43:57 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 79B0E84117C; Sat, 10 Jul 2021 02:43:56 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (100-96-27-225.trex.outbound.svc.cluster.local [100.96.27.225]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 3C1EA8412AF; Sat, 10 Jul 2021 02:43:55 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.27.225 (trex/6.3.3); Sat, 10 Jul 2021 02:43:56 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Cure-Tart: 08898f36372c29c5_1625885036121_1080131636 X-MC-Loop-Signature: 1625885036121:1752861330 X-MC-Ingress-Time: 1625885036120 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 2F390110F424; Sat, 10 Jul 2021 02:43:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1625885034; bh=kAr5eOiOQQ6OeOZOAycNTCEwLtlrGyMo/N3Ti+6NlRs=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=hctIuBt6jqEgJiilcitE0DybxDA3QNwt6DxuCx74O/WMsvxzLYd7WvTCKlauZkdLA wC6jkB1ayOT2CMTiToXmq+6eBDqQ7PBHluApSUVrhR4OpxcFG5YWf+Fe9ElPmKIrHH wEYE1nVYXcUgiMZ9H86AQjYAecB+iY849jMPCgr5Bh4rb+vegyQVyY7Xsbf895334k W5pJZ7Jy7b66Voo2c0+kZet4o8uhZR/zntZArVouQDAgYU8m3alLKyxVOGZ1Lch8Ou RdxDbJZpvPfB8xvl58Gyv2iLh+cAUjwCJew5bm9eUT6VBJytNehcEzr3iCp2WZFEpQ O2B+7Gd8fkxNw== Reply-To: dcrocker@bbiw.net To: John Levine , emailcore@ietf.org Cc: alexey.melnikov@isode.com References: <20210710021442.767B91F91165@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <583ba8e4-baec-5fe5-e25f-b2c8f28258e2@dcrocker.net> Date: Fri, 9 Jul 2021 19:43:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210710021442.767B91F91165@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #7: trace header fields - lone Return-Path case 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, 10 Jul 2021 02:44:03 -0000 On 7/9/2021 7:14 PM, John Levine wrote: > Sometimes if they are generated and delivered on the same system. Of course, > then they haven't used SMTP. but then, the email object doesn't require SMTP (and, really, never has...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jul 9 20:03:31 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DC33A16EA for ; Fri, 9 Jul 2021 20:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=MpmW6VT1; dkim=pass (2048-bit key) header.d=taugh.com header.b=fDivNlu9 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 JSBB-AKUm2B9 for ; Fri, 9 Jul 2021 20:03:17 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC39B3A16CE for ; Fri, 9 Jul 2021 20:03:16 -0700 (PDT) Received: (qmail 85009 invoked by uid 100); 10 Jul 2021 03:03:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:cleverness; s=14c0e.60e90df3.k2107; i=johnl@user.iecc.com; bh=kz3sx3HOjNQFwQxFoz0tJWjJfhRQ8FsnS2lhSzALzYY=; b=MpmW6VT1c9dttjHLldXcEzJzePHqIZPukmcOLmOQnHMtQ91nfdnT1g2/kRCy4Js6xDGUzYHqeBxS0orf/IgCfdFMYFXkRE3EQbOHJ32JXPVsORSBhOQ3plP+Mb46LJoyuvEnTd2eqm9VTFfmRdXNhCEAqlAQwz6WzVO/F/TpaYXcIHh+fHav+tGEjcKHUMrrlFa8wCepOp88XcOlS/GoGlOjij2m7eZa68/NYg2CbiyQ1nULZYvp3fepS/is9PlKOAGe7vg+Wdi0x5bOn6GxAp9tOEmtzMo3pC4lieULchLm8vvbrSQCBuj1fyNdh7xmwiaIRHZcYzbR9Fj6POlMHA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:cleverness; s=14c0e.60e90df3.k2107; olt=johnl@user.iecc.com; bh=kz3sx3HOjNQFwQxFoz0tJWjJfhRQ8FsnS2lhSzALzYY=; b=fDivNlu9IGNfCJLK7Xua5peh/7FO/XRtbG4fXEbWAwIB3xSsDw2g8VaXxYroWiSNVHRoq/lqLBx+H8T5rpx3lTP0MkEjpaGDHltXhFV8TIaFCCQT8WR9IFIpgE5n7siRBBR0fzJlidVeCLN31bg59y9m9SseCG/FowM6aVcXF49XQR/3bUZ6paluS8pJh2lJqG2HdbOwUte3qsB1+NCjk12lUXdkN60kKu1ky8Js8qoNye9pW9JeUnkFMEMHzKT3gbn+pypIFAfWZnz5pToxf7cTSK6WfFQr62IA0ed9g8LF+4Dq7W3Idk35PK1T6B0Y4TRnTtpbQhX/XQAEsfkaAA== Date: 9 Jul 2021 23:03:15 -0400 Message-ID: <226edd8a-7cf-4339-d89-e3c1dc11ee4@taugh.com> From: "John R Levine" To: dcrocker@bbiw.net Cc: emailcore@ietf.org, alexey.melnikov@isode.com In-Reply-To: <583ba8e4-baec-5fe5-e25f-b2c8f28258e2@dcrocker.net> References: <20210710021442.767B91F91165@ary.qy> <583ba8e4-baec-5fe5-e25f-b2c8f28258e2@dcrocker.net> Cleverness: None detected MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] Ticket #7: trace header fields - lone Return-Path case 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, 10 Jul 2021 03:03:30 -0000 > On 7/9/2021 7:14 PM, John Levine wrote: >> Sometimes if they are generated and delivered on the same system. Of >> course, then they haven't used SMTP. > > but then, the email object doesn't require SMTP (and, really, never has...) Sure, but the messages are still in RFC 5322(bis) form and it would be nice if the MUAs that handle messages that arrived via SMTP can also handle ones that were sent locally. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From nobody Fri Jul 9 20:33:16 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B73D3A1858 for ; Fri, 9 Jul 2021 20:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 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.338, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_BLOCKED=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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YcndiKOPbrA for ; Fri, 9 Jul 2021 20:33:09 -0700 (PDT) Received: from black.elm.relay.mailchannels.net (black.elm.relay.mailchannels.net [23.83.212.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDC03A1856 for ; Fri, 9 Jul 2021 20:33:08 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 09A8F36013E; Sat, 10 Jul 2021 03:33:07 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (100-96-16-89.trex-nlb.outbound.svc.cluster.local [100.96.16.89]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 2EB30361D43; Sat, 10 Jul 2021 03:25:46 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.16.89 (trex/6.3.3); Sat, 10 Jul 2021 03:25:46 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Name-Zesty: 3df0fe4173e63f70_1625887546789_1342575330 X-MC-Loop-Signature: 1625887546788:300985329 X-MC-Ingress-Time: 1625887546788 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 0CAFC10E9CD3; Sat, 10 Jul 2021 03:25:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1625887545; bh=RFQ1JfGxlJ0FkAEcz42Bw3qn0U8R+3+D96dYG1p86mo=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=hnWzDhs8ddRl65n9c9BWFamuaGUbrLB8GZNvkHvUXffhOiQY2KW1d8dHpet+/FOsE 2nCd1y5U3qNQZMyFX7nSburshPIzqh9Y4qau6NJHuhGrhE83JAb1fjblFI1zPa0+m7 EFNBRl0pcrW4vzuMB59kdWJFzGPk/NMhCAqCFnwLKdb8dQOOL2ayUfmRBoGSp5kdi/ 5G/VU77DatPgZxzvwD9g+anx8OAxg1HvRjkV4sGUea6QRez1oFYCCtT1C7PqzycCVr BXqtijkVocIHVpaELUbBzgkPEMyGm/ojTcVXV4V/e3DNWd3u2K594o2fInjrvwDbnY yWwIryuIZ/Lww== Reply-To: dcrocker@bbiw.net To: John R Levine , dcrocker@bbiw.net Cc: emailcore@ietf.org, alexey.melnikov@isode.com References: <20210710021442.767B91F91165@ary.qy> <583ba8e4-baec-5fe5-e25f-b2c8f28258e2@dcrocker.net> <226edd8a-7cf-4339-d89-e3c1dc11ee4@taugh.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <9094e629-5978-cd27-bf65-9ff2a8f95c80@dcrocker.net> Date: Fri, 9 Jul 2021 20:25:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <226edd8a-7cf-4339-d89-e3c1dc11ee4@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #7: trace header fields - lone Return-Path case 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, 10 Jul 2021 03:33:14 -0000 On 7/9/2021 8:03 PM, John R Levine wrote: > Sure, but the messages are still in RFC 5322(bis) form and it would be > nice if the MUAs that handle messages that arrived via SMTP can also > handle ones that were sent locally. I think that that was my point. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jul 9 20:59:39 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67D93A1983 for ; Fri, 9 Jul 2021 20:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=iy1WpztY; dkim=pass (2048-bit key) header.d=taugh.com header.b=OY7eKaUF 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 MPUoB4hkrmZc for ; Fri, 9 Jul 2021 20:59:31 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A463A1982 for ; Fri, 9 Jul 2021 20:59:30 -0700 (PDT) Received: (qmail 94782 invoked from network); 10 Jul 2021 03:59:30 -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=1723c.60e91b22.k2107; bh=Iyl/7viyYgcWoQtzks+oJM+UgMaef5NCsurQ/3MWodY=; b=iy1WpztY6LBdMbjpTZ9o2PRv6iOa7JoqVVMbwZlVGxaDdiQ1UzcoTkqogJlB5SM+yw9SE1rJNRjRjKU++ypNuVaPqv4+tmpflDcfKNO2HcGYk2P3sFfsYl4s6dPwOwYkx3E3EncixmYcFK42UU2+D3Y9IFM2REjQ6a2fq8rWOx5ZnGjbc3Vk3n+AGcENB/uZCGz2xeVSYxRxLA0kyLhYNC/eL6XBEnUAu33ZAU6r7HcI3aA8RfnMkDwLP7H04nG1fNJBm3k5vB27vOcBt0vjSGGnICHEYL19EH+YwOvbrjGY63+jIg8lgiq+IbE5+nCvXwOXZU0SInkJs6EshfC1sQ== 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=1723c.60e91b22.k2107; bh=Iyl/7viyYgcWoQtzks+oJM+UgMaef5NCsurQ/3MWodY=; b=OY7eKaUFNu1g3lgVWKEVptUqp8e7t4xICUhkVW3lyfU09dSkJ/nOFkO9I4b9dQJnVUY5ww+7IIwU4tnfPb5DN2t9bdHLLj3lcLhvsEtMs9SB2kBWSFuv1nMz6I8Z+OSygVlEh5I6CMnvleXQYywCPrw3VmOnOYIaOI0tw5cp2D7eEzMM6v9h/QBj7kxJFGolHKHSB2IZYsXvXm4GP4b18G8yUTpmPhVntTI8hSg+PwponwpWCYYvNmnTyg7X7162e3LsyBPT/uu6uSTnfhzApMz+jSWTaKN4O+Myz+Vmk7F9RtNFqU0wSqMG5RlxRB5VjvGcYlZKqaql6vC+2XU7rg== 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; 10 Jul 2021 03:59:29 -0000 Received: by ary.qy (Postfix, from userid 501) id 9858F1F9D7D2; Fri, 9 Jul 2021 23:59:28 -0400 (EDT) Date: 9 Jul 2021 23:59:28 -0400 Message-Id: <20210710035928.9858F1F9D7D2@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: michael@linuxmagic.com In-Reply-To: <6df9293d-6d14-d075-1715-2068258addc2@linuxmagic.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 #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 10 Jul 2021 03:59:37 -0000 It appears that Michael Peddemors said: >On 2021-07-09 12:24 p.m., Todd Herr wrote: >> I propose the following as a strawman... >> >> Change the above paragraph to read as follows: >> >>    An SMTP server MAY verify that the domain name argument in the EHLO >>    command has an address record matching the IP address of the client. >Not to mention, we still see far too many valid uses of EHLO that do not >conform to that. On the public Internet? Really? I agree you see all sorts of crud in submission and within private networks, but in SMTP relay to an MX, I don't think I see any hosts that EHLO without a valid name, at least not any from which I would want to receive mail. R's, John From nobody Fri Jul 9 21:06:43 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E913A19ED for ; Fri, 9 Jul 2021 21:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Zd4nAxzg; dkim=pass (2048-bit key) header.d=taugh.com header.b=E4cTqSXh 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 thxSYsISi-2I for ; Fri, 9 Jul 2021 21:06:34 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A8D3A19EB for ; Fri, 9 Jul 2021 21:06:33 -0700 (PDT) Received: (qmail 96070 invoked from network); 10 Jul 2021 04:06:33 -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=17743.60e91cc9.k2107; bh=5enNw/Kj7A/20YVedelhDdAilV8wWxhqthxkTxPKosM=; b=Zd4nAxzgJ5qsR0yn6q2mrAzNSX5P+ExWkqNm0wfZ2xCcdpsZOqwPZicP8j5sBio4cGcRTqmOvicvoSBtnU05xs74xyI+GGuB0ySDqA0OFsCk4ky29VwrA+9lr+jLjwNEWXFqRuDkYdW03NTIDkBIjjZJo6AgkJ+C2J/wf4sJEOXICafSxtk4P+WAVTt4u5D4ZiIdVXmRv+GaWyu5+WV2YuJiKYIStKJY03CglcDZfTz1n9PR5AY0ONux6mwRN+NfUjZS5scjt8WGPBnaK5DVlIUQr96HoVNGhIobCTjZ9gCACjZPw7qzzV/uVw2r94x/DzpfFG4R9UP/ADNF18QYSA== 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=17743.60e91cc9.k2107; bh=5enNw/Kj7A/20YVedelhDdAilV8wWxhqthxkTxPKosM=; b=E4cTqSXhVPWd2WXtqR6z18/TkytADBXmXlJwoOZStcCjAkD4oewjweku2czqyuSqdL4O5sHcv4qJD8v6XXpXn8njgEfC5PB1C12HuKNTbpJEs/SbgAISuphw87JBG1u2LO1M+GYPODT3M6eBJlkpIjWsBlbYPdeMzt0P7DpmHv/1QV5JSVa7gsceUAoLctoAC8vsRjKvaN3fboi75jPDc7yBzjo2+vSYOmXKAgMg2BpCBGj2wcgsjMw0D+CQ2MvLYutZrywwXD+iXKoqlKgaByzHomoYHLFZnalmBf4hg2fsLOZJX4LuMKPd5DOUIjeI3jqf/f4AjBMpdSUSPjEnwA== 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; 10 Jul 2021 04:06:32 -0000 Received: by ary.qy (Postfix, from userid 501) id D6B651F9E80F; Sat, 10 Jul 2021 00:06:31 -0400 (EDT) Date: 10 Jul 2021 00:06:31 -0400 Message-Id: <20210710040631.D6B651F9E80F@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #42: G.12. Extension Keywords Starting in 'X-' 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, 10 Jul 2021 04:06:40 -0000 It appears that Dave Crocker said: >On 7/9/2021 1:19 PM, Alexey Melnikov wrote: >>> As such, the 'SHOULD' that is suggested here seems to go farther than necessary. SHOULD is supposed to be for things >that will break, if you don't conform to the should, unless you/really/ know what you are doing. This doesn't seem to be a >case of that. >> The SHOULD requirement to register extensions with IANA improves interoperability and general reuse of good ideas, so I >think it is warranted. >> >> Do you have a counter proposal? > >We don't have a SHOULD for registering header fields, why have one here? Presumably to avoid colliding with other people who would use the same header name for something else. It's not like we're in any danger of running out of name strings. It might be interesting to Graham Klyne whether he gets a lot of requests for provisional header registrations and how extensive his expert review is. R's, John From nobody Fri Jul 9 21:45:05 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB8E3A1BB9 for ; Fri, 9 Jul 2021 21:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 SfeFYDhzNrZ7 for ; Fri, 9 Jul 2021 21:45:01 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 78F133A1BBD for ; Fri, 9 Jul 2021 21:45:01 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 56CF5D7485; Sat, 10 Jul 2021 00:45:00 -0400 (EDT) Date: Sat, 10 Jul 2021 00:45:00 -0400 From: Viktor Dukhovni To: emailcore@ietf.org Message-ID: Reply-To: emailcore@ietf.org References: <7da76485-2472-4807-d10c-73ced365e672@isode.com> <20210710021442.767B91F91165@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210710021442.767B91F91165@ary.qy> Archived-At: Subject: Re: [Emailcore] Ticket #7: trace header fields - lone Return-Path case 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, 10 Jul 2021 04:45:04 -0000 On Fri, Jul 09, 2021 at 10:14:42PM -0400, John Levine wrote: > It appears that Alexey Melnikov said: > >I would like to poll the WG about whether messages with lone > >Return-Paths are generated in the wild. If they are, the ABNF should > >probably be relaxed. > > Sometimes if they are generated and delivered on the same system. Of course, > then they haven't used SMTP. Also, some MSAs are configured to suppress addition of a local "Received: " header for privacy or other reasons. If the message is then delivered locally (even if submitted via SMTP, i.e. SUBMIT) it may then have just a lone "Return-Path:", with no other trace headers. One would however typically expect some of "From:", "Date:", "Message-ID:" to be present, but these are not trace headers. Also, FWIW, "Return-Path" is not typically sent in SMTP messages, it is typically instead added on final delivery to a mailbox, recording whatever the envelope sender appeared to be at that time. So while "in transit" such a message has no trace headers at all. -- Viktor. From nobody Fri Jul 9 22:11:48 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13563A1D03 for ; Fri, 9 Jul 2021 22:11:46 -0700 (PDT) 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 UKBctGOea-fc for ; Fri, 9 Jul 2021 22:11:41 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30233A1D02 for ; Fri, 9 Jul 2021 22:11:40 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m25H7-000F7A-I8; Sat, 10 Jul 2021 01:11:37 -0400 Date: Sat, 10 Jul 2021 01:11:32 -0400 From: John C Klensin To: Alessandro Vesely , emailcore@ietf.org Message-ID: In-Reply-To: References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> <01S14QJWN146005PTU@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 10 Jul 2021 05:11:47 -0000 --On Thursday, July 8, 2021 16:41 +0200 Alessandro Vesely wrote: >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A mail transaction may be = aborted by the RSET, a >>>> new =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EHLO, or the QUIT = command. SMTP extensions >>>> (see Section =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.2) may create = additional commands >>>> that abort or = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 end the = transaction. >=20 >=20 > Well, since that mentions aborting and ending the transaction, > why don't they also mention starting it? Nit successfully picked; text changed. john From nobody Sat Jul 10 00:40:11 2021 Return-Path: X-Original-To: emailcore@ietf.org Delivered-To: emailcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A393A163B; Sat, 10 Jul 2021 00:40:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emailcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <162590280941.26660.14036501955820232773@ietfa.amsl.com> Date: Sat, 10 Jul 2021 00:40:09 -0700 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5321bis-03.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jul 2021 07:40:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Revision of core Email specifications WG of the IETF. Title : Simple Mail Transfer Protocol Author : John C. Klensin Filename : draft-ietf-emailcore-rfc5321bis-03.txt Pages : 116 Date : 2021-07-10 Abstract: This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. This document replaces the earlier version with the same title in RFC 5321. [[CREF1: Note in Draft: Except for the last sentence, the above is unchanged from 5321 and may need adjusting in the light of RFC 6409 (Message Submission) as an Internet Standard.]] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5321bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-rfc5321bis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 10 00:46:03 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD52E3A16B3 for ; Sat, 10 Jul 2021 00:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtEThYIV7Bpm for ; Sat, 10 Jul 2021 00:45:59 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8BE03A16B2 for ; Sat, 10 Jul 2021 00:45:59 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m27gU-000FTD-MP for emailcore@ietf.org; Sat, 10 Jul 2021 03:45:58 -0400 Date: Sat, 10 Jul 2021 03:45:53 -0400 From: John C Klensin To: emailcore@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Emailcore] draft-ietf-emailcore-rfc5321bis-03 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, 10 Jul 2021 07:46:02 -0000 New version of draft-ietf-emailcore-rfc5321bis posted. See change log for differences and/or run a diff. Error reports on the change log as well as the substance welcome. To avoid surprises with recent discussion (and quoting from the change log): Note for this particular draft only: Notes were posted to the list on 2021-07-09 about tickets #7, #10, #14, #19, #20, $30, and #42. Even though some comments about them appeared in the subsequent day or so, there appears to have been insufficient time for discussions to stabilize sufficiently for changes to be included in this version of the I-D. --john From nobody Sat Jul 10 00:46:16 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E423A16B4 for ; Sat, 10 Jul 2021 00:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdLbbJRb7r-f for ; Sat, 10 Jul 2021 00:46:13 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59B23A16B7 for ; Sat, 10 Jul 2021 00:46:13 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m27gi-000FTI-Gv for emailcore@ietf.org; Sat, 10 Jul 2021 03:46:12 -0400 Date: Sat, 10 Jul 2021 03:46:07 -0400 From: John C Klensin To: emailcore@ietf.org Message-ID: In-Reply-To: <01S15IV3PJV0005PTU@mauve.mrochek.com> References: <82496eff-9533-5f38-8e73-7c266e1a768f@dcrocker.net> <01S14QJWN146005PTU@mauve.mrochek.com> <01S15IV3PJV0005PTU@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 10 Jul 2021 07:46:15 -0000 Ok. I have tried to capture this thread to the best of my ability. Once the -03 version of the I-D appears, please review and make additional suggestions as needed, subject to two observations from the editor: * As concerns the text about what future specifications can and cannot do, the intent is to make a specific warning about a very specific type of change that other sections of the document call out (the SMTP extension mechanism) and to impose an additional requirement on any extensions that change the transaction model. IMO (see below), at least some of the suggestions to further generalize that text would move it toward the meaningless handwaving to which other suggestions objected. * Both in the hope of helping the WG move forward and to preserve my sanity as editor (I value the latter, opinions of others may differ), proposed substitutions of new text for text I believe is already clear and that do not suggest changes with substantive, rather than editorial, effect are likely to be ignored unless explicitly endorsed by at least one person other than the author of the suggestion. Those who make suggestions but disagree with my treatment of them are free to (and probably should) ask the co-chairs to either assign tickets, make consensus calls, or both. FWIW, my criterion for "substantive" is fairly low. For example, I believe noticing that the text had talked about aborting and ending but not starting was a good catch. On the other hand, I'm not convinced that trying to find-tune text to make it extra clear that aborting a session also ends it would be a good use of people's time. The latter indication about how I intend to proceed is, of course, not limited to this particular topic. john (as editor) From nobody Sat Jul 10 00:49:32 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A9D3A16FD for ; Sat, 10 Jul 2021 00:49:30 -0700 (PDT) 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 RFykE6UpcIxR for ; Sat, 10 Jul 2021 00:49:26 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38BB53A16FB for ; Sat, 10 Jul 2021 00:49:26 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m27jo-000FU3-V9 for emailcore@ietf.org; Sat, 10 Jul 2021 03:49:24 -0400 Date: Sat, 10 Jul 2021 03:49:19 -0400 From: John C Klensin To: emailcore@ietf.org Message-ID: <5D84C913D9CE543BAF82865F@PSB> In-Reply-To: References: <5C50F3E6361F9E5AE613727B@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 10 Jul 2021 07:49:30 -0000 --On Tuesday, July 6, 2021 19:55 -0400 Viktor Dukhovni wrote: > On Tue, Jul 06, 2021 at 07:19:38PM -0400, John C Klensin wrote: > >> > I was wondering the same thing, but on reflection I think it >> > is clear that nothing in the server reply can extend the >> > scope of the transaction. The transaction may succeed, >> > fail, be terminated, or lead to an error state (a rejected >> > RSET or EHLO presumably precludes continuing with >> > subsequent transactions). >> >> Exactly. I suppose we could clarify further by saying that >> the server MUST respond to any of those commands/conditions >> with a 2yz code but Section 4.3 basically already says that. > > Well, not always 2yz, since ".", "RSET" or "EHLO" could fail > or be refused. IIRC it is "QUIT" for which "2yz" is the only > expected outcome. I don't understand how RSET could fail unless the server went outside the spec and considered it equivalent to QUIT, something that would leave things in an odd state wrt the session/ Connection. I suppose a server that paid no attention to the conventional wisdom or our advice about a second EHLO without an intervening RSET could respond to a second EHLO with "503 Bad sequence of commands". However, please note that, if we are going to start looking for those edge cases (I'm somewhat agnostic about whether we should), we are going to have to open and reexamine the command-reply sequences of Section 4.3.2. If you are convinced that is desirable (or necessary) I recommend opening a ticket. >> > So termination here refers to *commands* that terminate a >> > transaction. The fact that the client typically awaits a >> > response is implicit. (Clients might not wait for a QUIT >> > response, and might drop a connection after a successful >> > RSET if despite anticipating more traffic no further >> > messages are queued for the peer). >> >> Actually the current text requires (or is intended to require) >> that clients to wait except under unusual circumstances and >> then (deliberately) hand-waves about the definition of >> "unusual". I think that just strengthens your point. > > FWIW, this is another one of those things where practice > diverges from theory. Clients *DO* disconnect without waiting > for a "QUIT" response, and this is in practice well justified. > Clients also abruptly drop connections after a successful > "RSET" without sending "QUIT", when e.g. a cached connection > times out without new messages to send. > > Neither behaviour will change in, e.g., Postfix no matter what > the specification says. The server must be prepared to handle > lost connections, e.g. because of transport or network layer > issues, and the client may from time to time elect to > unilaterally close the transport. But I think the text already says that that server must be prepared for such things. As to the client, Whether we should change, e.g., the description of QUIT from the current text that strongly suggests that the client should wait for a reply to QUIT. Perhaps that stems from 821 being written in the time of a much more fragile network, but, while I imagine that few of us on this list regularly use fragile networks, they do still exist around the world. >> So, anyone want to argue that clarification is needed for this >> and, if it is, that it is important enough to justify added >> text? If so, proposed text would be appreciated because your >> friendly editor thinks it is fairly clear. > > I'm fine with the text re connection termination as-is. Thanks. I think it has been improved somewhat since you posted your note, but the improvements are, IMO, relatively small. best, john From nobody Sat Jul 10 00:50:23 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160463A170A for ; Sat, 10 Jul 2021 00:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.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 E_-KyhtW-moy for ; Sat, 10 Jul 2021 00:50:16 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB203A1708 for ; Sat, 10 Jul 2021 00:50:16 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id B69009F149; Sat, 10 Jul 2021 00:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1625903415; bh=XxJM3cOAx+RLFCzc/0OGL97O5eWUqXt/Gobn8fRc2bs=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=eB/qLu/4+EM0LQdbIFqQ9pG0oQiL5oyqKmjtOH8EYZsNjT6FeTPVgMPs8foVlu7qB /q/c3U5SvemEGG7FChKDwPS+sJXk+Fs52lkXY4XVANQc2lc+/LMoMmaEPJuotx/cD3 1oo14DDM8GPSVhxqpAg06SAqZcHLf0LFqVO08STA= From: Laura Atkins Message-Id: <1CAE2AD5-4732-4263-8360-4B71AE47377E@wordtothewise.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_77F4D476-3827-4EAB-A1AB-AF3AD6C660F0" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Sat, 10 Jul 2021 08:50:12 +0100 In-Reply-To: Cc: emailcore@ietf.org To: Todd Herr References: X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Emailcore] Ticket #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 10 Jul 2021 07:50:21 -0000 --Apple-Mail=_77F4D476-3827-4EAB-A1AB-AF3AD6C660F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 9 Jul 2021, at 20:24, Todd Herr = wrote: >=20 > Greetings. >=20 > I would like to begin a discussion on ticket #19 - = https://trac.ietf.org/trac/emailcore/ticket/19 = - as a long belated = follow on to discussion that was had during IETF 110. >=20 > Section 4.1.4 of draft-ietf-emailcore-5321bis includes this paragraph: >=20 > An SMTP server MAY verify that the domain name argument in the EHLO > command actually corresponds to the IP address of the client. > [[CREF13: [5321bis] [[Note in draft -- proposed change to "An SMTP > server MAY verify that the domain name argument in the EHLO command > has an address record matching the IP address of the client." = --David > MacQuigg, david_macquigg@yahoo.com = , Friday, 20090130 0637 -0700]]]] > However, if the verification fails, the server MUST NOT refuse to > accept a message on that basis. Information captured in the > verification attempt is for logging and tracing purposes. Note = that > this prohibition applies to the matching of the parameter to its IP > address only; see Section 7.9 for a more extensive discussion of > rejecting incoming connections or mail messages. > Discussion at IETF 110 = (https://codimd.ietf.org/notes-ietf-110-emailcore = ) landed on adding = text to the Applicability Statement regarding how mail might be rejected = if EHLO hostname doesn't resolve in DNS to IP address of SMTP client. >=20 > I propose the following as a strawman... >=20 > Change the above paragraph to read as follows: >=20 > An SMTP server MAY verify that the domain name argument in the EHLO=20= > command has an address record matching the IP address of the = client. >=20 > And include the following text in the Applicability Statement: >=20 > If the domain name argument in the EHLO command does not have an = address > record in the DNS that matches the IP address of the client, the = SMTP > server may refuse any mail from the client as part of established = anti-abuse > practice. Operational experience has demonstrated that the lack of = a matching > address record for the the domain name argument is at best an = indication of > a poorly-configured MTA, and at worst that of an abusive host. > Thoughts? Bit rot happens and can affect EHLO values. In fact, the number of = domains where the HELO doesn=E2=80=99t match the IP but does match a = different IP in the same cluster is significant based on my = investigations over the years. I=E2=80=99m never surprised when things = don=E2=80=99t match. I might tone down the judgement a little bit. The = lack of a matching address record isn=E2=80=99t =E2=80=9Cat best a = poorly-configured MTA=E2=80=9D. My experience suggests that it's more = likely at this point in time that abusive hosts match - as they=E2=80=99re= often programatically deployed and everything is set up to match. =E2=80=9COperational experience tells us that some types of abusive = hosts forge or otherwise fake a HELO value. SMTP operators may choose to = block systems based on the EHLO value mismatch=E2=80=A6=E2=80=9D=20 laura=20 > --=20 > Todd Herr | Technical Director, Standards and Ecosystem > e: todd.herr@valimail.com =20 > m: 703.220.4153 >=20 > This email and all data transmitted with it contains confidential = and/or 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. > --=20 > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_77F4D476-3827-4EAB-A1AB-AF3AD6C660F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 9 Jul 2021, at 20:24, Todd Herr <todd.herr=3D40valimail.com@dmarc.ietf.org> = wrote:

Greetings.

I would like to begin a = discussion on ticket #19 - https://trac.ietf.org/trac/emailcore/ticket/19 - as a = long belated follow on to discussion that was had during IETF = 110.

Section = 4.1.4 of draft-ietf-emailcore-5321bis includes this paragraph:

   An SMTP server MAY verify that the domain name argument in =
the EHLO
   command actually corresponds to the IP address of the client.
   [[CREF13: [5321bis] [[Note in draft -- proposed change to "An SMTP
   server MAY verify that the domain name argument in the EHLO command
   has an address record matching the IP address of the client." --David
   MacQuigg, david_macquigg@yahoo.com, Friday, 20090130 0637 -0700]]]]
   However, if the verification fails, the server MUST NOT refuse to
   accept a message on that basis.  Information captured in the
   verification attempt is for logging and tracing purposes.  Note that
   this prohibition applies to the matching of the parameter to its IP
   address only; see Section 7.9 for a more extensive discussion of
   rejecting incoming connections or mail messages.
Discussion at IETF 110 (https://codimd.ietf.org/notes-ietf-110= -emailcore) landed on adding text to the = Applicability Statement regarding how mail might be rejected if EHLO = hostname doesn't resolve in DNS to IP address of SMTP client.

I propose the following as a = strawman...

Change the above paragraph to = read as follows:

   An SMTP server MAY = verify that the domain name argument in the EHLO
  =  command has an address record matching the IP address of the = client.

And include the following text = in the Applicability Statement:

   If the domain name = argument in the EHLO command does not have an address
 =  record in the DNS that matches the IP address of the client, the = SMTP
   server may refuse any mail from the = client as part of established anti-abuse
  =  practice. Operational experience has demonstrated that the lack of = a matching
   address record for the the domain = name argument is at best an indication of
   a = poorly-configured MTA, and at worst that of an abusive = host.
Thoughts?
=

Bit rot happens and can = affect EHLO values. In fact, the number of domains where the HELO = doesn=E2=80=99t match the IP but does match a different IP in the same = cluster is significant based on my investigations over the years. I=E2=80=99= m never surprised when things don=E2=80=99t match. I might tone down the = judgement a little bit. The lack of a matching address record isn=E2=80=99= t =E2=80=9Cat best a poorly-configured MTA=E2=80=9D. My experience = suggests that it's more likely at this point in time that abusive hosts = match - as they=E2=80=99re often programatically deployed and everything = is set up to match.

=E2=80=9COperation= al experience tells us that some types of abusive hosts forge or = otherwise fake a HELO value. SMTP operators may choose to block systems = based on the EHLO value mismatch=E2=80=A6=E2=80=9D 

laura 

--

Todd Herr | Technical Director, Standards and = Ecosystem
e: todd.herr@valimail.com
m: 703.220.4153
This email = and all data transmitted with it contains confidential and/or = proprietary information intended solely for the use of individual(s) = authorized to receive it. If you are not an intended and authorized = recipient you are hereby notified of any use, disclosure, copying or = distribution of the information included in this transmission is = prohibited and may be unlawful. Please immediately notify the sender by = replying to this email and then delete it from your = system.
--
Emailcore mailing list
Emailcore@ietf.org
https://www.ietf.org/mailman/listinfo/emailcore

-- 
Having an Email Crisis? =  We can help! 800 823-9674 

Laura Atkins
Word = to the Wise
laura@wordtothewise.com
(650) = 437-0741 =

Email Delivery Blog: https://wordtothewise.com/blog =







= --Apple-Mail=_77F4D476-3827-4EAB-A1AB-AF3AD6C660F0-- From nobody Sat Jul 10 03:27:28 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AE33A0771 for ; Sat, 10 Jul 2021 03:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.795 X-Spam-Level: X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=fastmail.fm header.b=S8jDoJvt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BBZNN67k 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 P5o8F75NmSL0 for ; Sat, 10 Jul 2021 03:27:21 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98683A0778 for ; Sat, 10 Jul 2021 03:27:21 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 8F6A132001E9; Sat, 10 Jul 2021 06:27:18 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 10 Jul 2021 06:27:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-type:content-transfer-encoding:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; s=fm3; bh=5Ez/v5/ boQW7Dt93Yh8hZMtjT+9RWXF24AfPLS23l40=; b=S8jDoJvt4f4bFKJWXcUFAqm PArYiY6V2FJHxYcUufg4/MPPtynocqn3YyLR4tKN4MBqjk1EB0A/831etdagGz6p 1+6Xh0s36IdAmTjKo07lZtoN2thMRYuDouVhD7xvTRUssEwQWo7wLRSLmQgN3ZjR WfVhXJtS62a09A0Y1cBCFgzTIXw2B7Bf3bmgWSU7wioOAmbLBrJOvs8YT1+DpQDL HxMB1CcIVrbZNk5u6TwWEk4K81nbiRA2aYUQ/BkztB7BASbNU+maN7MiuPfeuChl f0FQSiGapLl3tuW0fNN8A2Pqh0HBTOnsyKf3FIIf6+Zt8Ml2ei4okwlKXVTJq/w= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=5Ez/v5/boQW7Dt93Yh8hZMtjT+9RWXF24AfPLS23l 40=; b=BBZNN67kMWW72jo6emWWo7uQXul77udxMFbt1HQZI1HwMGc8RI0yAW/ye gZtdW3eIlOknToQ5L1T8fM2UubesRsQ9lxKfb18bSGLAl7A86a8ACXBoiBqB+bxb KtLHGt2gxJfXVtYKbkNeh3y1iNsbx2u73K8dl/j38phbRGY13AhMWagULYyrhYM7 App91bZO4AkWFQsh3hj404c3W/N6ecLQ6WSW3V9Jeq5v/si3v/IhyQV/josY5EgL ODKVB9G49SrKW9IrNjVnKY+jbsMgwTer4COJ1obzZS75avgYVfwbdAFYHMFXELQ1 QOUbdVNzi90BdfhDUtkIHDOu420jw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrtdekgddvkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptgfgggfuhfgjfffkfhfvofesrgejmh erhhdtjeenucfhrhhomheptehlvgigvgihucfovghlnhhikhhovhcuoegrrghmvghlnhhi khhovhesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghrnhepgfettdfggfefhf ejieffvdevkeffgfetteehfefhjeevgeejvefhudehledvfeelnecuffhomhgrihhnpehi vghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 10 Jul 2021 06:27:16 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B4BCE266-FDFA-4E68-AAB1-7666763A3672 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Alexey Melnikov In-Reply-To: Date: Sat, 10 Jul 2021 11:27:15 +0100 Cc: emailcore@ietf.org Message-Id: <9F9214FA-3492-4A5A-88FA-494E9BC59F07@fastmail.fm> References: To: Todd Herr X-Mailer: iPad Mail (18F72) Archived-At: Subject: Re: [Emailcore] Ticket #10: Meaning of "resolvable FQDN" in Section 2.3.5 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, 10 Jul 2021 10:27:27 -0000 --Apple-Mail-B4BCE266-FDFA-4E68-AAB1-7666763A3672 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Todd, > On 9 Jul 2021, at 19:49, Todd Herr wrote: > =EF=BB=BF > Greetings. >=20 > I would like to start a discussion on ticket #10, which reads: >=20 >> In other words, names that can be resolved to MX RRs or address (i.e., A o= r AAAA) RRs (as discussed in Section 5) are permitted, as are CNAME RRs whos= e targets can be resolved, in turn, to MX or address RRs. > =20 >> It is not clear whether "In other words" really meant "for example" or it= is was (sic) intended that the only labels permitted are those that own rec= ords in one of the above RR types. >=20 >=20 > The proposal here is to change the text, replacing "In other words" with "= In particular", as follows: >=20 > OLD: >=20 > Only resolvable, fully-qualified domain names (FQDNs) are permitted > when domain names are used in SMTP. In other words, names that can > be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed > in Section 5) are permitted, as are CNAME RRs whose targets can be > resolved, in turn, to MX or address RRs. Local nicknames or > unqualified names MUST NOT be used. There are two exceptions to the=20= > rule requiring FQDNs: >=20 > NEW: >=20 > Only resolvable, fully-qualified domain names (FQDNs) are permitted > when domain names are used in SMTP. In particular, names that can > be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed > in Section 5) are permitted, as are CNAME RRs whose targets can be > resolved, in turn, to MX or address RRs. Local nicknames or > unqualified names MUST NOT be used. There are two exceptions to the=20= > rule requiring FQDNs: >=20 > Thoughts? (As a participant) I like this change, as it changes the text from an example to the definitive= list. Best Regards, Alexey >=20 > --=20 > Todd Herr | Technical Director, Standards and Ecosystem > e: todd.herr@valimail.com=20 > m: 703.220.4153 >=20 > This email and all data transmitted with it contains confidential and/or p= roprietary information intended solely for the use of individual(s) authoriz= ed to receive it. If you are not an intended and authorized recipient you ar= e hereby notified of any use, disclosure, copying or distribution of the inf= ormation included in this transmission is prohibited and may be unlawful. Pl= ease immediately notify the sender by replying to this email and then delete= it from your system. > --=20 > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore --Apple-Mail-B4BCE266-FDFA-4E68-AAB1-7666763A3672 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Todd,

On 9 Jul 2021, at 19:49, Todd Herr <to= dd.herr=3D40valimail.com@dmarc.ietf.org> wrote:
=EF=BB=BF
Greetings.
<= div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif">
I wou= ld like to start a discussion on ticket #10, which reads:

In other words, names that can be resolved to MX RRs or address&= nbsp;(i.e., A or AAAA) RRs (as discu= ssed in Section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs.
 
It is not clear whether "In other words" really meant "for example" or it is was (sic) intended that the o= nly labels permitted are those that own records in one of the above RR types= .

The pr= oposal here is to change the text, replacing "In other words" with "In parti= cular", as follows:

OLD:

  Only resolvable, fully-qualified domain names (FQDN=
s) are permitted
   when domain names are used in SMTP.  In other words, names that ca=
n
   be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
   in Se=
ction 5) are permitted, as are CNAME RRs whose targets can be
   resolved, in turn, to MX or address RRs.  Local nicknames or
   unqualified names MUST NOT be used.  There are two exceptions to the =
;
   rule requiring FQDNs:<=
/font>

NEW:

   Only resolvable, fully-qualified domain names (FQDNs) are permi=
tted
   when domain names are used in SMTP.  In particular, names that can
   be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
   in Se=
ction 5) are permitted, as are CNAME RRs whose targets can be
   resolved, in turn, to MX or address RRs.  Local nicknames or
   unqualified names MUST NOT be used.  There are two exceptions to the =
;
   rule requir=
ing FQDNs:

Thoughts?

(As a participant)
I like this change, a= s it changes the text from an example to the definitive list.

=
Best Regards,
Alexey

--

Todd Herr
<= b>e: todd.herr@valimail.com
m: 703.220.4153=

This email and all data transmitted with it contai= ns confidential and/or proprietary information intended solely for the use o= f individual(s) authorized to receive it. If you are not an intended and aut= horized 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 th= is email and then delete it from your system.

=
--
Emailcore mailing list
Emailcore@i= etf.org
https://www.ietf.org/mailman/listinfo/emailcore
= --Apple-Mail-B4BCE266-FDFA-4E68-AAB1-7666763A3672-- From nobody Sat Jul 10 03:32:29 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6A33A0891 for ; Sat, 10 Jul 2021 03:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=JZpAiisD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=czb1bIKZ 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 TfR6w7E98Poy for ; Sat, 10 Jul 2021 03:32:24 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232783A088A for ; Sat, 10 Jul 2021 03:32:24 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 37E603200258; Sat, 10 Jul 2021 06:32:23 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 10 Jul 2021 06:32:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-type:content-transfer-encoding:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; s=fm3; bh=M97qjZv jNI+YR3P+7yPNkk4gz8yC9sdO1Rr87Ycb0gE=; b=JZpAiisDDcbordimNYBcGU+ h6ykEaFB/ByEFLc36TJaak4uBNOjqf24SklYF5dMin0NfH4K0w1O10ncuPHJsiUx VD6cpOwH9OLCA3TgFJdfg/FXBbJKPd8F1Yb8umJ7BU51L4GFQFfBKNxpx3NJPLph uyJXPPZGW+TqgLelUrfddyN92dpJdjpQ5RdEW8COj+ee6iY8iUgQYTO4OhVgofDb 4B+lQ3SUCNCKvOTs4Dc290++K29W230gX7nnTbdOAcW+7IrQLYR3DOyW2xIpXyxc XsCMGvCvd2KoufHD+F54j8QUtEWF3euqsxJ8S0bMSA0uWVnPVxedIWEpKoPVRJA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=M97qjZvjNI+YR3P+7yPNkk4gz8yC9sdO1Rr87Ycb0 gE=; b=czb1bIKZfm5U5KO3l4akylj1WC7mS8MB/Zc6tFgx4cb4bFFqI6CKJKVDY GqgmJ9E+i+aT/kJPmr3UzXctNfN7IDSuHeLCLO7EB3VlUqAntB8jkB3c0cBA+V46 It78Q3yJ86dOAmNkgPvOLW+X04SPGW4JW0yV1B0Ng9SpgaE4G7qkYRi91ZrjoH+b BVgD81oOPETTlXtFckjQq+0o5YSj02sSboLNswPp6MjYzAtwCDA3plQfgwoPyfsx F6wcFjxRI+gsOsCq7mUFu9myIOk97ewQiYr/3O+FT5wAfA40K4HDQXLb7EwrO1NA OJbTiHcdfZ3VEBB6H/cxLp1iaO++A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrtdekgddvlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtgfgguffhjgffkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhgvgigv hicuofgvlhhnihhkohhvuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhmqe enucggtffrrghtthgvrhhnpeekleeuheelgedukedtleffudeftdegleekhfeitdekvdeu jefgtdeuvefftedttdenucffohhmrghinhepsggsihifrdhnvghtpdhivghtfhdrohhrgh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghm vghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 10 Jul 2021 06:32:22 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Alexey Melnikov In-Reply-To: <583ba8e4-baec-5fe5-e25f-b2c8f28258e2@dcrocker.net> Date: Sat, 10 Jul 2021 11:32:20 +0100 Cc: emailcore@ietf.org, alexey.melnikov@isode.com Message-Id: <8B27165E-FE5C-4E65-A629-30C4678D17DE@fastmail.fm> References: <583ba8e4-baec-5fe5-e25f-b2c8f28258e2@dcrocker.net> To: dcrocker@bbiw.net, John Levine X-Mailer: iPad Mail (18F72) Archived-At: Subject: Re: [Emailcore] Ticket #7: trace header fields - lone Return-Path case 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, 10 Jul 2021 10:32:29 -0000 > On 10 Jul 2021, at 03:44, Dave Crocker wrote: >=20 > =EF=BB=BFOn 7/9/2021 7:14 PM, John Levine wrote: >> Sometimes if they are generated and delivered on the same system. Of cou= rse, >> then they haven't used SMTP. >=20 > but then, the email object doesn't require SMTP (and, really, never has...= ) +1. Email format document has wider applicability than just SMTP. >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 > --=20 > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore From vijay96238@gmail.com Sat Jul 10 03:59:29 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3163A10AC for ; Sat, 10 Jul 2021 03:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBXe2p3tbr8s for ; Sat, 10 Jul 2021 03:59:27 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 2D7083A10A9 for ; Sat, 10 Jul 2021 03:59:27 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id c145so585499oib.2 for ; Sat, 10 Jul 2021 03:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Ma42IaNyMnxnvkNQXb58KWWiEcZ20PWT5FCsuD8GwGM=; b=TalCWVm3SkiTRqkhDUflD14HkcG39ljyQ0gYSvNitaTXxZ93RKoXl+to12Gktg/E4Y EC31VFXQQKvu1oJiN2uzy350AKpkcNWSRVNr6Hwtna57T1qOQZbKFrgABoS4gxYQsfPI uGKXwVc4qh8o19vHq8OwV9AmfHJvqg5b4B7O1rt9qQ0dEurgNBtX1RmAlS31MaMErlXj Szdycql/Vh7ERYehD+KulVInaPq/ijdYrtVBYHo/xoOsKzhtXhPYrI+mDBvBxkefFzSk cQ+gK8HZ0IytPdzamNFiXi59to5cAt+9OD2PQ+dn/X43aW29HKSvHeDC5WFZvOnMebQ3 ys3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Ma42IaNyMnxnvkNQXb58KWWiEcZ20PWT5FCsuD8GwGM=; b=a6Nj1twK4zWN58e5eeKJXm43uKmzENxbLlgtyjcvPij3ayWurFgaP3LIN/CdkQoC1L wXrnf6g4PKBPYqdH59/PJdD2zRUCQX2D7Cqc3B9AVlohqVBTVQ538mN771CANp0MuwIl VI+M0HSrvMdavX+Tf89n13vTIPA5BX2N7cOJM/xn/uOvTEVeW6Lca1JYE7TdknQzQlQN No47m97FqDLW2wqkeUvPgmNKzzyGQ6OiPQrconoMfYdrLzjKeDAd28cNL4k0baXb3QLw jy34l6LglYGo3qes4ahhK7CaZW5blcCzKum3ledUQj+aAA2j+mwRCEuXKH8URn3WWncC Styw== X-Gm-Message-State: AOAM533H4SheXZP8/ZAFK9AEUqnUfCuQ7YN3YJGd//WW+fz84zOfnjFd tyAP2Fv2fmngTXFt1duRuJS6fawJvyXemJa9WiAt4Tgl+ye75g== X-Google-Smtp-Source: ABdhPJzFsFdKIMjh4pezfO0VOcRGqOCwfYE/FhR9SuNtUhGfiI3vE67UpXJmATx1VCeh5l07GMPlKIX2od3UCDriifs= X-Received: by 2002:aca:1802:: with SMTP id h2mr2983388oih.146.1625914765810; Sat, 10 Jul 2021 03:59:25 -0700 (PDT) MIME-Version: 1.0 From: Vijay Patel Date: Sat, 10 Jul 2021 16:29:26 +0530 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="0000000000000d1f3f05c6c2c85b" Archived-At: Subject: [Emailcore] Additional fields to categorize email to reduce email storage cost 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, 10 Jul 2021 11:01:45 -0000 --0000000000000d1f3f05c6c2c85b Content-Type: text/plain; charset="UTF-8" Hi, Sincere thanks for maintaining internet standards. Background: Whenever I see my gmail account with lots of subscription emails, newsletters, and promotional mails, I get questions about how to manage and streamline them. Unsubscribe is definitely a simple option to get rid of it. Or spam filter options (by email provider). I am looking for an additional feature that mandates email sender to specify when the email can be deleted safely. Example-1: I get daily promotional emails for my bank account / debit card / credit card / spend on internet / offers / Investment services / Mutual funds / IPO / and a lot more. If these email messages carry specific fields to indicate it is Pure Promotional email, I believe it will help Gmail / Outlook Live / Yahoo to provide additional options to users (like me) to delete past emails which are not relevant after certain days. I believe this will lead to electronics resource saving (Storage cost / Backup management), Electricity savings, and reducing carbon footprint. Example-2: Newsletter emails Newsletter subscription might be driving a lot of email traffic on a daily basis. Can there be further categorization of email based on use cases? Example, A newsletter email may contain full body (html + latest features), but it shall also contain a link to persistent copy on the internet (to be managed by sender). This will allow to truncate the message after certain days. The challenge I am describing in this use case is more related to current roles and responsibilities owned by various stakeholders. Email providers are happy to provide free storage + huge limits . Email senders are not at all worried about sending thousands of emails per day and filling mailboxes. The movement, storage cost is added to email sender, genuine email senders (All large email publishing companies / newsletter senders - who are equally sensible about contributing to a better internet future) can play their good role. I am not sure if these issues can be discussed by the emailcore group. But surely, I am attempting to inform those who are actively working to make the internet a better place. Regards, Vijay Virus-free. www.avast.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> --0000000000000d1f3f05c6c2c85b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Sincere thanks for maintaining inte= rnet standards.

Background:
Whenever I s= ee my gmail account=C2=A0with lots of subscription emails, newsletters, and= promotional mails, I get questions about how to manage and streamline them= .

Unsubscribe is definitely a simple option to get= rid of it.
Or spam filter options (by email provider).

I am looking for an additional feature that mandates email = sender to specify when the email can be deleted safely.

Example-1: I get daily promotional emails for my bank account / debit= card / credit card / spend=C2=A0on internet / offers / Investment services= / Mutual funds / IPO / and a lot more.
If these email messages c= arry specific fields to indicate it is Pure Promotional email, I believe it= will help Gmail / Outlook Live / Yahoo to provide additional options to us= ers (like me) to delete past emails which are not relevant after certain da= ys.

I believe this will lead to electronics resour= ce saving (Storage cost / Backup management), Electricity savings, and redu= cing carbon footprint.=C2=A0

Example-2: Newsletter= emails
Newsletter subscription might be driving a lot of email t= raffic on a daily basis. Can there be further categorization of email based= on use cases? Example, A newsletter email may contain full body (html=C2= =A0+ latest features), but it shall also contain a link to persistent copy = on the internet (to be managed by sender). This will allow to truncate the = message after certain days.

The challenge I am des= cribing in this use case=C2=A0is more related to current roles and responsi= bilities owned by various stakeholders. Email providers are happy to provid= e free storage + huge limits . Email senders are not at all worried about s= ending thousands of emails per day and filling mailboxes. The movement, sto= rage cost is added to email sender, genuine email senders (All large email = publishing companies / newsletter senders - who are equally sensible about = contributing to a better internet future) can play their good role.

I am not sure if these issues can be discussed by the ema= ilcore group. But surely, I am attempting to inform those who are actively = working to make the internet a better place.

Regar= ds,
Vijay

3D"" Virus-free. www.avast.com
--0000000000000d1f3f05c6c2c85b-- From nobody Sat Jul 10 06:01:27 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E448A3A19CD for ; Sat, 10 Jul 2021 06:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 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_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 PE4cqK8Zpg0v for ; Sat, 10 Jul 2021 06:01:20 -0700 (PDT) Received: from plum.mrochek.com (bang.mrochek.com [98.153.82.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17C23A19CE for ; Sat, 10 Jul 2021 06:01:19 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1866PMXSG00HXSW@mauve.mrochek.com> for emailcore@ietf.org; Sat, 10 Jul 2021 05:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1625921775; bh=HiSKfigKaa8GKmzGbM5HMbCtRXAD/y6fFZrq0ODnot0=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Og2Po9QBJYAKibaZ0tE5N5bjnuUq2eHeCfEsFI8CKRkNbINMjN8mYD1go0KxMQYmG qKjp8TEgmKEMYzkPJOJI+tNXqyn5mf29O5A6FMkevduUei8uT2vu8HJvqLzSJTP6Gp 9cbHGjcantjG93bXbm2/wUzzCFfofxWIvm5LoV0E= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S0F3SXH38G005PTU@mauve.mrochek.com>; Sat, 10 Jul 2021 05:56:11 -0700 (PDT) Cc: Todd Herr , emailcore@ietf.org Message-id: <01S1866N0YP6005PTU@mauve.mrochek.com> Date: Sat, 10 Jul 2021 05:55:57 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 10 Jul 2021 11:27:15 +0100" <9F9214FA-3492-4A5A-88FA-494E9BC59F07@fastmail.fm> References: <9F9214FA-3492-4A5A-88FA-494E9BC59F07@fastmail.fm> To: Alexey Melnikov Archived-At: Subject: Re: [Emailcore] Ticket #10: Meaning of "resolvable FQDN" in Section 2.3.5 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, 10 Jul 2021 13:01:25 -0000 > Hi Todd, > > On 9 Jul 2021, at 19:49, Todd Herr wrote: > >  > > Greetings. > > > > I would like to start a discussion on ticket #10, which reads: > > > >> In other words, names that can be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed in Section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs. > > > >> It is not clear whether "In other words" really meant "for example" or it is was (sic) intended that the only labels permitted are those that own records in one of the above RR types. > > > > > > The proposal here is to change the text, replacing "In other words" with "In particular", as follows: > > > > OLD: > > > > Only resolvable, fully-qualified domain names (FQDNs) are permitted > > when domain names are used in SMTP. In other words, names that can > > be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed > > in Section 5) are permitted, as are CNAME RRs whose targets can be > > resolved, in turn, to MX or address RRs. Local nicknames or > > unqualified names MUST NOT be used. There are two exceptions to the > > rule requiring FQDNs: > > > > NEW: > > > > Only resolvable, fully-qualified domain names (FQDNs) are permitted > > when domain names are used in SMTP. In particular, names that can > > be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed > > in Section 5) are permitted, as are CNAME RRs whose targets can be > > resolved, in turn, to MX or address RRs. Local nicknames or > > unqualified names MUST NOT be used. There are two exceptions to the > > rule requiring FQDNs: > > > > Thoughts? > (As a participant) > I like this change, as it changes the text from an example to the definitive list. I like it as well. Ned > Best Regards, > Alexey > > > > -- > > Todd Herr | Technical Director, Standards and Ecosystem > > e: todd.herr@valimail.com > > m: 703.220.4153 > > > > This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. > > -- > > Emailcore mailing list > > Emailcore@ietf.org > > https://www.ietf.org/mailman/listinfo/emailcore From nobody Sat Jul 10 14:58:48 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE4F3A1552 for ; Sat, 10 Jul 2021 14:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Afij3I/4; dkim=pass (2048-bit key) header.d=taugh.com header.b=gxtPdPMr 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 UkBKzK1IFVHW for ; Sat, 10 Jul 2021 14:58:40 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC543A1550 for ; Sat, 10 Jul 2021 14:58:40 -0700 (PDT) Received: (qmail 14326 invoked from network); 10 Jul 2021 21:58:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=37f4.60ea180e.k2107; bh=vfcdlvAR2+Ab0o9Wjmo7xtu+Ch3WJcSK1gOdJgEB76M=; b=Afij3I/4StyaUL5ACLVQkZ7LWHs2nlfSmBxByTrV524PaVQGjxMBXAX5TK7oZ1sQMGSw3FiHnoLuxTtSJ62UV0sId4auPt8gafiwE0ZUIbO7Sd3CoOvQG0K2eJBnhzbUHnovnWsuSAJBYO3+rYnFI6fJaxKw2rLrjqufPHP+hkiympFiDZDYdptROW+k52n91NfAJ8RiPyNAlKEuOmQfRfKcHXaHygcMDfsxYTEfDC6Nq7gvbxkVABd6uZUPQh4D/si6BnSwBZYbj4fxGUmOetUP0SrW/ctV7TZTDvE2ZNMm2QvhVIr+nKQHn58Gq6reTPxeBRboADk5JLWrG1RfBg== 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=37f4.60ea180e.k2107; bh=vfcdlvAR2+Ab0o9Wjmo7xtu+Ch3WJcSK1gOdJgEB76M=; b=gxtPdPMr6Ihzvw1i910dGbyS0/WDZGuZw/OwLA+UGH2RgMIm++XCAFmayDKivwkzARlAJxTsHnGWzda5q/tUoN4dVxsB3so2nKTVvGkU7Siowk0OIaiUQyWmjp2iWsVyTGGUEnCbd6LpPhhCOWOowyBiADo3SsTWJpmcdNpLF09eRtJgvWgk5lQnXUtvENHcWAybWxOqV8CsXfUniAPKbep/36sGQGOLMO1jFRfOeUM55y3G664egU0W0AOatNLo390wIb5YJWeg3CvnfUKOXv8o0QplcYl42GLnTkb1yTZJT3v+kF1Ps2TBVteIyJ7KIWQUCxU3AVfVp62FlC/7hw== 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; 10 Jul 2021 21:58:38 -0000 Received: by ary.qy (Postfix, from userid 501) id A2CBD1FF220E; Sat, 10 Jul 2021 17:58:36 -0400 (EDT) Date: 10 Jul 2021 17:58:36 -0400 Message-Id: <20210710215837.A2CBD1FF220E@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: vijay96238@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Additional fields to categorize email to reduce email storage cost 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, 10 Jul 2021 21:58:46 -0000 It appears that Vijay Patel said: >I am looking for an additional feature that mandates email sender to >specify when the email can be deleted safely. The Expires: message header was defined in RFC 2156 in 1998. As far as I am aware, noboy uses it. I think we can conclude that if there were a demand for this feature, sometime over the past two decades people would have used it, but there isn't, so they don't. Also, in 1998 a gigabyte of disk space cost about $50, while now it costs about 3 cents, so we would expect people in that era to care a lot more about how much space their mail used. R's, John From nobody Sat Jul 10 15:38:27 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF4D3A0DED for ; Sat, 10 Jul 2021 15:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.774 X-Spam-Level: X-Spam-Status: No, score=0.774 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=no 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 6beeVhBrPkdH for ; Sat, 10 Jul 2021 15:38:21 -0700 (PDT) Received: from plum.mrochek.com (bang.mrochek.com [98.153.82.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED3923A0DEE for ; Sat, 10 Jul 2021 15:38:20 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S18QC4R2CG00HNRA@mauve.mrochek.com> for emailcore@ietf.org; Sat, 10 Jul 2021 15:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1625956396; bh=e32KKhNQ2raasXm5tIlkoZVRbGnq+kdqx5scv7nhWPk=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=A9yU8IXsLx6+3SX3SUIwBI3lqVcdwaJ12LqImKz2OZax2iHQCgl9527QkMCxElK6j UMWezXCARZqlVkaVjG/ofxJj2sVq2R7iCBy/cYKCDevi8etqOaqPWfmT6EYEosyYmo OzbpswcsEVRGC6UyOAqgjwP/jTiRORPj530uMhAI= 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 <01S0F3SXH38G005PTU@mauve.mrochek.com>; Sat, 10 Jul 2021 15:33:14 -0700 (PDT) Cc: emailcore@ietf.org Message-id: <01S18QC33DRG005PTU@mauve.mrochek.com> Date: Sat, 10 Jul 2021 15:28:28 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 09 Jul 2021 16:38:56 +0100" References: To: Alexey Melnikov Archived-At: Subject: Re: [Emailcore] Ticket #20: G.7.13. Possible SEND, SAML, SOML Loose End 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, 10 Jul 2021 22:38:25 -0000 > Dear WG participants, > Ticket #20 is asking whether the document needs any further discussion > of SEND/SAML/SOML other than in the Appendix F.6 quoted below: > F.6.  Sending versus Mailing >    In addition to specifying a mechanism for delivering messages to >    user's mailboxes, RFC 821 provided additional, optional, commands to >    deliver messages directly to the user's terminal screen.  These >    commands (SEND, SAML, SOML) were rarely implemented, and changes in >    workstation technology and the introduction of other protocols may >    have rendered them obsolete even where they are implemented. >    [[5321bis Editor's Note: does this need a stronger reference to 821, >    2821, and/or 5321?  Also, is anything else needed given the removal >    of these commands and comments about, e.g., their opening mail >    transaction sessions, from the mail body of the text?]] I don't think anything strong is needed. >    Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers >    MAY implement them.  If they are implemented by servers, the >    implementation model specified in RFC 821 MUST be used and the >    command names MUST be published in the response to the EHLO command. This last paragraph omits the possibility of them being implemented but not enabled. I also don't see any point to saying that servers MAY implement them. How about: Clients SHOULD NOT provide SEND, SAML, or SOML as services. If a server implements them, the implementation model specified in RFC 821 MUST be used and the names of any commands that are enabled MUST be published in the response to the EHLO command. Ned From nobody Sat Jul 10 20:20:19 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20423A121A for ; Sat, 10 Jul 2021 20:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmhpNyLlcRPY for ; Sat, 10 Jul 2021 20:20:13 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619103A1215 for ; Sat, 10 Jul 2021 20:20:12 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m2Q0o-000IlU-RN; Sat, 10 Jul 2021 23:20:10 -0400 Date: Sat, 10 Jul 2021 23:20:04 -0400 From: John C Klensin To: John Levine cc: emailcore@ietf.org, vijay96238@gmail.com Message-ID: <673FD853EB7755E10B051D3F@PSB> In-Reply-To: <20210710215837.A2CBD1FF220E@ary.qy> References: <20210710215837.A2CBD1FF220E@ary.qy> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Additional fields to categorize email to reduce email storage cost 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, 11 Jul 2021 03:20:18 -0000 --On Saturday, July 10, 2021 17:58 -0400 John Levine wrote: > It appears that Vijay Patel said: >> I am looking for an additional feature that mandates email >> sender to specify when the email can be deleted safely. > > The Expires: message header was defined in RFC 2156 in 1998. > As far as I am aware, noboy uses it. > > I think we can conclude that if there were a demand for this > feature, sometime over the past two decades people would have > used it, but there isn't, so they don't. > > Also, in 1998 a gigabyte of disk space cost about $50, while > now it costs about 3 cents, so we would expect people in that > era to care a lot more about how much space their mail used. John, Completely agree with everything you write above, but one additional comment. "Mandating" that message senders do anything (including attaching "Expires" header fields) is a dicey business. In most cases, senders have little incentive unless there is agreement that the message will be automagically deleted from the recipient's mail store when that date passes. The is unenforceable and not what I think Vijay is asking for. And, of course, if the goal is to minimize recipient storage space, the sender may have no incentive to do that either. We do see a variation on this theme today, and that is messages with something like "action required before 2021-07-31" in the subject line: nothing automated, but a strong hint to the recipient. best. john From nobody Sat Jul 10 20:30:45 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B83B3A13A2 for ; Sat, 10 Jul 2021 20:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep2HmVrJxgTj for ; Sat, 10 Jul 2021 20:30:39 -0700 (PDT) Received: from dog.elm.relay.mailchannels.net (dog.elm.relay.mailchannels.net [23.83.212.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18FDA3A13AE for ; Sat, 10 Jul 2021 20:30:38 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2867A4811FE; Sun, 11 Jul 2021 03:30:37 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (100-96-13-112.trex.outbound.svc.cluster.local [100.96.13.112]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id E7A74481700; Sun, 11 Jul 2021 03:30:35 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.13.112 (trex/6.3.3); Sun, 11 Jul 2021 03:30:36 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Harbor-Occur: 25a352b11babaed0_1625974236849_2897225787 X-MC-Loop-Signature: 1625974236849:3895626905 X-MC-Ingress-Time: 1625974236849 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id CE1E710E9CC2; Sun, 11 Jul 2021 03:30:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1625974235; bh=gDbbw3brfRlI+UXCqpYWvELt1DgeAx0cc9HbW83Ssyw=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=S/RcU+lnj7NKd6/ws63ZfwkCJwd7/N+vkRX2sYKsxMDGuYMhKf8LiVkz0A6zgkZ3D 7pP11HpSroGnpIXDIAb8NuFqdiYV4TxJZenKohsk7GuMEH1Y1zYZrkdNRsJpac/7S5 /aYPbAUyaLXbP8WKjVTsnyOj2od7/5ySeWKOj4Hnf5XXPE9s0p6019Z3C/gmODGTxP FwVwZeKKAmnQqiC3ST6C2ielRRRJvfSWZITHU8Nz2KNlzQpzkc4i0OQ52KLnM3PTxJ QgMayrhRjzj8Qh11tx+En/wg214yhuzGirt62xNxCqh0clCv9ACYrDEWdMg2/STDda busVHfSTxAFOw== Reply-To: dcrocker@bbiw.net To: John Levine , emailcore@ietf.org Cc: vijay96238@gmail.com References: <20210710215837.A2CBD1FF220E@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <9545798b-73f1-4727-e0a5-8ff23c40cc36@dcrocker.net> Date: Sat, 10 Jul 2021 20:30:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210710215837.A2CBD1FF220E@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Additional fields to categorize email to reduce email storage cost 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, 11 Jul 2021 03:30:44 -0000 On 7/10/2021 2:58 PM, John Levine wrote: > The Expires: message header was defined in RFC 2156 in 1998. As far as I am > aware, noboy uses it. > > I think we can conclude that if there were a demand for this feature, sometime > over the past two decades people would have used it, but there isn't, so they don't. > > Also, in 1998 a gigabyte of disk space cost about $50, while now it costs about 3 cents, > so we would expect people in that era to care a lot more about how much space > their mail used. 1. The reason for adding expiration information is losing timely relevance or utility, not saving storage space. 2. RFC 2156 cites the header field but doesn't actually define it. 3. RFC 2156 cites one heck of a lot of fields, making it especially unlikely that stray Internet folk will know that any particular field is defined and usable. Still, there's never been a community desire to emulate richer 'office' functionality, in spite of various efforts to support it over the years. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jul 10 20:41:21 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE833A14F9 for ; Sat, 10 Jul 2021 20:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=CTM7ssNv; dkim=pass (2048-bit key) header.d=taugh.com header.b=nGlZlp78 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 ziy3P9fG5WjB for ; Sat, 10 Jul 2021 20:41:14 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 223A93A14F5 for ; Sat, 10 Jul 2021 20:41:13 -0700 (PDT) Received: (qmail 69002 invoked from network); 11 Jul 2021 03:41:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=10d84.60ea6857.k2107; bh=E6HtkCuFAcMsh9LULQ+j0crBx+bZpaq25VYDChFPOPQ=; b=CTM7ssNvVGJnTeMrbAUCrgK9W6l2aftDa2x+VKyUMjQ3DF2HPk6OXvsKcwM5B/ArdsG1UtBLDWIo6i2wbvL6XnMUfQwHAU6XR5MTrEiCkBWy4WxD5ghnNFdaHrwIvNz6t1xyoS2X1dXpoONFiEx24cwxRXvpO+dC0LH7/pZ+2YmwO8OqvOdwJfwlvWKpxgXbpj0QWhRddpXqld0zuH/i92jvl5+AI7G0N1KVC2omyB3YK6vk98EgjQp2vz2sAtnscZiGYByZPUUrtn2HaFgobriAKxym4CetBJkbwJxmIfDK/fxIaz392px2EUSXLZy2+VHCGl0C0kKQL3wHFu/Mxw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=10d84.60ea6857.k2107; bh=E6HtkCuFAcMsh9LULQ+j0crBx+bZpaq25VYDChFPOPQ=; b=nGlZlp78dEcddjaUZIeAQLxoB6RdzgRX1KUk+shvP0qA8s4/HZT9zg3ELex1hPsMDZdIvCQgc8dEYc/zBuqpQuEUMS4FtpIs2DFTzjPMCRLaBKAcTvvXKowW6qH4MhWZzrg+2TeBP460UwrxZneVNsF58giy9g0xwiP04C1x/UuQWQ8YpUljnc/XqgLn5j9jZ9dFGqnjYWmPQdy1hL6R1heKyjQQRXbPZbOkiNQZMXYMsNqwP2XtPMJII1e7lswvt7DksFuOBwK7Mpn4gYc1px1oWhjCzqf94pt5F6hu4zT7OsCvC52Qx75eym7YJk3uWPIQhzZSr6zEFRimObufQA== 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; 11 Jul 2021 03:41:11 -0000 Received: by ary.qy (Postfix, from userid 501) id BDD4A2018397; Sat, 10 Jul 2021 23:41:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 6DB6F201836A; Sat, 10 Jul 2021 23:41:09 -0400 (EDT) Date: 10 Jul 2021 23:41:09 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" , emailcore@ietf.org Cc: vijay96238@gmail.com X-X-Sender: johnl@ary.qy In-Reply-To: <9545798b-73f1-4727-e0a5-8ff23c40cc36@dcrocker.net> References: <20210710215837.A2CBD1FF220E@ary.qy> <9545798b-73f1-4727-e0a5-8ff23c40cc36@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] Additional fields to categorize email to reduce email storage cost 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, 11 Jul 2021 03:41:20 -0000 On Sat, 10 Jul 2021, Dave Crocker wrote: > 1. The reason for adding expiration information is losing timely relevance or > utility, not saving storage space. > > 2. RFC 2156 cites the header field but doesn't actually define it. See RFC 4021 which refers to 2156 and defines it as Related information: Time at which a message loses its validity. Renamed version of obsolete Expiry-Date header field. RFC 2156 (MIXER), not for general use. Dunno why it says not for general use unless the idea is it's only for X.400 gateways. The syntax of usenet messages is nearly the same as mail messages, and they also have an Expires header, see RFC 5536. sec 3.2.5. They used to be fairly common in periodically posted FAQ messages, so one would expire when the next copy of the FAQ was posted, but I haven't seen many of those lately, either. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Jul 11 14:37:36 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21873A1F63 for ; Sun, 11 Jul 2021 14:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 B7M0iR33f3LI for ; Sun, 11 Jul 2021 14:37:30 -0700 (PDT) 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 625DB3A1F61 for ; Sun, 11 Jul 2021 14:37:30 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1A2I12WJK00B6WT@mauve.mrochek.com> for emailcore@ietf.org; Sun, 11 Jul 2021 14:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1626039145; bh=jgoo7UwVcnI0uuUZdtYucJbx2BKwX7fuTcTzaW3y4eY=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=qCK/I5m0xX+8FlVGmqhQiJl7UPLdEAXUqg/LO+yeOK2z1SMZPT3uWuJ/sAOg3ZypB 72Dchku1PsBeBOdIf7zrR96FAo5ow7poAon7KRKoKgnRxnm3u9x6wDx4qVrciFtGD3 9SQuQJyCSlqdFDye5AWRew8CzTWv7LEd/weCFf2s= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S19ON4E7F40085YQ@mauve.mrochek.com>; Sun, 11 Jul 2021 14:32:23 -0700 (PDT) Cc: Alexey Melnikov , dcrocker@bbiw.net, Alexey Melnikov , emailcore@ietf.org Message-id: <01S1A2HZAB520085YQ@mauve.mrochek.com> Date: Sun, 11 Jul 2021 13:44:14 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 09 Jul 2021 13:44:43 -0700" References: To: Dave Crocker Archived-At: Subject: Re: [Emailcore] Ticket #42: G.12. Extension Keywords Starting in 'X-' 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, 11 Jul 2021 21:37:35 -0000 > On 7/9/2021 1:19 PM, Alexey Melnikov wrote: > >> As such, the 'SHOULD' that is suggested here seems to go farther than necessary. SHOULD is supposed to be for things that will break, if you don't conform to the should, unless you/really/ know what you are doing. This doesn't seem to be a case of that. > > The SHOULD requirement to register extensions with IANA improves interoperability and general reuse of good ideas, so I think it is warranted. > > > > Do you have a counter proposal? > We don't have a SHOULD for registering header fields, why have one here? Because these are very different cases. Anyone can add a new header field to the mix with a couple of lines of code in pretty much any email component. That's all it takes since most headers are for human, not machine, consumption - the vast majority are never parsed by anything. And most of them are, frankly, junk. Who cares if they are registered or not? SMTP extensions are another matter. SMTP clients and servers both have to be modified in an interoperable way, and to deploy an extension to any significent extent likely means modifying more than one of each. And for the rare extension that does deploy and which do something people want, tracking down information on them in other to "keep up" can be a bit of pain. Mind you, the only extensions of consequence I can think of have been authentication extensions that appeared in SMTP courtesy of SASL, not pure SMTP extensions, and thus aren't in scope here. And requirements language doesn't seem to have helped in these cases. But we cannot tell what the future holds, and requirements language is always somewhat aspirational. > The view that registration improves interoperability has obvious appeal, > but the counter is that it imposes a burden to adoption. That is, for > someone considering creating an enhancement, they face the SHOULD. Again, very different cases. Assuming there was a way to impose a header registration requirement that people could not ignore, it really would be a significant burden given how easy it is to deploy a header. Developing and deploying an SMTP or authentication is vastly more difficult. The added cost of a simple registration is not likely to be significent. > Again, a SHOULD makes sense when there is a clear and present danger to > non-compliance. But as a general, coercive technique, I think it's > actually a net-negative. Non-compliance isn't the only issue. See above. Ned From nobody Sun Jul 11 20:36:18 2021 Return-Path: X-Original-To: emailcore@ietf.org Delivered-To: emailcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC41F3A2BAB; Sun, 11 Jul 2021 20:36:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emailcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <162606097375.22271.17205436685669947700@ietfa.amsl.com> Date: Sun, 11 Jul 2021 20:36:13 -0700 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-as-02.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 03:36:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Revision of core Email specifications WG of the IETF. Title : Applicability Statement for IETF Core Email Protocols Authors : John C Klensin Kenneth Murchison E Sam Filename : draft-ietf-emailcore-as-02.txt Pages : 9 Date : 2021-07-11 Abstract: Electronic mail is one of the oldest Internet applications that is still in very active use. While the basic protocols and formats for mail transport and message formats have evolved slowly over the years, events and thinking in more recent years have supplemented those core protocols with additional features and suggestions for their use. This Applicability Statement describes the relationship among many of those protocols and provides guidance and makes recommendations for the use of features of the core protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emailcore-as/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-as-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-as-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 11:01:53 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1FD3A0406 for ; Mon, 12 Jul 2021 11:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 MCfQk6Ve_tSX for ; Mon, 12 Jul 2021 11:01:46 -0700 (PDT) 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 158033A040A for ; Mon, 12 Jul 2021 11:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1626112900; bh=nbLfJNajdGx5U2cncFxqRAJ3z0+SkswZgUM7GkRGMmE=; l=1799; h=To:References:From:Date:In-Reply-To; b=DCYl3RgjduIFG80+TYCY1yNfrwZTDzAJW8EMu3NqgUKXemux7lellx2H7xUm439wd 54X70JruShjmffk578yYAsfdzt4/hu2nKMnbV5qIv4LcxLQBa4MgRCVYFr86SpCeVI yxb8PbD+qErXDmPFN0p+p3T1JJxCnvvPU9ChYYJhggGQx1ZMvO+oMkKU+eKo4 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 00000000005DC03D.0000000060EC8384.00001FBE; Mon, 12 Jul 2021 20:01:40 +0200 To: emailcore@ietf.org References: <5C50F3E6361F9E5AE613727B@PSB> <5D84C913D9CE543BAF82865F@PSB> From: Alessandro Vesely Message-ID: <6e3f6998-4f46-a2c1-78fb-1fc303faf0a8@tana.it> Date: Mon, 12 Jul 2021 20:01:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <5D84C913D9CE543BAF82865F@PSB> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 12 Jul 2021 18:01:51 -0000 On Sat 10/Jul/2021 09:49:19 +0200 John C Klensin wrote: > --On Tuesday, July 6, 2021 19:55 -0400 Viktor Dukhovni wrote: >> >> FWIW, this is another one of those things where practice >> diverges from theory. Clients *DO* disconnect without waiting >> for a "QUIT" response, and this is in practice well justified. >> Clients also abruptly drop connections after a successful >> "RSET" without sending "QUIT", when e.g. a cached connection >> times out without new messages to send. >> >> Neither behaviour will change in, e.g., Postfix no matter what >> the specification says. The server must be prepared to handle >> lost connections, e.g. because of transport or network layer >> issues, and the client may from time to time elect to >> unilaterally close the transport. > > But I think the text already says that that server must be > prepared for such things. As to the client, Whether we should > change, e.g., the description of QUIT from the current text that > strongly suggests that the client should wait for a reply to > QUIT. Perhaps that stems from 821 being written in the time of > a much more fragile network, but, while I imagine that few of us > on this list regularly use fragile networks, they do still exist > around the world. The onset of bots and abusive behavior had the side effect of making networks appear more fragile than they formally are. Several mail sites use fail2ban or equivalent software, which can drop network connection abruptly, based on log files or received messages, possibly sending a tcp-reset to the local server and leaving the client timeout on its own. Of course, that is outside SMTP. No need to mention it in the spec, but let's not assume that improved hardware implies better reliability. Best Ale -- From nobody Mon Jul 12 12:21:08 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3A93A118E for ; Mon, 12 Jul 2021 12:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[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 LiO8NPjiBc3m for ; Mon, 12 Jul 2021 12:21:00 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 9770F3A118D for ; Mon, 12 Jul 2021 12:21:00 -0700 (PDT) Received: from smtpclient.apple (unknown [63.88.3.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 93FE4D8855 for ; Mon, 12 Jul 2021 15:20:58 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Viktor Dukhovni In-Reply-To: <5D84C913D9CE543BAF82865F@PSB> Date: Mon, 12 Jul 2021 15:20:58 -0400 Content-Transfer-Encoding: 7bit Reply-To: emailcore@ietf.org Message-Id: References: <5C50F3E6361F9E5AE613727B@PSB> <5D84C913D9CE543BAF82865F@PSB> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 12 Jul 2021 19:21:06 -0000 > On 10 Jul 2021, at 3:49 am, John C Klensin wrote: > >> Well, not always 2yz, since ".", "RSET" or "EHLO" could fail >> or be refused. IIRC it is "QUIT" for which "2yz" is the only >> expected outcome. > > I don't understand how RSET could fail unless the server went > outside the spec and considered it equivalent to QUIT, something > that would leave things in an odd state wrt the session/ > Connection. I suppose a server that paid no attention to the > conventional wisdom or our advice about a second EHLO without an > intervening RSET could respond to a second EHLO with "503 Bad > sequence of commands". Non-success responses to RSET are not uncommon, when the server is unwilling to continue the client session beyond the current transaction. Clients need to be prepared to receive a 4XX (perhaps 421) response to RSET and should then disconnect, b/c as you observe the session is no longer in a recoverable state. > However, please note that, if we are going to start looking for > those edge cases (I'm somewhat agnostic about whether we > should), we are going to have to open and reexamine the > command-reply sequences of Section 4.3.2. If you are convinced > that is desirable (or necessary) I recommend opening a ticket. Sadly, I'm not very good at following through on opening tickets, so if that's what it takes, the issue might get lost... >> FWIW, this is another one of those things where practice >> diverges from theory. Clients *DO* disconnect without waiting >> for a "QUIT" response, and this is in practice well justified. >> Clients also abruptly drop connections after a successful >> "RSET" without sending "QUIT", when e.g. a cached connection >> times out without new messages to send. >> >> Neither behaviour will change in, e.g., Postfix no matter what >> the specification says. The server must be prepared to handle >> lost connections, e.g. because of transport or network layer >> issues, and the client may from time to time elect to >> unilaterally close the transport. > > But I think the text already says that that server must be > prepared for such things. As to the client, Whether we should > change, e.g., the description of QUIT from the current text that > strongly suggests that the client should wait for a reply to > QUIT. Perhaps that stems from 821 being written in the time of > a much more fragile network, but, while I imagine that few of us > on this list regularly use fragile networks, they do still exist > around the world. The issue is that the response to QUIT is of no interest to the client, it closes the connection either way. Keeping an open connection to the server waiting for a useless reply can be expensive if it ties up connection slots that could be used to deliver mail (in MTAs with carefully managed concurrency limits). So sending QUIT and closing the channel is the best choice in practice. PIPELINING helps here, because in that case we have: C> ... msg body ... C> .QUIT S> 250 OK221 Goodbye C> ... closes connection ... So whether or not the client actually reads the "221 Goodbye" is not observable, it waits for the "250 Ok" after the combined "."+QUIT and then disconnects. It is only when PIPELINING is not offered that disconnect before QUIT response is potentially visible to the server. -- Viktor. From nobody Mon Jul 12 12:38:50 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECBF3A1356 for ; Mon, 12 Jul 2021 12:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 eProvCrfiYWa for ; Mon, 12 Jul 2021 12:38:45 -0700 (PDT) Received: from mail-ob3.cityemail.com (mail-ob3.cityemail.com [104.128.152.20]) by ietfa.amsl.com (Postfix) with ESMTP id C8FCD3A1365 for ; Mon, 12 Jul 2021 12:38:25 -0700 (PDT) Received: (qmail 31755 invoked from network); 12 Jul 2021 19:38:24 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe3.cityemail.com with (AES128-GCM-SHA256 encrypted) SMTP (b92aa198-e348-11eb-8baa-db8e832d7111); Mon, 12 Jul 2021 12:38:24 -0700 To: emailcore@ietf.org References: <5C50F3E6361F9E5AE613727B@PSB> <5D84C913D9CE543BAF82865F@PSB> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: Date: Mon, 12 Jul 2021 12:38:24 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-MagicMail-OS: Linux 2.2.x-3.x X-MagicMail-UUID: b92aa198-e348-11eb-8baa-db8e832d7111 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 #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 12 Jul 2021 19:38:50 -0000 On 2021-07-12 12:20 p.m., Viktor Dukhovni wrote: > The issue is that the response to QUIT is of no interest to the > client, it closes the connection either way. Keeping an open > connection to the server waiting for a useless reply can be > expensive if it ties up connection slots that could be used > to deliver mail (in MTAs with carefully managed concurrency > limits). > > So sending QUIT and closing the channel is the best choice > in practice. PIPELINING helps here, because in that case > we have: > > C> ... msg body ... > C> .QUIT > S> 250 OK221 Goodbye > C> ... closes connection ... > > So whether or not the client actually reads the "221 Goodbye" is > not observable, it waits for the "250 Ok" after the combined "."+QUIT > and then disconnects. It is only when PIPELINING is not offered > that disconnect before QUIT response is potentially visible to the > server. > > -- For the record, if you do NOT wait for a response to the QUIT, you will probably be more likely to be marked as a spammer.. Not that there is a response to QUIT that represents, "don't hang up yet, I haven't accepted responsibility for the message(s) you sent in this transaction yet.. ", but waiting a 'suitable' time interval before terminating the connection is a reasonable ask. The server MAY want to provide you with a more detailed response in it's 250 ok -- "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 Jul 12 12:39:44 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C3C3A1389 for ; Mon, 12 Jul 2021 12:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[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 wpbOePBOcYFY for ; Mon, 12 Jul 2021 12:39:32 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 2F9DF3A139E for ; Mon, 12 Jul 2021 12:39:32 -0700 (PDT) Received: from smtpclient.apple (unknown [63.88.3.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 13A23D87F7 for ; Mon, 12 Jul 2021 15:39:31 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Viktor Dukhovni In-Reply-To: <01S1A2HZAB520085YQ@mauve.mrochek.com> Date: Mon, 12 Jul 2021 15:39:30 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: emailcore@ietf.org Message-Id: <2B2DEA13-6E65-4D92-8E57-834B20313F2C@dukhovni.org> References: <01S1A2HZAB520085YQ@mauve.mrochek.com> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Emailcore] Ticket #42: G.12. Extension Keywords Starting in 'X-' 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, 12 Jul 2021 19:39:43 -0000 > On 11 Jul 2021, at 4:44 pm, Ned Freed wrote: >=20 > Mind you, the only extensions of consequence I can think of have been > authentication extensions that appeared in SMTP courtesy of SASL, not = pure SMTP > extensions, and thus aren't in scope here. And requirements language = doesn't > seem to have helped in these cases. The Postfix "XFORWARD" and "XCLIENT" extensions seem to have gained some traction and are implemented in various other software (e.g. load balancers, and other MTAs). http://www.postfix.org/XFORWARD_README.html http://www.postfix.org/XCLIENT_README.html --=20 Viktor. From nobody Mon Jul 12 12:55:13 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25ED3A14B5 for ; Mon, 12 Jul 2021 12:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 j-3CVBEEzwJa for ; Mon, 12 Jul 2021 12:55:07 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 868B73A14A2 for ; Mon, 12 Jul 2021 12:55:07 -0700 (PDT) Received: from smtpclient.apple (unknown [63.88.3.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 834F1D8D91 for ; Mon, 12 Jul 2021 15:55:06 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Viktor Dukhovni In-Reply-To: Date: Mon, 12 Jul 2021 15:55:06 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: emailcore@ietf.org Message-Id: References: <5C50F3E6361F9E5AE613727B@PSB> <5D84C913D9CE543BAF82865F@PSB> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Emailcore] Ticket #11: G.7.4. Possible clarification about mail transactions and transaction state 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, 12 Jul 2021 19:55:12 -0000 > On 12 Jul 2021, at 3:38 pm, Michael Peddemors = wrote: >=20 > For the record, if you do NOT wait for a response to the QUIT, you = will > probably be more likely to be marked as a spammer.. Postfix has well over 20% of the MTA market share, and even higher by message volume. So declaring all Postfix MTAs to be spammers is = generally not a winning choice. The risk is exceedingly low. > Not that there is a response to QUIT that represents, "don't hang up = yet, > I haven't accepted responsibility for the message(s) you sent in this > transaction yet.. ", but waiting a 'suitable' time interval before = terminating > the connection is a reasonable ask. The server MAY want to provide you = with > a more detailed response in it's 250 ok This is not going to happen. Postfix MTAs default to hanging up without waiting for a QUIT response. This is only observable in the absence of PIPELINING, and even then typically not seen because the server closes the connection after handing off the QUIT response to the local TCP stack, and never sees the RST if the client happened to already have also closed its TCP read-side. What might make close before QUIT response more prominent is use of TLS. The server's TLS stack might shutdown the write side upon receipt of the client's TLS close notify, returning an error for attempts to return anything other than a reciprocal close-notify in the reverse direction. Whether the early disconnect is observed or not depends on various timing and implementation details, but if observed from one Postfix system, it will typically be observed from most. No apologies for this, the implementation is well motivated, and will not change for mere adherence to the letter of the specification. --=20 Viktor. From nobody Tue Jul 13 04:27:45 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6D33A14BD for ; Tue, 13 Jul 2021 04:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 0QquQ3SbmaJk for ; Tue, 13 Jul 2021 04:27:38 -0700 (PDT) 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 76F6E3A14B5 for ; Tue, 13 Jul 2021 04:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1626175653; bh=Sn+ZHDaX5sRHy4INoPCA2yKNZlF+Scjv9AslemYd3WE=; l=1548; h=To:References:From:Date:In-Reply-To; b=A5ZkvSj+ZNGbXAZYITHZW7CgLPay6SudeMZ6g2p8C1zH4Kq3RCwK0H5AVvJ1QhZpX DtV74jdnnSB+htV24N3dhUjyKUfuZwO8t2D65y5vm8+pOL8h04hIAcoWIcZTQ6XmwT H9eZb30x55rjEOSJbgtJm9FwoofKmRaLnQVw0Y4/8iXavY7J80HlLgeIo5hGE 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 00000000005DC028.0000000060ED78A5.000030FC; Tue, 13 Jul 2021 13:27:33 +0200 To: emailcore@ietf.org References: <4d75d10a-baf1-2c44-6c6c-f921eba9c5ff@dcrocker.net> From: Alessandro Vesely Message-ID: <992fb825-5510-e5eb-5c61-2e6a40efb20a@tana.it> Date: Tue, 13 Jul 2021 13:27:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <4d75d10a-baf1-2c44-6c6c-f921eba9c5ff@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #30: Erratum 4055: Description of SPF and DKIM is wrong 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, 13 Jul 2021 11:27:44 -0000 On Fri 09/Jul/2021 22:16:17 +0200 Dave Crocker wrote: > On 7/9/2021 12:42 PM, Todd Herr wrote: >> >> This specification does not deal with the verification of return paths for >> use in delivery notifications. A server MAY attempt to verify >> the returnpath before using its address for delivery notifications, but >> methods of doing so are not defined here nor is any particular >> method recommended at this time. >> >> >> Thoughts? > > Definitely better.  References to details that are outside the actual scope of > the current specification create a forward reference that invites problems. > > But I will suggest that the MAY is a pseudo-specification. It proffers > normative language but has not technical substance. An implied normative point is that, should the verification fail, the server could even reject the transaction. There are two passages where the draft alludes to SPF: Section 3.6.2. (#30) this ticket about MAIL FROM, and Section 4.1.4. (#47) about HELO/EHLO. To increase parallelism between those sections, I'd drop the "for use in delivery notifications" phrase. If verification is OT, its purpose and the possible reactions to its failure are also OT. An attempt: This specification does not deal with the verification of return paths. A server MAY verify that the returnpath is valid or viable, but methods of doing so are not defined here nor is any particular method recommended at this time. Should this paragraph also refer to Section 7.8 or 7.9? jm2c Ale -- From nobody Tue Jul 13 04:27:49 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FE63A14B5 for ; Tue, 13 Jul 2021 04:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 cxgSqqRSeNXA for ; Tue, 13 Jul 2021 04:27:39 -0700 (PDT) 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 51DAC3A14B8 for ; Tue, 13 Jul 2021 04:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1626175657; bh=l5sLL9roy3tylt98+tQnerS5ZE4BKnHAhyXiT3upMDc=; l=710; h=To:References:From:Date:In-Reply-To; b=CEojiMprC7NEn2g0imCwbwBY4sGZS5z6nqEJJ7GZKOay9AktxrbfdU4QANcDfS3Qs YX7hEpbwStRI4wzy6qQY2DP4T3dsMbDszYE4JJjjM3OXwvRvWIArGhyCL/j0QWVmOJ m3UxHniTw2QDVdojntBHlM3fimpvb6kMkkVL1Ydp1/GJJlEP+VRjoRIYE6334 Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0C3.0000000060ED78A9.00003110; Tue, 13 Jul 2021 13:27:37 +0200 To: emailcore@ietf.org References: From: Alessandro Vesely Message-ID: Date: Tue, 13 Jul 2021 13:27:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.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 #19: G.7.6. Requirements for domain name and/or IP address in EHLO 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, 13 Jul 2021 11:27:44 -0000 On Fri 09/Jul/2021 21:24:47 +0200 Todd Herr wrote: > > I propose the following as a strawman... > > Change the above paragraph to read as follows: > > An SMTP server MAY verify that the domain name argument in the EHLO > command has an address record matching the IP address of the client. I'd make that even more abstract, for example: An SMTP server MAY verify the validity of the domain name argument in the EHLO command. Domain name to IP, IP to PTR name, SPF, and more are different verification criteria, sometimes overlapping and sometimes not. > And include the following text in the Applicability Statement: > > [snip text to be discussed at A/S time] Best Ale -- From nobody Tue Jul 13 04:27:56 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E9C3A14BD for ; Tue, 13 Jul 2021 04:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 0gyfXdoVwswt for ; Tue, 13 Jul 2021 04:27:41 -0700 (PDT) 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 3CBCB3A14B9 for ; Tue, 13 Jul 2021 04:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1626175660; bh=3ncp4EJjlJgnIBuyeawH1EhtihXufK63v16ar1ZEAIY=; l=1929; h=To:References:From:Date:In-Reply-To; b=DFaQSv5wL46q577iPTBz2QjrJl66ttu0RTIQpuCLIXw8m7eU5ZE8y08W4Wg0IqLpF GmrB9k5l1m2xJ4AbUVUpVSsXpzggdE3k/OmbVxzcLAaBYuABnB2Una0wrsyjgb8eym V7KFyQ39b6TpNYs4uxuYRvXmYd4LBGLlyrvit9eTDyzHxbW2+BGBHb01mc1Oq 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 00000000005DC0D6.0000000060ED78AC.00003123; Tue, 13 Jul 2021 13:27:40 +0200 To: emailcore@ietf.org References: <9F9214FA-3492-4A5A-88FA-494E9BC59F07@fastmail.fm> <01S1866N0YP6005PTU@mauve.mrochek.com> From: Alessandro Vesely Message-ID: Date: Tue, 13 Jul 2021 13:27:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <01S1866N0YP6005PTU@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 #10: Meaning of "resolvable FQDN" in Section 2.3.5 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, 13 Jul 2021 11:27:47 -0000 On Sat 10/Jul/2021 14:55:57 +0200 Ned Freed wrote: >>> On 9 Jul 2021, at 19:49, Todd Herr wrote: >>>  >>> Greetings. >>> >>> I would like to start a discussion on ticket #10, which reads: >>> >>>> In other words, names that can be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed in Section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs. >>> >>>> It is not clear whether "In other words" really meant "for example" or it is was (sic) intended that the only labels permitted are those that own records in one of the above RR types. >>> >>> >>> The proposal here is to change the text, replacing "In other words" with "In particular", as follows: >>> >>> OLD: >>> >>> Only resolvable, fully-qualified domain names (FQDNs) are permitted >>> when domain names are used in SMTP. In other words, names that can >>> be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed >>> in Section 5) are permitted, as are CNAME RRs whose targets can be >>> resolved, in turn, to MX or address RRs. Local nicknames or >>> unqualified names MUST NOT be used. There are two exceptions to the >>> rule requiring FQDNs: >>> >>> NEW: >>> >>> Only resolvable, fully-qualified domain names (FQDNs) are permitted >>> when domain names are used in SMTP. In particular, names that can >>> be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed >>> in Section 5) are permitted, as are CNAME RRs whose targets can be >>> resolved, in turn, to MX or address RRs. Local nicknames or >>> unqualified names MUST NOT be used. There are two exceptions to the >>> rule requiring FQDNs: >>> >>> Thoughts? >> >> (As a participant) >> I like this change, as it changes the text from an example to the definitive list. > > I like it as well. +1, good disambiguation. Best Ale -- From nobody Tue Jul 13 05:48:45 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE28B3A0943 for ; Tue, 13 Jul 2021 05:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 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_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 tIxystlDh7Vv for ; Tue, 13 Jul 2021 05:48:38 -0700 (PDT) Received: from plum.mrochek.com (bang.mrochek.com [98.153.82.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40DE13A094A for ; Tue, 13 Jul 2021 05:48:38 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1CCM1LM8G00HX6T@mauve.mrochek.com> for emailcore@ietf.org; Tue, 13 Jul 2021 05:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1626180214; bh=Gi21ixOFz3XEzILyKlbfC1sg7AFFntmr1XE+s5gr6nw=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Oy/h3x7+I+UOZ3YisbSETjomJ8X5qaabsfajQuhl0b1qa6W618Y1V2zlW8Rpkqh/v Ertqv+tSV28nLWgL79vsfQ4Fwpz4uVuuJDCT/FBcjirDy4bYiyserlQ52T9CNwXK0o IkXTIf6T+NiDxwO3ksPYTi1KdUzTUN0JVgOSpVV4= 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 <01S0F3SXH38G005PTU@mauve.mrochek.com>; Tue, 13 Jul 2021 05:43:32 -0700 (PDT) Cc: emailcore@ietf.org Message-id: <01S1CCLZCLD0005PTU@mauve.mrochek.com> Date: Tue, 13 Jul 2021 05:35:38 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 12 Jul 2021 15:39:30 -0400" <2B2DEA13-6E65-4D92-8E57-834B20313F2C@dukhovni.org> References: <01S1A2HZAB520085YQ@mauve.mrochek.com> <2B2DEA13-6E65-4D92-8E57-834B20313F2C@dukhovni.org> To: Viktor Dukhovni Archived-At: Subject: Re: [Emailcore] Ticket #42: G.12. Extension Keywords Starting in 'X-' 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, 13 Jul 2021 12:48:43 -0000 > > On 11 Jul 2021, at 4:44 pm, Ned Freed wrote: > > > > Mind you, the only extensions of consequence I can think of have been > > authentication extensions that appeared in SMTP courtesy of SASL, not pure SMTP > > extensions, and thus aren't in scope here. And requirements language doesn't > > seem to have helped in these cases. > The Postfix "XFORWARD" and "XCLIENT" extensions seem to have gained > some traction and are implemented in various other software (e.g. > load balancers, and other MTAs). > http://www.postfix.org/XFORWARD_README.html > http://www.postfix.org/XCLIENT_README.html IME proxy protocol seems to be the preferred mechanism for load balancers - becase it works with any protocol, not just SMTP. And IME the choice of whether or not to implement Microsoft's client identification authentication stuff is a far more consequential one. But this is just quibbling. The SMTP world would be a better place i XCLIENT were registered and specified. It's been on by to-do list for years to write a formal specification for it. (Yes, we implement it.) Maybe someday... Ned From nobody Tue Jul 13 06:14:14 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D333A0D5E for ; Tue, 13 Jul 2021 06:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 tQpGiPofQVqw for ; Tue, 13 Jul 2021 06:14:06 -0700 (PDT) Received: from plum.mrochek.com (bang.mrochek.com [98.153.82.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D806D3A0D50 for ; Tue, 13 Jul 2021 06:14:06 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1CDHN082O00JC9B@mauve.mrochek.com> for emailcore@ietf.org; Tue, 13 Jul 2021 06:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1626181742; bh=wJ1Ma1O2ndFM9BisYWGi/AFx/iW6aDQrkYAbBt3zTfA=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=NCLDJY33FPq2sJm1nhVWL2QgpJJP5/TeA/OaB3ZirDvWjn53/wk90Rp2+N4bnpC9w kGYiewaHxet6Ud4kw2QdSi1rV3OWYzOToXwIct+TA5KPJDFnO2/7m71kietM4uhGiN N+k/m8QlNpwYsSZ0fICnGbaLQXHlf2JYV9b6d6dg= 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 <01S0F3SXH38G005PTU@mauve.mrochek.com>; Tue, 13 Jul 2021 06:08:59 -0700 (PDT) Cc: emailcore@ietf.org Message-id: <01S1CDHKSDL6005PTU@mauve.mrochek.com> Date: Tue, 13 Jul 2021 05:52:51 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 09 Jul 2021 15:01:55 -0400" References: To: Todd Herr Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits 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, 13 Jul 2021 13:14:12 -0000 > Greetings. > I would like to start a discussion about ticket #14 - > https://trac.ietf.org/trac/emailcore/ticket/14 > Section 4.5.3.1 of draft-ietf-emailcore-rfc5321bis reads: > 4.5.3.1. Size Limits and Minimums > There are several objects that have required minimum/maximum sizes. > Every implementation MUST be able to receive objects of at least > these sizes. Objects larger than these sizes SHOULD be avoided when > possible. However, some Internet mail constructs such as encoded > X.400 addresses (RFC 2156 [26]) will often require larger objects. > Clients MAY attempt to transmit these, but MUST be prepared for a > server to reject them if they cannot be handled by it. To the > maximum extent possible, implementation techniques that impose no > limits on the length of these objects should be used. > Extensions to SMTP may involve the use of characters that occupy more > than a single octet each. This section therefore specifies lengths > in octets where absolute lengths, rather than character counts, are > intended. > and ticket 14 asks the question: > Given the controversy on the SMTP mailing list between 20191123 and now > about maximum lengths, is the above adequate or is further tuning of the > limit text below needed? The text, especially the part about X.400, is seriously dated at this point. (For those of you who have never dealt with X.400, X.400 addresses consist of a list of attributes and values, including but not limited to attributes for postal address information, and theoretically can be thousands of octets in length. The 1:1 mapping of this defined by RFC 2156 puts most of this in the local part in /attr1=/value1/attr2=value2/... form.) As a practical matter real world X.400 gateways never required longer lengths on the SMTP/RFC822 side, for the simple reason that they never worked well enough. (It didn't stop compliance suites from coding tests that required them...) A combination of restraint on the part of X.400 implementations and very complicated mappings were used to avoid the problem. And if a client has a fallback, as the text requires, why not just use it rather than sending something that may work locally but fail downstream, where no fallback is possible? I also note that X.400 has changed from "the mail system we'll all be using somday" to "only used in limited government/military cases, and even those are disappearing". Is it really worth mentioning at this point? Finally, and most importantly, implementation techniques that impose no limits on object size represent a serious security risk. I think this alone justifies removing "should support" bit. > draft-ietf-emailcore-rfc5321bis then goes on to specify length limits in > octets, not characters, in each of the following sections: > 4.5.3.1.1. Local-part > 4.5.3.1.2. Domain > 4.5.3.1.3. Path > 4.5.3.1.4. Command Line > 4.5.3.1.5. Reply Line > 4.5.3.1.6. Text Line > 4.5.3.1.7. Message Content > 4.5.3.1.8. Recipient Buffer Like it or not, the limits in existing implementations are octet, not character, based. A change to make them character-based is therefore wholly nonsensical. Ned > Thoughts? > -- > *Todd Herr* | Technical Director, Standards and Ecosystem > *e:* todd.herr@valimail.com > *m:* 703.220.4153 > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. From nobody Tue Jul 13 08:33:13 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6FF3A17F5 for ; Tue, 13 Jul 2021 08:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLqCFkFLDzWF for ; Tue, 13 Jul 2021 08:33:06 -0700 (PDT) Received: from dog.elm.relay.mailchannels.net (dog.elm.relay.mailchannels.net [23.83.212.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC463A17F3 for ; Tue, 13 Jul 2021 08:33:00 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id DFC0334370F; Tue, 13 Jul 2021 15:32:54 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (100-98-55-150.trex-nlb.outbound.svc.cluster.local [100.98.55.150]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id DDCFA3436D6; Tue, 13 Jul 2021 15:32:53 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.98.55.150 (trex/6.3.3); Tue, 13 Jul 2021 15:32:54 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Supply-Interest: 78f631cc4ddd8a79_1626190374404_2977464152 X-MC-Loop-Signature: 1626190374404:2908794184 X-MC-Ingress-Time: 1626190374403 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id DCAF410E99ED; Tue, 13 Jul 2021 15:32:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1626190373; bh=JRT4NFncBFErgmq55048ZIKOZmL3oty+F85I8yDM5W8=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=TnBrRy2QFVMua3GvptlzOF8otfJUmkdWvunoyMTpCsemcFvjab6DC1WVV7w28/omC ey/xouixeayI8FdK5geGbT6FP3dD0GbDdpquTbXYLvY2rIuatm60V6HFoElK8hPHLN iHyow6sMtL8jEsnzgFPsFp1/Bnnh6Bm5KnuNk4E6t84iXKxSQx53AEqwCA7YsEeolK jN+sqhoS+Gex7dtVUUFXN28EBpqH5Y7d7jsM6o5UgN2R/OKXsh7cfqk04GqM6P+ydv wlOf3yrx6e9ie5bSVZIit4g/4BS6U9T8PBzdacZ7k5Rl59nU4hPJ2/01Bd3xuLNDx6 WM45lMARi/LUg== Reply-To: dcrocker@bbiw.net To: Ned Freed , Todd Herr Cc: emailcore@ietf.org References: <01S1CDHKSDL6005PTU@mauve.mrochek.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <70e3923f-c3c9-8625-4009-0a4ca0fb5ab0@dcrocker.net> Date: Tue, 13 Jul 2021 08:32:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <01S1CDHKSDL6005PTU@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 #14: G.7.8. Review different size limits 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, 13 Jul 2021 15:33:11 -0000 On 7/13/2021 5:52 AM, Ned Freed wrote: > I also note that X.400 has changed from "the mail system we'll all be using > somday" to "only used in limited government/military cases, and even those are > disappearing". Is it really worth mentioning at this point? It is not. > Finally, and most importantly, implementation techniques that impose no limits > on object size represent a serious security risk. I think this alone justifies > removing "should support" bit. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 13 09:28:52 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F15C3A03FF for ; Tue, 13 Jul 2021 09:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 F4j3cuocGQyO for ; Tue, 13 Jul 2021 09:28:46 -0700 (PDT) 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 A337B3A040C for ; Tue, 13 Jul 2021 09:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1626193718; bh=WbNBvg2RMbVP/7uIxYMdOrUCliTB/KWSOqtilZx2Y80=; l=1250; h=To:References:From:Date:In-Reply-To; b=Dhbs/+jqH9wWC32FFj0WOrs5+PfNSF6Z8Ff7JcxLwGWG0KH4AwjH5ATsMVAwXuCY1 MwrXp6CM44ybVYNa6siGqFoUf085lQFfoNF+Yo9wpEMKwR1eJW+6fHnTEk4AdjAzrT lZx6/Y0mSMIYf3OtzP0rwsNz0pp+spbiCplaeHfD7b+PtcHvUy3dMivlEgujc Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.0000000060EDBF36.0000568E; Tue, 13 Jul 2021 18:28:38 +0200 To: emailcore@ietf.org References: <01S18QC33DRG005PTU@mauve.mrochek.com> From: Alessandro Vesely Message-ID: <60b3dd04-688c-636c-b0fa-b01f5bc31417@tana.it> Date: Tue, 13 Jul 2021 18:28:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <01S18QC33DRG005PTU@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 #20: G.7.13. Possible SEND, SAML, SOML Loose End 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, 13 Jul 2021 16:28:52 -0000 On Sun 11/Jul/2021 00:28:28 +0200 Ned Freed wrote: > >>     Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers >>     MAY implement them.  If they are implemented by servers, the >>     implementation model specified in RFC 821 MUST be used and the >>     command names MUST be published in the response to the EHLO command. > > This last paragraph omits the possibility of them being implemented but > not enabled. I also don't see any point to saying that servers MAY implement > them. How about: > >    Clients SHOULD NOT provide SEND, SAML, or SOML as services. If >    a server implements them, the implementation model specified in RFC 821 >    MUST be used and the names of any commands that are enabled MUST be >    published in the response to the EHLO command. I'm confused by the first sentence. My understanding is that a client can use a given service if a server provides it. Ho about this: Clients SHOULD NOT provide for using SEND, SAML, or SOML commands. If a server implements them, the implementation model specified in RFC 821 MUST be used and the names of any commands that are enabled MUST be published in the response to the EHLO command. Best Ale -- From nobody Tue Jul 13 09:30:44 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495733A0489 for ; Tue, 13 Jul 2021 09:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 iZAq-50q8pz5 for ; Tue, 13 Jul 2021 09:30:36 -0700 (PDT) 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 173F23A044E for ; Tue, 13 Jul 2021 09:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1626193833; bh=PlE+oBUkLn9bpNwxr+T407mtOe2PQRYlfd0qBgyi+Zo=; l=1059; h=To:References:From:Date:In-Reply-To; b=BIIpZJ7RR+OxN/qiiLrtS8KYDtyXQbmUiJaPg1EiddFN7OCqhdEz0UZtIy9kuPNKa ei4RnT4SVeYhz+FIfTP1sdNavDx65QzAqMzEAyHOdcejPXUFK89TvOq49eiiNimdYd JgzYD7b/fa32+JlGVtj6iUiksMWXHGhIBwp8Ok85JK6L5FW/6SbazWcbny9vU Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.0000000060EDBFA9.0000570F; Tue, 13 Jul 2021 18:30:33 +0200 To: emailcore@ietf.org References: <01S1CDHKSDL6005PTU@mauve.mrochek.com> <70e3923f-c3c9-8625-4009-0a4ca0fb5ab0@dcrocker.net> From: Alessandro Vesely Message-ID: <5e1490c1-a26f-3e39-b5b2-41d3f1c0c6a7@tana.it> Date: Tue, 13 Jul 2021 18:30:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <70e3923f-c3c9-8625-4009-0a4ca0fb5ab0@dcrocker.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits 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, 13 Jul 2021 16:30:43 -0000 On Tue 13/Jul/2021 17:32:50 +0200 Dave Crocker wrote: > On 7/13/2021 5:52 AM, Ned Freed wrote: >> I also note that X.400 has changed from "the mail system we'll all be using >> someday" to "only used in limited government/military cases, and even those are >> disappearing". Is it really worth mentioning at this point? Where do those quotes come from? Do you have a reference? When did the change occur? > It is not. +1, >> Finally, and most importantly, implementation techniques that impose no limits >> on object size represent a serious security risk. I think this alone justifies >> removing "should support" bit. You mean "should be used"? ("should support" doesn't appear in that paragraph). I'm not clear what is the security risk. Clearly, no implementation can be truly limitless, since the Universe itself appears to be limited. Perhaps: To the maximum extent possible, implementation techniques that impose no *predefined* limits on the length of these objects should be used. ? Best Ale -- From nobody Tue Jul 13 11:58:20 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FD03A0CB2 for ; Tue, 13 Jul 2021 11:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQC0kTO4XlvB for ; Tue, 13 Jul 2021 11:58:13 -0700 (PDT) Received: from antelope.elm.relay.mailchannels.net (antelope.elm.relay.mailchannels.net [23.83.212.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34FB43A0CB4 for ; Tue, 13 Jul 2021 11:58:11 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 9FF8062051A; Tue, 13 Jul 2021 18:58:08 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (100-101-162-69.trex-nlb.outbound.svc.cluster.local [100.101.162.69]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 64A886206A0; Tue, 13 Jul 2021 18:58:07 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (35.45.192.35.bc.googleusercontent.com [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.101.162.69 (trex/6.3.3); Tue, 13 Jul 2021 18:58:08 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Whispering-Trouble: 38554aa936c293b2_1626202688333_2544654749 X-MC-Loop-Signature: 1626202688333:1564687872 X-MC-Ingress-Time: 1626202688332 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 6477631364BF; Tue, 13 Jul 2021 18:58:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1626202686; bh=vxE253/vXUtfUjBKudJGEb+Wjf2FB6ZidMBTjfHW2Qk=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=ST9VAjwPhb+GipJ8bSxhhZlIkt7TaWPj5NWTsLWJ+zlYXmXkpZnu1dsu7mJ2syGYS zOdLvqpY7bIU+lMB/pzAk7XmpMj7mXEXtD6vK7mpnnK6FLtOL6RYNl+NPW0qQ3j9nb VCAMPH+zP/5AuruxUKvzmS00OXTNElN4HdQWeizfTlqcWAOlM/rylXnP3DxCOfG9T0 cGjCTITs1/BOHtvHKM1NoSfXygIlnc0aJCF2PD8e+3V2lyBWsEWWy6grLeFvQ52xMq c26hGgiqiUJujPZ/MfiOXJhm5lVt34efjtmmH+ELpB6dKzI+S9WB1uP4QPzkRaA+3F Tpdl+ejht1JQg== Reply-To: dcrocker@bbiw.net To: Ned Freed Cc: emailcore@ietf.org References: <01S1A2HZAB520085YQ@mauve.mrochek.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <7a4edee1-b0ea-789a-8c50-7e48a7bd82e4@dcrocker.net> Date: Tue, 13 Jul 2021 11:58:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <01S1A2HZAB520085YQ@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] Registration is for coordination, not coercion 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, 13 Jul 2021 18:58:19 -0000 (Subject line changed, to focus on a basic point of concern.) On 7/11/2021 1:44 PM, Ned Freed wrote: > SMTP extensions are another matter. SMTP clients and servers both > have to be modified in an interoperable way, and to deploy an > extension to any significent extent likely means modifying more than > one of each. And for the rare extension that does deploy and which do > something people want, tracking down information on them in other to > "keep up" can be a bit of pain. The IETF has always been a bit confused about enforcement. The use of normative language encourages the misguided view that authors have a force of law over other folk. This then extends into the realm of registration. And yet the IETF's success did not come from coercing use but from satisfying needs. When there is limited space for registration, figuring out a possibly-restrictive policy for allocations is required. In other cases, it probably isn't. The view that restrictive registration policies are otherwise necessary seems to come from a failure to distinguish tasks. Standardization is where community 'approval' lies. Not registration. Registration is for disciplined administerion of an identification space. We invoke a vague fear of potential harm from an allocation that involves activity that is not properly vetted. So we require a specification, or even that it be standardized. But the danger of requiring neither lacks a demonstrable danger. Intuitively, the fear is reasonable, but, well... you know... theory vs. practice... Say a random SMTP extension name is registered, and it has no specification. As long as the meta-rule is "ignore what you don't understand", what is the danger? And note that this case is already present, for UNregistered identifiers. So, really, the question is what is the incremental danger from registering such allocations? Say a random SMTP extension name is registered and has an associated specification that is crappy. For this to cause meaningful damage both client and server implementers must fail to see how crappy it is. Again, this case already happens, such as with some 'experimental' specifications that actually do get IETF approval; and maybe even some standards track ones. Again, what is the danger? There is an absolute, community good to encouraging registration, because it makes it unlikely there will be name collisions; it advertises the existing of an extension activity, and it makes clear who is in charge of use of the name. Even requiring a published specification decreases that good. IETF standards do not succeed because their use is required but because the community likes the standards. Registration should use the same model. It's not that associating a specification isn't also a good. And it isn't that standardization isn't a good. It's that making them barriers to entry into a registration space is a bad. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 13 11:58:41 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE37C3A0CC6 for ; Tue, 13 Jul 2021 11:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 iwGZuxW-Uw8e for ; Tue, 13 Jul 2021 11:58:33 -0700 (PDT) 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 A13EB3A0CB4 for ; Tue, 13 Jul 2021 11:58:33 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1CPINGXRK00G21K@mauve.mrochek.com> for emailcore@ietf.org; Tue, 13 Jul 2021 11:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1626202407; bh=jyOBYoGJDVOjFLx5h7GydzN1dKq4KbCx8ZbJSlcDdNA=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=JGfA8Qx9K3MxosQOkXSKozxlOJmwczX1+ULecbh4nGgFa30M/a20pbhETI0vIbODw thatCNbQEVtkv9qE7HcE1oVlzd1727S8R6JtL4NHIxBOiAJJ9eXFFMQFX799Ft7NrW YutDRJZ4Z1dfVXFRS8ovjLObjN/8qYbDv7Gua4/M= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S0F3SXH38G005PTU@mauve.mrochek.com>; Tue, 13 Jul 2021 11:53:25 -0700 (PDT) Cc: emailcore@ietf.org Message-id: <01S1CPIM81KU005PTU@mauve.mrochek.com> Date: Tue, 13 Jul 2021 11:16:35 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 13 Jul 2021 18:30:33 +0200" <5e1490c1-a26f-3e39-b5b2-41d3f1c0c6a7@tana.it> References: <01S1CDHKSDL6005PTU@mauve.mrochek.com> <70e3923f-c3c9-8625-4009-0a4ca0fb5ab0@dcrocker.net> <5e1490c1-a26f-3e39-b5b2-41d3f1c0c6a7@tana.it> To: Alessandro Vesely Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits 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, 13 Jul 2021 18:58:40 -0000 > On Tue 13/Jul/2021 17:32:50 +0200 Dave Crocker wrote: > > On 7/13/2021 5:52 AM, Ned Freed wrote: > >> I also note that X.400 has changed from "the mail system we'll all be using > >> someday" to "only used in limited government/military cases, and even those are > >> disappearing". Is it really worth mentioning at this point? > Where do those quotes come from? They came from me. I'm paraphrasing what many people said back in the 80s when X.400 was the new hotness and now when it's old and busted. It's hard to believe now, but at the time the expectation really was that a mostly government-run email service based on a universal directory was the future. > Do you have a reference? When did the change occur? These sorts of transitions rarely involve an abrupt change, but as it happens, in the case of X.400 I did have an "aha" moment. It was back in the early 90s at the Electronic Mail Association's Message Attachment Working Group (MAWG) meeting on profiling the File Transfer Body Part and aligning it with MIME. As the EMA equivalent of the blue sheet started circulating, Nick Shelness stood up and (more or less) said, "Please include your Internet address on the sheet, most of the X.400 ones you've provided in the past don't work." Since then I've wondered if Nick - among other things, the main author of Softswitch - knew the significance of what he was saying. Knowing Nick, he probably did. > > It is not. > +1, > >> Finally, and most importantly, implementation techniques that impose no limits > >> on object size represent a serious security risk. I think this alone justifies > >> removing "should support" bit. > You mean "should be used"? ("should support" doesn't appear in that > paragraph). Correct. > I'm not clear what is the security risk. Clearly, no implementation can be > truly limitless, since the Universe itself appears to be limited. Perhaps: > To the > maximum extent possible, implementation techniques that impose no > *predefined* limits on the length of these objects should be used. That's still a recipe for disaster because people won't know to set them correctly. Anything without a reasonable limit can be found by a hacker and exploited to exhaust resources. And if you don't believe this happens, I have a couple of very nice bridges to sell you. It also does nothing to enhance interoperability. Requiring the minimums but encouraging everyone to implement more opens the door to implementators coding stuff that assumes larger limits - because what they had in the lab suppported more - but then fails badly when faced with a wider range of implementations on the Internet. IMO at this point interoperability trumps being able to get away with stuff sometimes. Ned From nobody Tue Jul 13 12:47:46 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B6D3A15B3 for ; Tue, 13 Jul 2021 12:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=rf513VMq; dkim=pass (2048-bit key) header.d=taugh.com header.b=MttmgTef 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 30ixsCSjWuTj for ; Tue, 13 Jul 2021 12:47:39 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB833A15AC for ; Tue, 13 Jul 2021 12:47:39 -0700 (PDT) Received: (qmail 47833 invoked from network); 13 Jul 2021 19:47:37 -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=bad7.60ededd9.k2107; bh=NHaM6uZm7IZbilFNJNmoBmnuGlzZFjvk7OEHlQqPx3E=; b=rf513VMqhFJARr8u1WbsRKSW8iDBEaxRPq0toK8of2y+tUcXjYnSKIGx04NBAj5pY2cK+sTqFAyMyS9qJDbqzPNXfZSl5pzaK0tmF2s1EMmb3w6ATcfua6a+Y4+ZnA+cFNlFHY+QCYqEioT/a2Ob2S+A2QE7cNEch/wILdds2Punmh5MH07QgtG9m9d9+NkPPwfiYwT7hJqh8oWYCdUE9oPFPPoS1ajA4WgY2xCtDbtMXBmxTl+arRCXoPz9sxkASlYjsdF/eudxdiR0Fn4Zy57LchtNs8o2I/uYGuWWY1BdCb4cIvTMIkwFIBi5hGty9IoTYjj6g5L9xxZv6P3dQw== 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=bad7.60ededd9.k2107; bh=NHaM6uZm7IZbilFNJNmoBmnuGlzZFjvk7OEHlQqPx3E=; b=MttmgTefyQsfEYuWyFrxUrEPTO7wUqb66AokyPZicUOlk1rCMac9Exfhndl4zmWNSoQ2XJyU9F+s0VcWFuwGVwXkNyr1SYNu178qte3sTmTFZqrKGUv1MJ+e9ctD2rOZnBCE1cAXgU/zbH0Sdm55XNhBjRCwddbDiyAJzERgUCwq30lemQ0FzjX3iIH0+lOMc7T2OpVuBN3xha83uCvQRkpJ4r/tThAmLG5DJBB47uZEGfLY6JehUXpL32YxDh0wREidzZ3H3ECHcqVvbAq+N/sMJFjUlP5oV02PJCdVK+F8bkK1+fGtcIGQ/Wj3bYBA+pxqGqSD5/7+BD0QT3QcyA== 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; 13 Jul 2021 19:47:37 -0000 Received: by ary.qy (Postfix, from userid 501) id A65FB214C287; Tue, 13 Jul 2021 15:47:35 -0400 (EDT) Date: 13 Jul 2021 15:47:35 -0400 Message-Id: <20210713194736.A65FB214C287@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <70e3923f-c3c9-8625-4009-0a4ca0fb5ab0@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] Ticket #14: G.7.8. Review different size limits 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, 13 Jul 2021 19:47:45 -0000 It appears that Dave Crocker said: >On 7/13/2021 5:52 AM, Ned Freed wrote: >> I also note that X.400 has changed from "the mail system we'll all be using >> somday" to "only used in limited government/military cases, and even those are >> disappearing". Is it really worth mentioning at this point? > >It is not. Oh, all right, says cca!ima!johnl >> Finally, and most importantly, implementation techniques that impose no limits >> on object size represent a serious security risk. I think this alone justifies >> removing "should support" bit. > >+1 Agreed. If it's a limit, it's a limit. Speaking of limits, how do we feel about the 1000 octet limit on line length. It is my impression that it is often exceeded in HTML text. R's, John From nobody Tue Jul 13 13:56:57 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A2A3A0CDB for ; Tue, 13 Jul 2021 13:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 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_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 2k3u-I-URPNx for ; Tue, 13 Jul 2021 13:56:50 -0700 (PDT) Received: from plum.mrochek.com (bang.mrochek.com [98.153.82.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C5C43A0CD5 for ; Tue, 13 Jul 2021 13:56:50 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1CTNC9IFK00G254@mauve.mrochek.com> for emailcore@ietf.org; Tue, 13 Jul 2021 13:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1626209506; bh=ChPwVG/GislrE+0344rIwQzy4+qbCsC97wFkJzbEAzo=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=XBrVM0LJIdiKOC1LVDBDPi7uVwWVK6pMpkabk6ooV8xd77tk8pVH8QMSbcKiwLKj0 0T+TFumZUdza7fHUr93JJhK605f0ogXu3qXD/X+OKLx8l4gqnV+GZ+Q5noR8gw4O7I DV4Q+xzj0KHbBael5fG6nSXvBiXaAMP3QVh6MWiU= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S0F3SXH38G005PTU@mauve.mrochek.com>; Tue, 13 Jul 2021 13:51:43 -0700 (PDT) Cc: Ned Freed , emailcore@ietf.org Message-id: <01S1CTN9L5N0005PTU@mauve.mrochek.com> Date: Tue, 13 Jul 2021 13:50:01 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 13 Jul 2021 11:58:04 -0700" <7a4edee1-b0ea-789a-8c50-7e48a7bd82e4@dcrocker.net> References: <01S1A2HZAB520085YQ@mauve.mrochek.com> <7a4edee1-b0ea-789a-8c50-7e48a7bd82e4@dcrocker.net> To: Dave Crocker Archived-At: Subject: Re: [Emailcore] Registration is for coordination, not coercion 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, 13 Jul 2021 20:56:55 -0000 Agreed on all points. Our original "IETF specification required" position for SMTP extensions was an error. We need to rectify that, and encouraging registration, hopefully with a pointer to whatever specification does exist, is IMO the right way forward. Ned > (Subject line changed, to focus on a basic point of concern.) > On 7/11/2021 1:44 PM, Ned Freed wrote: > > SMTP extensions are another matter. SMTP clients and servers both > > have to be modified in an interoperable way, and to deploy an > > extension to any significent extent likely means modifying more than > > one of each. And for the rare extension that does deploy and which do > > something people want, tracking down information on them in other to > > "keep up" can be a bit of pain. > The IETF has always been a bit confused about enforcement. The use of > normative language encourages the misguided view that authors have a > force of law over other folk. This then extends into the realm of > registration. And yet the IETF's success did not come from coercing use > but from satisfying needs. > When there is limited space for registration, figuring out a > possibly-restrictive policy for allocations is required. In other > cases, it probably isn't. > The view that restrictive registration policies are otherwise necessary > seems to come from a failure to distinguish tasks. Standardization is > where community 'approval' lies. Not registration. Registration is for > disciplined administerion of an identification space. > We invoke a vague fear of potential harm from an allocation that > involves activity that is not properly vetted. So we require a > specification, or even that it be standardized. But the danger of > requiring neither lacks a demonstrable danger. Intuitively, the fear is > reasonable, but, well... you know... theory vs. practice... > Say a random SMTP extension name is registered, and it has no > specification. As long as the meta-rule is "ignore what you don't > understand", what is the danger? And note that this case is already > present, for UNregistered identifiers. So, really, the question is what > is the incremental danger from registering such allocations? > Say a random SMTP extension name is registered and has an associated > specification that is crappy. For this to cause meaningful damage both > client and server implementers must fail to see how crappy it is. > Again, this case already happens, such as with some 'experimental' > specifications that actually do get IETF approval; and maybe even some > standards track ones. Again, what is the danger? > There is an absolute, community good to encouraging registration, > because it makes it unlikely there will be name collisions; it > advertises the existing of an extension activity, and it makes clear who > is in charge of use of the name. > Even requiring a published specification decreases that good. > IETF standards do not succeed because their use is required but because > the community likes the standards. Registration should use the same model. > It's not that associating a specification isn't also a good. And it > isn't that standardization isn't a good. It's that making them barriers > to entry into a registration space is a bad. > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net From nobody Tue Jul 13 18:42:41 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067413A0FF7 for ; Tue, 13 Jul 2021 18:42:40 -0700 (PDT) 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 Nns2Cucb6Qxl for ; Tue, 13 Jul 2021 18:42:35 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432EF3A0FF5 for ; Tue, 13 Jul 2021 18:42:34 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m3Tus-0008BX-0p; Tue, 13 Jul 2021 21:42:26 -0400 Date: Tue, 13 Jul 2021 21:42:20 -0400 From: John C Klensin To: Ned Freed , Dave Crocker cc: emailcore@ietf.org Message-ID: <1E50DF3E459CC22EDCA0C00D@PSB> In-Reply-To: <01S1CTN9L5N0005PTU@mauve.mrochek.com> References: <01S1A2HZAB520085YQ@mauve.mrochek.com> <7a4edee1-b0ea-789a-8c50-7e48a7bd82e4@dcrocker.net> <01S1CTN9L5N0005PTU@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Registration is for coordination, not coercion 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, 14 Jul 2021 01:42:40 -0000 Largely agree with both of you. However, please note that extending the same logic too far renders the IETF (and standards more generally) irrelevant because people should just establish whatever arrangements they like and hope they get traction, presumably on a "tell your friends" basis. >From that perspective, while some of the vocabulary we use to describe out requirements is clearly wrong, IETF review and endorsement should (and usually does) guarantee two things. One is that people other than the creators/ authors/ primary advocates have been able to examine a specification, have done so, and, depending on the degree of IETF endorsement, improve upon and/or endorse the spec. Are those steps worth anything? That depends on the degree to which the IETF (and its leadership) takes its role seriously, insists on informed consensus where appropriate, and so on. When a specification is pushed through by a small cabal who are not really interested in review and general input, much less the possibility of making changes (and I suggest we have all seen that happen occasionally), then the endorsement, however presented, is close to meaningless whether the marketplace recognizes that or not. The other is that IETF-endorsed specification are useful in getting ideas into circulation -- marketing them, if you prefer. Perhaps in this world in which a relatively small number of vendors control most of the action in many application areas (including email), that aspect is inefficient and unnecessary: it may be far more efficient for those vendors to collaborate, produce specifications that meet their collective needs, and then either use their proprietary nature to freeze everyone else out or to get everyone else to adopt their ideas because, from a market standpoint, interoperating with the relevant collection of large gorillas is a condition for being useful. So, maybe we need to worry less about what is a "standard" and what isn't and the importance (or lack thereof) about IETF approval/ consensus. Instead, we should concentrate on registration purely to avoid conflicting definitions; try to figure out a way to avoid DoS and large-scale name-squatting attacks on that process; stress the importance of published, easily-accessible, well-vetted, and clear and comprehensible documents; and perhaps give out gold stars for the degree of consensus, document quality, acceptance, and deployment should people decide to apply for them. I am not sure how much difference it would make other than, maybe, reducing the number of unregistered identifiers a bit. But perhaps that is enough. best, john --On Tuesday, July 13, 2021 13:50 -0700 Ned Freed wrote: > Agreed on all points. Our original "IETF specification > required" position for > SMTP extensions was an error. We need to rectify that, and > encouraging > registration, hopefully with a pointer to whatever > specification does exist, is > IMO the right way forward. > > Ned > >> (Subject line changed, to focus on a basic point of concern.) > > >> On 7/11/2021 1:44 PM, Ned Freed wrote: >> > SMTP extensions are another matter. SMTP clients and >> > servers both have to be modified in an interoperable way, >> > and to deploy an extension to any significent extent likely >> > means modifying more than one of each. And for the rare >> > extension that does deploy and which do something people >> > want, tracking down information on them in other to "keep >> > up" can be a bit of pain. > > >> The IETF has always been a bit confused about enforcement. >> The use of normative language encourages the misguided view >> that authors have a force of law over other folk. This then >> extends into the realm of registration. And yet the IETF's >> success did not come from coercing use but from satisfying >> needs. > >> When there is limited space for registration, figuring out a >> possibly-restrictive policy for allocations is required. In >> other cases, it probably isn't. > >> The view that restrictive registration policies are otherwise >> necessary seems to come from a failure to distinguish tasks. >> Standardization is where community 'approval' lies. Not >> registration. Registration is for disciplined administerion >> of an identification space. > >> We invoke a vague fear of potential harm from an allocation >> that involves activity that is not properly vetted. So we >> require a specification, or even that it be standardized. >> But the danger of requiring neither lacks a demonstrable >> danger. Intuitively, the fear is reasonable, but, well... >> you know... theory vs. practice... > >> Say a random SMTP extension name is registered, and it has no >> specification. As long as the meta-rule is "ignore what you >> don't understand", what is the danger? And note that this >> case is already present, for UNregistered identifiers. So, >> really, the question is what is the incremental danger from >> registering such allocations? > >> Say a random SMTP extension name is registered and has an >> associated specification that is crappy. For this to cause >> meaningful damage both client and server implementers must >> fail to see how crappy it is. Again, this case already >> happens, such as with some 'experimental' specifications that >> actually do get IETF approval; and maybe even some standards >> track ones. Again, what is the danger? > >> There is an absolute, community good to encouraging >> registration, because it makes it unlikely there will be name >> collisions; it advertises the existing of an extension >> activity, and it makes clear who is in charge of use of the >> name. > >> Even requiring a published specification decreases that good. > >> IETF standards do not succeed because their use is required >> but because the community likes the standards. Registration >> should use the same model. > >> It's not that associating a specification isn't also a good. >> And it isn't that standardization isn't a good. It's that >> making them barriers to entry into a registration space is a >> bad. > >> d/ >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net From nobody Tue Jul 13 18:57:34 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A963E3A10B7 for ; Tue, 13 Jul 2021 18:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoyN2xFr4bw1 for ; Tue, 13 Jul 2021 18:57:27 -0700 (PDT) Received: from camel.birch.relay.mailchannels.net (camel.birch.relay.mailchannels.net [23.83.209.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74963A10B3 for ; Tue, 13 Jul 2021 18:57:27 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 487C6280B24; Wed, 14 Jul 2021 01:57:26 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (100-96-13-112.trex-nlb.outbound.svc.cluster.local [100.96.13.112]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 1C1C1280B38; Wed, 14 Jul 2021 01:57:25 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.13.112 (trex/6.3.3); Wed, 14 Jul 2021 01:57:26 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Whistle-Towering: 0885702b134e109c_1626227845937_2836748328 X-MC-Loop-Signature: 1626227845937:2326178296 X-MC-Ingress-Time: 1626227845937 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 2731410E99E5; Wed, 14 Jul 2021 01:57:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1626227844; bh=CcFKPPS2Svm03NaX8xQDqE2HVSrkJg+uFWN3l2q2b/8=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=JZ0Z0Ce+0dae73Kp3BwgO/ne6Il5q5HUpbdtklRK5cypKu+9dJPlly43vQPp9O/5R wJOHnU4ee2REquYn8Iv9SAOstavM+AjI1aA3xlNxehhOsphotBYx1E3aB+n4xSYJN7 /lVKo6VTWZIKtFeh3rxskjxp8PmqLThnKc7s96lFP5AZKtZ76z+Y+/+fhk8/d3le5h 3iO7ElPC99zcvRyTFRbD9py1OOa0IzjiNN+YJL8d6geIKbCXjNe5AKRV6UzZgX9Eri TBgF/HrTP82u6CrWWwmUFn5T5hmQBK4GT/iEWjlu4Xzc1nGZ4cdh8Br0qYLElRb2Rd WK1lnd01d/Kkg== Reply-To: dcrocker@bbiw.net To: John C Klensin Cc: emailcore@ietf.org References: <01S1A2HZAB520085YQ@mauve.mrochek.com> <7a4edee1-b0ea-789a-8c50-7e48a7bd82e4@dcrocker.net> <01S1CTN9L5N0005PTU@mauve.mrochek.com> <1E50DF3E459CC22EDCA0C00D@PSB> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 13 Jul 2021 18:57:22 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <1E50DF3E459CC22EDCA0C00D@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Registration is for coordination, not coercion 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, 14 Jul 2021 01:57:33 -0000 On 7/13/2021 6:42 PM, John C Klensin wrote: > Largely agree with both of you. However, please note that > extending the same logic too far renders the IETF (and standards > more generally) irrelevant because people should just establish > whatever arrangements they like and hope they get traction, > presumably on a "tell your friends" basis. Forgive me, John, but that -- and the rest of your note -- profoundly miss the point I made. Oddly, I'll even claim that my note covered -- and arguably countered -- most of the concerns you seem to be raising, except that some seem to be entirely outside the scope of my note. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jul 14 11:38:40 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2393A1357 for ; Wed, 14 Jul 2021 11:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.684 X-Spam-Level: X-Spam-Status: No, score=-0.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nh5xrjJcUi2 for ; Wed, 14 Jul 2021 11:38:33 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 C16F23A133A for ; Wed, 14 Jul 2021 11:38:33 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id a10so1236007qvj.11 for ; Wed, 14 Jul 2021 11:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lSTaaTlxxu9jdCtsJdPwKpUaYKehQ8oze1xERe4DELk=; b=RJC8BYpOuLeRKclm+vi3I3p42Xk2oSH92tuAvuDWKMUULepSmxaHRm9bob2otj1BBx i+valsqbBHAYCP2JgtVnCHfsDZJpRCCrYjHKVvS92PJH9Yn7/bBI/STu9nSHsPElwATo sx7p1jXjCPzigOEdx0OpNBqaFaeknjvJ/9nWaC4RG3NKXsOr/4Cgb/rpyuuFTvlwRc65 JX2SPH3ImYNw0SY0HPLhnlfq1fy4vRLS3daIbhGuZ5jbXPO7xi0PJAQ1bzTROUzvcOgf WKo0T18TtzREbZad+V0fM7MF34O6TxXe5a7n5eio+GqN/ItHGq3wQmwA3vChOLypqtVj LGRA== 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=lSTaaTlxxu9jdCtsJdPwKpUaYKehQ8oze1xERe4DELk=; b=qQdx6HeBhHQHjZuF0frUFkE9/8cGv+w863weQsBcF6jeEvYL617efb2z6KO15UFZNu l9jgjxEqBh3Cy2hwvdVhZi/C65X3D4+RzK1UNUQE5AeMehfrdKUCC8X+sZ1LwLENBqx6 +XLHa4s2yhBFzbbeuLFsQ2tkI12uW6ULqb5vZAfrCiUa+E0qIyuFgUjjCqvtl1qU4/GW eGgYh+jLY7PPpIKn7AH8+4Mk77B+G3ALP3fiY5tLQlojYu7h838vn6r0nqJOCm0b/AGl xrfz6Yj5JoEeRB0vlJXoYTrronLmQgA83nO/X3l1czl0Vx8oYdt+xZFtRqM0n+giPuOc Ngbw== X-Gm-Message-State: AOAM531iAORXnl7PHszMOD7/cE+9l53Dfqq8cRjiYdGeMOsU+yDqD95v O63cB+BBWvntpQhMBLuLTM3uBiElbDUOrsURTARCrQHo6uU= X-Google-Smtp-Source: ABdhPJzuIaVJZc1nV9+yRKCa7vP5pkiOxQ2+k5Cz0gEZG+NrlB3aunB4kvepqgQnYsGBq5PGnC1uTACj4qXNUh6dUG0= X-Received: by 2002:a0c:abc6:: with SMTP id k6mr12132609qvb.18.1626287911952; Wed, 14 Jul 2021 11:38:31 -0700 (PDT) MIME-Version: 1.0 References: <70e3923f-c3c9-8625-4009-0a4ca0fb5ab0@dcrocker.net> <20210713194736.A65FB214C287@ary.qy> In-Reply-To: <20210713194736.A65FB214C287@ary.qy> From: Todd Herr Date: Wed, 14 Jul 2021 14:38:16 -0400 Message-ID: To: John Levine Cc: emailcore@ietf.org, Dave Crocker Content-Type: multipart/alternative; boundary="0000000000004b736805c719a90a" Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits 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, 14 Jul 2021 18:38:39 -0000 --0000000000004b736805c719a90a Content-Type: text/plain; charset="UTF-8" On Tue, Jul 13, 2021 at 3:47 PM John Levine wrote: > > Speaking of limits, how do we feel about the 1000 octet limit on line > length. It is my impression > that it is often exceeded in HTML text. > > Haven't had occasion to see the issue crop up in a while, but I don't miss having to explain to a content creator that the limit exists, and that left angle bracket b r right angle bracket is not the same as carriage return, line feed. -- *Todd Herr* | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --0000000000004b736805c719a90a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 13, 2021 at 3:47 PM John Levine <johnl@taugh.com> wrote:

Speaking of limits, how do we feel about the 1000 octet limit on line lengt= h.=C2=A0 It is my impression
that it is often exceeded in HTML text.

Haven't had occasion to see the issue crop up in a while, bu= t I don't miss having to explain to a content creator that the limit ex= ists, and that left angle bracket b r right angle bracket is not the same a= s carriage return, line feed.
--

Todd Herr | Technical Director, Standa= rds and Ecosystem
m: 703.220.4153

This email and a= ll data transmitted with it contains confidential and/or proprietary inform= ation intended solely for the use of individual(s) authorized to receive it= . If you are not an intended and authorized recipient you are hereby notifi= ed of any use, disclosure, copying or distribution of the information inclu= ded in this transmission is prohibited and may be unlawful. Please immediat= ely notify the sender by replying to this email and then delete it from you= r system.

--0000000000004b736805c719a90a-- From nobody Wed Jul 14 14:10:31 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FEB3A0C8B for ; Wed, 14 Jul 2021 14:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 UVHa7HQkXofI for ; Wed, 14 Jul 2021 14:10:25 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 0CB7B3A0C8A for ; Wed, 14 Jul 2021 14:10:24 -0700 (PDT) Received: from smtpclient.apple (mobile-107-107-59-83.mycingular.net [107.107.59.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 47FD4DA5BC for ; Wed, 14 Jul 2021 17:10:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Viktor Dukhovni In-Reply-To: <20210713194736.A65FB214C287@ary.qy> Date: Wed, 14 Jul 2021 17:10:22 -0400 Content-Transfer-Encoding: 7bit Reply-To: emailcore@ietf.org Message-Id: References: <20210713194736.A65FB214C287@ary.qy> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits 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, 14 Jul 2021 21:10:30 -0000 > On 13 Jul 2021, at 3:47 pm, John Levine wrote: > > Speaking of limits, how do we feel about the 1000 octet limit on line > length. It is my impression that it is often exceeded in HTML text. FWIW, internally Postfix has no message content line length limit. Long lines (over 2048 bytes) are stored and processed in chunks. That said, lines in messages sent out via SMTP are by default folded at 998+CRLF bytes: http://www.postfix.org/postconf.5.html#smtp_line_length_limit Logical (possibly folded across multiple physical lines) *headers* longer than 100KB are truncated: http://www.postfix.org/postconf.5.html#header_size_limit So it would not be a big deal if the limit were raised, but it would take some years before most Postfix installations upgraded to a release with a higher default limit. If some sites override the default value, they'd have to update their explicit override if too small. -- -- Viktor. From nobody Wed Jul 14 18:12:51 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80EC33A0593 for ; Wed, 14 Jul 2021 18:12:48 -0700 (PDT) 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 et0geQ0uEmdF for ; Wed, 14 Jul 2021 18:12:43 -0700 (PDT) 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 31D533A1385 for ; Wed, 14 Jul 2021 18:12:42 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1EGVWS5E800DLXG@mauve.mrochek.com> for emailcore@ietf.org; Wed, 14 Jul 2021 18:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1626311258; bh=xyc92HOs2fOyKJp6EZgeYt8ciLwKBUeo8V92qVnjoog=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=kSREWsO3nUE5JdR/8Ol9hHCj/eUEHPjU35Lk6jPn8wJKVycap0o45BXRkAEB6EaKR CRsVh6uMDSgXuZME0H+uzGela24zrpU/OtclFn+qkBhYzQOM92zo0XHRJv9jaRqu9W ddfmTECjRgWVozJibM/nNFNupTwB+Ecq6ibZEEDM= 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 <01S0F3SXH38G005PTU@mauve.mrochek.com>; Wed, 14 Jul 2021 18:07:37 -0700 (PDT) Cc: John Levine , emailcore@ietf.org, Dave Crocker Message-id: <01S1EGVVJ7BW005PTU@mauve.mrochek.com> Date: Wed, 14 Jul 2021 18:04:07 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 14 Jul 2021 14:38:16 -0400" References: <70e3923f-c3c9-8625-4009-0a4ca0fb5ab0@dcrocker.net> <20210713194736.A65FB214C287@ary.qy> To: Todd Herr Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 01:12:49 -0000 > On Tue, Jul 13, 2021 at 3:47 PM John Levine wrote: > > Speaking of limits, how do we feel about the 1000 octet limit on line > > length. It is my impression > > that it is often exceeded in HTML text. > Haven't had occasion to see the issue crop up in a while, but I don't miss > having to explain to a content creator that the limit exists, and that left > angle bracket b r right angle bracket is not the same as carriage return, > line feed. Purely anecdotal, but I've noticed that in the past couple of years quite a few HTML senders seem to have newly discovered something called quoted-printable. In any case, I don't see how we can possibly increase the 998+CRLF limit at this point. There are far too many SMTP implementations with fixed buffer sizes that are never going to be updated and will be in use for a long, long time. Nor, frankly, do I see any advantage in doing so given the existence of encoding options like quoted-printable. Ned From nobody Thu Jul 15 01:12:06 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D1E3A21B2 for ; Thu, 15 Jul 2021 01:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 5cr0PYBg5lDj for ; Thu, 15 Jul 2021 01:11:58 -0700 (PDT) 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 A3F383A21AD for ; Thu, 15 Jul 2021 01:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1626336713; bh=+8yLyvy9k7tpsouQ6RFd7K9M3bzgHs4FAOKtfNG4DOk=; l=3901; h=To:References:From:Date:In-Reply-To; b=AkHMIclmbQLn/exdZMrS/j6tEEsY2eZfpKc3BDu2yUjj+hmgZ91sb9TgXWqlMraB1 iRtQr17wLSUoGTuDtuiKikXpTcuuoNUfBmr2LH4oSPzAOqyZgI0/aGNmychdCgrWM6 pAVBCDSA6niG6RRcYCWphOozScuMXuhPjFllS5do/SYZalNdibW7ldjUvlFxX 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 00000000005DC0CB.0000000060EFEDC9.000006A5; Thu, 15 Jul 2021 10:11:53 +0200 To: Ned Freed , emailcore@ietf.org References: <01S1CDHKSDL6005PTU@mauve.mrochek.com> <70e3923f-c3c9-8625-4009-0a4ca0fb5ab0@dcrocker.net> <5e1490c1-a26f-3e39-b5b2-41d3f1c0c6a7@tana.it> <01S1CPIM81KU005PTU@mauve.mrochek.com> From: Alessandro Vesely Message-ID: Date: Thu, 15 Jul 2021 10:11:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <01S1CPIM81KU005PTU@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 #14: G.7.8. Review different size limits X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 08:12:04 -0000 On Tue 13/Jul/2021 20:16:35 +0200 Ned Freed wrote: >> On Tue 13/Jul/2021 17:32:50 +0200 Dave Crocker wrote: >>> On 7/13/2021 5:52 AM, Ned Freed wrote: >>>> I also note that X.400 has changed from "the mail system we'll all be using >>>> someday" to "only used in limited government/military cases, and even those are >>>> disappearing". Is it really worth mentioning at this point? >> >> Where do those quotes come from? > > They came from me. I'm paraphrasing what many people said back in the 80s when > X.400 was the new hotness and now when it's old and busted. > > It's hard to believe now, but at the time the expectation really was that a > mostly government-run email service based on a universal directory was the > future. > >> Do you have a reference?  When did the change occur? > > These sorts of transitions rarely involve an abrupt change, but as it happens, > in the case of X.400 I did have an "aha" moment. It was back in the early 90s > at the Electronic Mail Association's Message Attachment Working Group (MAWG) > meeting on profiling the File Transfer Body Part and aligning it with MIME. As > the EMA equivalent of the blue sheet started circulating, Nick Shelness stood > up and (more or less) said, "Please include your Internet address on the sheet, > most of the X.400 ones you've provided in the past don't work." > > Since then I've wondered if Nick - among other things, the main author of > Softswitch - knew the significance of what he was saying. Knowing Nick, he > probably did. Thanks for sharing! (https://en.wikipedia.org/wiki/X.400#cite_note-1) >>>> Finally, and most importantly, implementation techniques that impose no limits >>>> on object size represent a serious security risk. I think this alone justifies >>>> removing "should support" bit. >> [...] >> >> I'm not clear what is the security risk.  Clearly, no implementation can be >> truly limitless, since the Universe itself appears to be limited.  Perhaps: >> >>                                                             To the >>     maximum extent possible, implementation techniques that impose no >>     *predefined* limits on the length of these objects should be used. > > That's still a recipe for disaster because people won't know to set them > correctly. Anything without a reasonable limit can  be found by a hacker and > exploited to exhaust resources. That's a general safety rule, not an SMTP-specific provision. Yet, the consideration meant by the sentence could be retained. How about: Up to the point where resource exhaustion would be at stake, implementation techniques that impose no predefined limits on the length of these objects should be used. > It also does nothing to enhance interoperability. Requiring the minimums but > encouraging everyone to implement more opens the door to implementators coding > stuff that assumes larger limits - because what they had in the lab supported > more - but then fails badly when faced with a wider range of implementations on > the Internet. > > IMO at this point interoperability trumps being able to get away with stuff > sometimes. Agreed. However, removing the sentence conveys a much stronger meaning to the size limits given in the spec. It depends on whether we consider them to be hard limits or just reasonable indications given at the time when the spec is being published. Just like X.400 fades out, some trend requiring more space might fade in in the future. Consider the line length limit John mentioned. Consider the overall message length limit, which the spec does not give, but whose range seems to be more or less agreed upon among the vast majority of servers. RCPTLIMIT could impose local hard limits in a more flexible way. Best Ale -- From nobody Thu Jul 15 03:43:18 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D128E3A1FB5 for ; Thu, 15 Jul 2021 03:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 vXm8NXGFRwlg for ; Thu, 15 Jul 2021 03:43:11 -0700 (PDT) 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 97AD53A266F for ; Thu, 15 Jul 2021 03:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1626345787; bh=7b2VH5dinXu4qo0R0UBU+YyXs/CvSxUwtGJZaHKP+LI=; l=462; h=To:References:Cc:From:Date:In-Reply-To; b=A58mDRy64ftPClRrWc4uXVVda+MFQM4gYzovjMnXhAyLvq2+ry1zN5VaAFMBcJPpt 5vNMYvpbGCOJTjS7GVYcTmHcun1T2YgaMthrBcRzzjkzR4fYYoM21fsnE2IxMzC3GK nvYdk7J35oe2iP3oCVzK+hJhlUADXsVIpV9MQo+xVzB0AavRM/OtYx6GYyIt+ 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 00000000005DC0CC.0000000060F0113B.00001C8F; Thu, 15 Jul 2021 12:43:07 +0200 To: Viktor Dukhovni References: <20210713194736.A65FB214C287@ary.qy> Cc: emailcore@ietf.org From: Alessandro Vesely Message-ID: Date: Thu, 15 Jul 2021 12:43:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.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 #14: G.7.8. Review different size limits X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 10:43:17 -0000 On Wed 14/Jul/2021 23:10:22 +0200 Viktor Dukhovni wrote: > > Logical (possibly folded across multiple physical lines) *headers* longer > than 100KB are truncated: > > http://www.postfix.org/postconf.5.html#header_size_limit Worded as in postconf it's not clear whether you mean a whole header rather than a single header field. In the text above, the phrase up to and including the parenthesis suggests the latter interpretation. Best Ale -- From nobody Thu Jul 15 06:45:34 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971C13A08FC for ; Thu, 15 Jul 2021 06:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 QK2ePsGGsZLN for ; Thu, 15 Jul 2021 06:45:29 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 EBCE23A08F8 for ; Thu, 15 Jul 2021 06:45:28 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 934F9DAC8D; Thu, 15 Jul 2021 09:45:27 -0400 (EDT) Date: Thu, 15 Jul 2021 09:45:27 -0400 From: Viktor Dukhovni To: emailcore@ietf.org Message-ID: Reply-To: emailcore@ietf.org References: <20210713194736.A65FB214C287@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 13:45:34 -0000 On Thu, Jul 15, 2021 at 12:43:07PM +0200, Alessandro Vesely wrote: > On Wed 14/Jul/2021 23:10:22 +0200 Viktor Dukhovni wrote: > > > > Logical (possibly folded across multiple physical lines) *headers* longer > > than 100KB are truncated: > > > > http://www.postfix.org/postconf.5.html#header_size_limit > > Worded as in postconf it's not clear whether you mean a whole header rather > than a single header field. In the text above, the phrase up to and including > the parenthesis suggests the latter interpretation. It is *a* header field, but perhaps the text could be made more explicit. The text in http://www.postfix.org/header_checks.5.html has a bit more context, but it is I guess possible to still read it as applying to complete set of message headers as a unit. header_checks mime_header_checks (default: $header_checks) nested_header_checks (default: $header_checks) Lookup tables with content filter rules for message header lines: respectively, these are applied to the initial message headers (not including MIME headers), to the MIME headers any- where in the message, and to the initial headers of attached messages. -------> Note: these filters see one logical message header at a time, -------> even when a message header spans multiple lines. Message headers -------> that are longer than $header_size_limit characters are trun- -------> cated. Anyway, bottom line, large (even unbounded) message *body* line sizes work just fine in Postfix, but logical message headers (used in MIME parsing, header checks, ...) do need a manageable size limit, which is generously set at 100KiB, with longer (individual) headers truncated to not exceed that size. If milters are employed, then the particular milter applications would have to deal with any larger limits, and I don't know if there's any general statement that can be made about support for long logical or physical message header or body lines in milters. -- Viktor. From nobody Thu Jul 15 11:09:09 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCAB3A1737 for ; Thu, 15 Jul 2021 11:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKO98-Lu9lMy for ; Thu, 15 Jul 2021 11:09:02 -0700 (PDT) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172DE3A1736 for ; Thu, 15 Jul 2021 11:09:01 -0700 (PDT) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id 1262616056; Thu, 15 Jul 2021 20:08:59 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 1731B2C0; Thu, 15 Jul 2021 20:08:57 +0200 (CEST) Date: Thu, 15 Jul 2021 20:08:57 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: emailcore@ietf.org Message-ID: <20210715180857.fgWbT%steffen@sdaoden.eu> In-Reply-To: References: <20210713194736.A65FB214C287@ary.qy> Mail-Followup-To: emailcore@ietf.org User-Agent: s-nail v14.9.22-170-g4fc3932ea4 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 18:09:08 -0000 Viktor Dukhovni wrote in : |> On 13 Jul 2021, at 3:47 pm, John Levine wrote: |> |> Speaking of limits, how do we feel about the 1000 octet limit on line |> length. It is my impression that it is often exceeded in HTML text. Normally MIME should come into play then, and apply a content-transfer-encoding to break it down. The problem for (also other) simple-minded software is then to unfold it when decoding. |FWIW, internally Postfix has no message content line length limit. |Long lines (over 2048 bytes) are stored and processed in chunks. That is a desirable approach, congratulations. I wish i were there already. |That said, lines in messages sent out via SMTP are by default folded |at 998+CRLF bytes: There was that UTF-8 RFC from i think a Microsoft guy who soaped this up to say "in modern times a character is the new byte", so that this should now be 1000*4, at least for SMTP, not for 5322-bis, though. Maybe too sloppily said. (My memory says i had an angry moment when AlpineLinux added ICU dependency to postfix in order to support that UTF-8 extension.) Maybe that is a weakness in the original folding algorithm, that whitespace at the begin of follow lines is preserved. Maybe the (now) usual "line-continuation by escaping the linefeed with reverse solidus" would have been the better approach, then one could simply break were desired and it would all not matter. Like it is now artificial whitespace may have happen in the worst case, but --- isn't that itself so artificial that extending the limit of 1000 looks a bit like over-engeneering? Especially since presence of non 7-bit clean data imposes MIME encoding, anyway? | http://www.postfix.org/postconf.5.html#smtp_line_length_limit | |Logical (possibly folded across multiple physical lines) *headers* longer |than 100KB are truncated: | | http://www.postfix.org/postconf.5.html#header_size_limit If i recall correctly i was once stumbling over a dovecot commit which added header truncation like that, too. |So it would not be a big deal if the limit were raised, but it would |take some years before most Postfix installations upgraded to a |release with a higher default limit. If some sites override the |default value, they'd have to update their explicit override if too |small. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Thu Jul 15 13:03:20 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6193A0EA9 for ; Thu, 15 Jul 2021 13:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=HVA2pjBc; dkim=pass (2048-bit key) header.d=taugh.com header.b=Rpf6Dv4i 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 mVRAdUQInK8J for ; Thu, 15 Jul 2021 13:03:09 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9943A0EAD for ; Thu, 15 Jul 2021 13:03:08 -0700 (PDT) Received: (qmail 27389 invoked from network); 15 Jul 2021 20:03:04 -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=6af1.60f09478.k2107; bh=cTKvY8sCJXVoo8wM/u33DULuddiKt6VEiO9e23mhr8A=; b=HVA2pjBc8mDrRDWnPG2DabWkQTHYAdHtvswd4XWIcrcNS5yZwvkNTg/7xKsYAogtQKNfu0p+eZIL/rLlHbAI9cDmk3QHhb7h9K0DUdtC/gn3eC/bksrsfuD+vPosPmCyjLwUd7k2s7sGWICS9B3uSKBRGvYh/uSgllrWKi4kr5olzqVmXh5nRxSqiYyxGPHSEvRMgX5bDHjPSSyvuopsU8ACJ0Bm1SZTua3ZXMhuTX5fLwpoF78LT82Ifx2hgYiFVEAj7X6u8ab1oP6JGGk3lg6KGVzGIXiFaqqLsB/mwwH7Rkpao9SX+nq1QQtSTbZ6LEjIAPDTg78o2ssqo/iOkQ== 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=6af1.60f09478.k2107; bh=cTKvY8sCJXVoo8wM/u33DULuddiKt6VEiO9e23mhr8A=; b=Rpf6Dv4ie+fKFiAhaccKUl8PtzmezFvbhZ/iE9r1vxYPUdUMajI3vK/DcZiFBz9SN2187Pt9YId41GBxyJFqAqHkGmr4o3nyrugvG+v2Nv8MbFVXO82+ValiaYwso/mwdzAcsd/mKD7H0yh6JCg8uxSnYHHI+G86LdeFBI017okQUI5nT61c+hmT3ffTQPoYXgvnnC1Xn9EixDmlEo0VEZPCu8QvCno/FYG98Abzn8E3JewaP265XKOPWTdamsxxPXX4fNPrYwK6/QwTo22ze6G3g1lo5urljCKCl1k2Rb+nOZul1f+Vd0Si/A9JHweiO26FBAfcbAE0FTr/tMj9mg== 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; 15 Jul 2021 20:03:04 -0000 Received: by ary.qy (Postfix, from userid 501) id E0E3023851A3; Wed, 14 Jul 2021 21:51:53 -0400 (EDT) Date: 14 Jul 2021 21:51:53 -0400 Message-Id: <20210715200305.E0E3023851A3@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: ned.freed@mrochek.com In-Reply-To: <01S1EGVVJ7BW005PTU@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 #14: G.7.8. Review different size limits X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 20:03:15 -0000 It appears that Ned Freed said: >In any case, I don't see how we can possibly increase the 998+CRLF limit at >this point. There are far too many SMTP implementations with fixed buffer sizes >that are never going to be updated and will be in use for a long, long time. >Nor, frankly, do I see any advantage in doing so given the existence of >encoding options like quoted-printable. I was wondering if there really are such MTAs or if this is one of those limits that don't matter to the code any more. My MTA allocates all the strings dynamically so if its 3 bytes or a megabyte it dosn't care. Dunno how common that is. R's, John From nobody Thu Jul 15 13:16:45 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067AD3A1390 for ; Thu, 15 Jul 2021 13:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Cms8Fl5A; dkim=pass (2048-bit key) header.d=taugh.com header.b=RmMGIqQx 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 HVcIhY81owPg for ; Thu, 15 Jul 2021 13:16:37 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83ED13A138C for ; Thu, 15 Jul 2021 13:16:37 -0700 (PDT) Received: (qmail 29792 invoked from network); 15 Jul 2021 20:16:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=745e.60f097a4.k2107; bh=TDaTLKWM8nYIli901zfqVHeOxV4ZJAcvf7N+Yv4wg3I=; b=Cms8Fl5ACsMSh9WRr3/oZWNuu1n6iiUjaWnUFQvuFDqB1SVMIIGv1TGT8jAVwc4X1QTE28C0WC/oTweDNBRagAHLfAmkS+b4Ljcj4LIp/UQ9wDyVIfLwEco2qsd/sXMYlnNFXGtFizLoDme0ZD0xTFPj7F2KXPClAdCRj+Y1+28JLNN4YzDpaaI9O7gBjLsNzHNOj9F86ePiAIsLls5Wjez/CUEdVFloLnlnttvjjb8xlCDVoAsI6KZxf+/8LNKC1QgfnCq54qtzYVpNDres/JWHffM56EpcSjCgEDNqaDgDi46KH7N3rVlp+EsgnDzDrgf7JbsRMsLOX07rXni88Q== 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=745e.60f097a4.k2107; bh=TDaTLKWM8nYIli901zfqVHeOxV4ZJAcvf7N+Yv4wg3I=; b=RmMGIqQxMJkoixxwNxuqk9Xr9B2rt6UQ+iOarNibyermt6VDwEt7tcDHqo/M+ZlNQZIoWBdVLMY+8QkAwBe4EYVmpbxx1h+ou1IHuLNGIOwV+gFPEr5VhNUxM5SPL5lRo3kSwma7hzh1YnTltHr5iebvuvepYe5Een6dbOutPn+rzjYOwfO2Q737I1iBRjg3dyxIY+9ErLWQfM0yQUk5sm8G5R8qnXjZs2GW9V0DqjGYELdSMKspv6wzq+d+9j0F2T2wjS28DVKYRAO3Osks6pjPQdpYCo4j7X7SMg3dz7N52CilddOG6SGLhqNEXdsnu5J7Muc4qi7N+H6lc0pj+w== 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; 15 Jul 2021 20:16:36 -0000 Received: by ary.qy (Postfix, from userid 501) id 983BD238781A; Thu, 15 Jul 2021 16:16:38 -0400 (EDT) Date: 15 Jul 2021 16:16:38 -0400 Message-Id: <20210715201638.983BD238781A@ary.qy> From: "John Levine" To: emailcore@ietf.org In-Reply-To: <20210715180857.fgWbT%steffen@sdaoden.eu> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 20:16:43 -0000 It appears that Steffen Nurpmeso said: > |> Speaking of limits, how do we feel about the 1000 octet limit on line > |> length. It is my impression that it is often exceeded in HTML text. >There was that UTF-8 RFC from i think a Microsoft guy who soaped >this up to say "in modern times a character is the new byte", so >that this should now be 1000*4, at least for SMTP, ... That is just wrong. RFC 6532 specifically says if you're sending unencoded UTF-8, the limit is still 1000 octets, not 1000 characters. >Maybe that is a weakness in the original folding algorithm, that >whitespace at the begin of follow lines is preserved. Maybe the >(now) usual "line-continuation by escaping the linefeed with >reverse solidus" would have been the better approach, ... That only applies to headers. The 1000 octet limit applies to the whole message. For text we have flowed text which uses a space at the end of a line as a signal to rewrap. >Especially since presence of non 7-bit clean data imposes MIME >encoding, anyway? Hm. You might want to investigate the 8BITMIME SMTP extension, defined in 1993 and supported by every MTA I've looked at in this millenium. R's, John PS: I don't feel strongly about lifting the 1000 octet limit but I would like to understand how widely it's enforced by mail receivers. From nobody Thu Jul 15 13:58:45 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630CB3A052C for ; Thu, 15 Jul 2021 13:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 2dP-6qLSM02r for ; Thu, 15 Jul 2021 13:58:39 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 0BF223A0475 for ; Thu, 15 Jul 2021 13:58:38 -0700 (PDT) Received: from smtpclient.apple (unknown [63.88.3.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 6FCC6DB0DA for ; Thu, 15 Jul 2021 16:58:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Viktor Dukhovni In-Reply-To: <20210715201638.983BD238781A@ary.qy> Date: Thu, 15 Jul 2021 16:58:36 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: emailcore@ietf.org Message-Id: References: <20210715201638.983BD238781A@ary.qy> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 20:58:43 -0000 > On 15 Jul 2021, at 4:16 pm, John Levine wrote: >=20 > PS: I don't feel strongly about lifting the 1000 octet limit but I = would like > to understand how widely it's enforced by mail receivers. On the receiving side Postfix does not enforce any physical line length limits on message body lines, but as already mentioned logical header headers, and thus of course also any single physical line in a logical header can't exceed 100KiB. The 1000 octet limit is only enforced when sending. --=20 Viktor. From nobody Thu Jul 15 15:19:35 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07733A1369 for ; Thu, 15 Jul 2021 15:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=EneNMdHl; dkim=pass (2048-bit key) header.d=taugh.com header.b=CQzKji0X 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 KEwGg1VzhubK for ; Thu, 15 Jul 2021 15:19:27 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0D13A1371 for ; Thu, 15 Jul 2021 15:19:27 -0700 (PDT) Received: (qmail 45111 invoked from network); 15 Jul 2021 22:19:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=b035.60f0b46c.k2107; bh=tOlLJlRxZCj9eb8ghSQ8K/SFUznjq3GiCoAoZGmM5kE=; b=EneNMdHlldsiwGHBHCnjVdExSlDPfB5fNyV/YZBnwOXtUQESTx58BUZQv3B5yUspzdEYp3ORrrJlvGKU56Y8ICIcd53L8o6J30GMzM/ZvX+B6AypLZCVcTBQXdFvSaXKuVsumgQKYzABcuv31JsP55u56A5uwpZgYhg8nSAAJXKa7dnImW6hikcq0tZIrycEV+IVPshvzLMVE02ocMNRW2dXzMdsarfii061LJiLSSOLYfiI0Sx2GKe0dGgB5rYMeA+Aj5K+UeX4OCXTiZz3VrvWCOYg6IsMefqAjkgffI4IBObYM1pYRNOVcUSjU/jBD0q/m6diR1Y+rMcP290G7w== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=b035.60f0b46c.k2107; bh=tOlLJlRxZCj9eb8ghSQ8K/SFUznjq3GiCoAoZGmM5kE=; b=CQzKji0XXFW7hQF1wvES21nZHW8zhduNi+m6BjqEXtpuhlI5ONSXBNR46rV54yE1M4nINPo4jlw8JAfp7e8i/FsUnggmqVDjNkqE8Umls9zSzr4269GTTlnLfeZpe9l97qLtwSk8AVkZQvm1jLRHAhq50gotIskzABaV3OdanlnmNf1IvceF0Te3aF4cEaAzso6m/ueIriAH9p9FTwrIze6GV9eVAdTcVb0XFee6XWS0yLGjL2f7ESvGolHYbAfXAMT4qW0yG5c1ZqW3Yn9jduvoXDn+B+7huu/P/iLhE2J66SjN4525UEXg1k1wA7h/6Uwxe8CmhpwJvE5VPpJrIg== 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; 15 Jul 2021 22:19:24 -0000 Received: by ary.qy (Postfix, from userid 501) id C6E9F239F6B6; Thu, 15 Jul 2021 18:19:21 -0400 (EDT) Date: 15 Jul 2021 18:19:21 -0400 Message-Id: <20210715221921.C6E9F239F6B6@ary.qy> From: "John Levine" To: emailcore@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 22:19:33 -0000 It appears that Viktor Dukhovni said: >> On 15 Jul 2021, at 4:16 pm, John Levine wrote: >> >> PS: I don't feel strongly about lifting the 1000 octet limit but I would like >> to understand how widely it's enforced by mail receivers. > >On the receiving side Postfix does not enforce any physical >line length limits on message body lines, ... I realize qmail isn't very popular any more, although you will find it hiding in the guts of a lot of packaged mail systems. For incoming messages, it's all dynamic and there's no length limits. For outgoing messages it politely wraps headers to 80 bytes but leaves bodies alone. From nobody Fri Jul 16 01:08:30 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E303A2BE5 for ; Fri, 16 Jul 2021 01:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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, T_SPF_HELO_TEMPERROR=0.01, 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 r6ayFFUVT_lP for ; Fri, 16 Jul 2021 01:08:23 -0700 (PDT) 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 676183A2BE4 for ; Fri, 16 Jul 2021 01:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1626422896; bh=C66F9fIdJ8Manti2S63ekFmGwrybmrOjJw7bU/M526w=; l=925; h=To:References:From:Date:In-Reply-To; b=CULpSWyLOxzI8yzr0LBa1Y3dUOVWF7KfiyoZI67nhF8AqcX3qk1c2adJVLvb2QCug KissQVqbwiTVPlMpKQk97Fk+t9QGJv5DfNl3JtcCF90t8xd4RGmUl0nmFuiCIPfCbY 6citAGixttFVn2haKs0xhiV0WAQYjLlxW2wiOpkM8VTuy0QJzhQlGRdgNa2uK 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 00000000005DC0BA.0000000060F13E6F.000040B7; Fri, 16 Jul 2021 10:08:15 +0200 To: emailcore@ietf.org References: <20210715221921.C6E9F239F6B6@ary.qy> From: Alessandro Vesely Message-ID: <8b551cf1-131b-cf43-5e61-cabf6fb9e2e6@tana.it> Date: Fri, 16 Jul 2021 10:08:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210715221921.C6E9F239F6B6@ary.qy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 08:08:29 -0000 On Fri 16/Jul/2021 00:19:21 +0200 John Levine wrote: > It appears that Viktor Dukhovni said: >>> On 15 Jul 2021, at 4:16 pm, John Levine wrote: >>> >>> PS: I don't feel strongly about lifting the 1000 octet limit but I would like >>> to understand how widely it's enforced by mail receivers. >> >>On the receiving side Postfix does not enforce any physical >>line length limits on message body lines, ... > > I realize qmail isn't very popular any more, although you will find > it hiding in the guts of a lot of packaged mail systems. For incoming > messages, it's all dynamic and there's no length limits. For outgoing > messages it politely wraps headers to 80 bytes but leaves bodies alone. Courier has similar limits on submission. Some 100000 for the whole header (configurable since 2007, BOFHHEADERLIMIT) and 5000 bytes line length limit. Best Ale -- From nobody Fri Jul 16 08:41:19 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E623A3B5F for ; Fri, 16 Jul 2021 08:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 6lgOcLoHi8vh for ; Fri, 16 Jul 2021 08:41:11 -0700 (PDT) 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 1B90E3A3B60 for ; Fri, 16 Jul 2021 08:41:10 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1GPI0SC1C00DNIC@mauve.mrochek.com> for emailcore@ietf.org; Fri, 16 Jul 2021 08:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1626449767; bh=3Dn0mrMiGQFKXTWISiIs7gcnwrj0LN1Oe60uv/gQGYM=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=fdvGIFQbTJ+rkGwDYPG01dj4ez9X8jvsGMImVlhr4fZlCuiqbWGEIPeaYwzywHQkO sWHTm88E9zHEn75UWLT+iPATF1dgNxZeCSNBFVsnqvOUrDTU+f+rmkX3Htoh4uNBHP PtWvGgioDKy9v+IVUbYOYs39DWIvwG8+SESMJIC0= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S0F3SXH38G005PTU@mauve.mrochek.com>; Fri, 16 Jul 2021 08:36:05 -0700 (PDT) Cc: emailcore@ietf.org Message-id: <01S1GPHZJUWQ005PTU@mauve.mrochek.com> Date: Fri, 16 Jul 2021 08:34:35 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 16 Jul 2021 10:08:15 +0200" <8b551cf1-131b-cf43-5e61-cabf6fb9e2e6@tana.it> References: <20210715221921.C6E9F239F6B6@ary.qy> <8b551cf1-131b-cf43-5e61-cabf6fb9e2e6@tana.it> To: Alessandro Vesely Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 15:41:17 -0000 > On Fri 16/Jul/2021 00:19:21 +0200 John Levine wrote: > > It appears that Viktor Dukhovni said: > >>> On 15 Jul 2021, at 4:16 pm, John Levine wrote: > >>> > >>> PS: I don't feel strongly about lifting the 1000 octet limit but I would like > >>> to understand how widely it's enforced by mail receivers. > >> > >>On the receiving side Postfix does not enforce any physical > >>line length limits on message body lines, ... > > > > I realize qmail isn't very popular any more, although you will find > > it hiding in the guts of a lot of packaged mail systems. For incoming > > messages, it's all dynamic and there's no length limits. For outgoing > > messages it politely wraps headers to 80 bytes but leaves bodies alone. > Courier has similar limits on submission. Some 100000 for the whole header > (configurable since 2007, BOFHHEADERLIMIT) and 5000 bytes line length limit. It's really quite unfortunate that there's no limit specified on header size, since sending a huge header is yet another way to exhaust resources on a poorly implemented MTA. However, adding one is clearly beyond the scope of what we're allowed to do in emailcore. Even a change to make the limits we have "real" is pushing it. Ned > -- > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore From nobody Fri Jul 16 08:52:58 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC553A3BD6 for ; Fri, 16 Jul 2021 08:52:48 -0700 (PDT) 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 fmQIf8HIlzit for ; Fri, 16 Jul 2021 08:52:44 -0700 (PDT) Received: from mail-ob.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id D820D3A0913 for ; Fri, 16 Jul 2021 08:52:42 -0700 (PDT) Received: (qmail 31307 invoked from network); 16 Jul 2021 15:52:40 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (AES128-GCM-SHA256 encrypted) SMTP (d99f7f72-e64d-11eb-9f59-c35c2591458d); Fri, 16 Jul 2021 08:52:40 -0700 To: emailcore@ietf.org References: <20210715221921.C6E9F239F6B6@ary.qy> <8b551cf1-131b-cf43-5e61-cabf6fb9e2e6@tana.it> <01S1GPHZJUWQ005PTU@mauve.mrochek.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: Date: Fri, 16 Jul 2021 08:52:40 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <01S1GPHZJUWQ005PTU@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 2.2.x-3.x X-MagicMail-UUID: d99f7f72-e64d-11eb-9f59-c35c2591458d 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 #14: G.7.8. Review different size limits X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 15:52:58 -0000 Vote against changing existing limits, it is not just MTA's that have to deal with this, but many email analytics programs etc.. But I agree that we should consider some 'best practices' size limits on headers.. Can we start looking at existing limits in more details? But as I think John pointed out, creators of HTML messages have long be operating with poor practices. Have even seen some messages where the whole HTML part was on a single line. But we could have a SHOULD indication of max line limits, while a long line is 'technically' not an issue, there are many practical examples why it is not preferred, eg string matching in long lines, not to mention simple things like viewing a message source and how ugly difficult this is when the message creates a very long scroll window. On 2021-07-16 8:34 a.m., Ned Freed wrote: >> On Fri 16/Jul/2021 00:19:21 +0200 John Levine wrote: >> > It appears that Viktor Dukhovni  said: >> >>> On 15 Jul 2021, at 4:16 pm, John Levine wrote: >> >>> >> >>> PS: I don't feel strongly about lifting the 1000 octet limit but I >> would like >> >>> to understand how widely it's enforced by mail receivers. >> >> >> >>On the receiving side Postfix does not enforce any physical >> >>line length limits on message body lines, ... >> > >> > I realize qmail isn't very popular any more, although you will find >> > it hiding in the guts of a lot of packaged mail systems.  For incoming >> > messages, it's all dynamic and there's no length limits.  For outgoing >> > messages it politely wraps headers to 80 bytes but leaves bodies alone. > > >> Courier has similar limits on submission.  Some 100000 for the whole >> header >> (configurable since 2007, BOFHHEADERLIMIT) and 5000 bytes line length >> limit. > > It's really quite unfortunate that there's no limit specified on header > size, since sending a huge header is yet another way to exhaust resources > on a poorly implemented MTA. > > However, adding one is clearly beyond the scope of what we're allowed to > do in emailcore. Even a change to make the limits we have "real" is pushing > it. > >                 Ned > > > > > > > > > > > > >> -- >> Emailcore mailing list >> Emailcore@ietf.org >> https://www.ietf.org/mailman/listinfo/emailcore > -- "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 Fri Jul 16 08:56:33 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AF23A3BBD for ; Fri, 16 Jul 2021 08:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFJZYZek8b0U for ; Fri, 16 Jul 2021 08:56:26 -0700 (PDT) Received: from cross.elm.relay.mailchannels.net (cross.elm.relay.mailchannels.net [23.83.212.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B0B13A3BB3 for ; Fri, 16 Jul 2021 08:56:25 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 766DF840050; Fri, 16 Jul 2021 15:56:24 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (100-105-161-168.trex-nlb.outbound.svc.cluster.local [100.105.161.168]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 4E015840074; Fri, 16 Jul 2021 15:56:23 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (35.45.192.35.bc.googleusercontent.com [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.105.161.168 (trex/6.3.3); Fri, 16 Jul 2021 15:56:23 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Attack-Continue: 449fb3a90d951056_1626450983689_512634723 X-MC-Loop-Signature: 1626450983689:4098980566 X-MC-Ingress-Time: 1626450983688 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 78574310E138; Fri, 16 Jul 2021 15:56:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1626450982; bh=LorAwOMMk1LPBk9Wmnh5K7z2agzHsrOT0sATQRw+vU4=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=UeqxWVIY4Lz2AQefPxRaGeHQAnzUt0leL6Ji/hAoVuzo7lFNYzDrKnYJULI8ezqxx sRBwJ5uIuLC7FI9muZcqzqz70GhlvYLpSOMiIGcqWmLX46IemJtib3gOocs3CedtVB PZ8u9y+PtJbEO2WCXPKtXO13X7NQyO7BU7AglfqE1nXFzPJ2foFSlN469+QhKavi1J bu5Zxf80FbHwVGQKq8SCaPCIRWU0+3z10IK6zxrvdSy8xolmNcWpwNnrKX8gfMLT7A XKuLY5ylhKZaNPmmBbbcIodfiSjq/aKV7LtECfJn+qLRnNyd+ZpJuVsdLwkayDRmwp d3y+s2pYrCg6w== Reply-To: dcrocker@bbiw.net To: Michael Peddemors , emailcore@ietf.org References: <20210715221921.C6E9F239F6B6@ary.qy> <8b551cf1-131b-cf43-5e61-cabf6fb9e2e6@tana.it> <01S1GPHZJUWQ005PTU@mauve.mrochek.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <8144001a-d72c-0aa9-aa8b-9957d1ebe2d0@dcrocker.net> Date: Fri, 16 Jul 2021 08:56:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.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: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 15:56:31 -0000 On 7/16/2021 8:52 AM, Michael Peddemors wrote: > Vote against changing existing limits, it is not just MTA's that have to > deal with this, but many email analytics programs etc.. +1 Unless I missed it in the thread, I didn't see any documentation of a serious problem that needs fixing, nevermind a serious benefit to be obtained, but it's clear changing limits imposes a systemic effect, which the current effort seeks to minimize. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jul 16 09:47:30 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1643A3D3E for ; Fri, 16 Jul 2021 09:47:29 -0700 (PDT) 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 hQidNy8a-LI7 for ; Fri, 16 Jul 2021 09:47:25 -0700 (PDT) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C385B3A3D3D for ; Fri, 16 Jul 2021 09:47:24 -0700 (PDT) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id 0BCAF16056; Fri, 16 Jul 2021 18:47:20 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 02091316; Fri, 16 Jul 2021 18:29:13 +0200 (CEST) Date: Fri, 16 Jul 2021 18:29:13 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: "John Levine" Cc: emailcore@ietf.org Message-ID: <20210716162913.mo0D2%steffen@sdaoden.eu> In-Reply-To: <20210715201638.983BD238781A@ary.qy> References: <20210715201638.983BD238781A@ary.qy> Mail-Followup-To: "John Levine" , emailcore@ietf.org User-Agent: s-nail v14.9.22-170-g4fc3932ea4 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 16:47:30 -0000 John Levine wrote in <20210715201638.983BD238781A@ary.qy>: |It appears that Steffen Nurpmeso said: |>|> Speaking of limits, how do we feel about the 1000 octet limit on line |>|> length. It is my impression that it is often exceeded in HTML text. | |>There was that UTF-8 RFC from i think a Microsoft guy who soaped |>this up to say "in modern times a character is the new byte", so |>that this should now be 1000*4, at least for SMTP, ... | |That is just wrong. RFC 6532 specifically says if you're sending unencoded |UTF-8, the limit is still 1000 octets, not 1000 characters. Yes, "octet" was the used term. In the tradition of preceeding RFCs. I surely was too sloppy here. |>Maybe that is a weakness in the original folding algorithm, that |>whitespace at the begin of follow lines is preserved. Maybe the |>(now) usual "line-continuation by escaping the linefeed with |>reverse solidus" would have been the better approach, ... | |That only applies to headers. The 1000 octet limit applies to the |whole message. For text we have flowed text which uses a space at |the end of a line as a signal to rewrap. Yes. (But for headers there is a SHOULD for automatic wrapping (at 78), whereas bodies i would expect to be left alone unless the limit of "at least / no lower than 1000" is excessed; for any software that is not a pure MTA i would expect convertion to MIME and using a content-transfer-encoding instead. You very often see this even enforced, for example on Mailman-driven mailing-lists, where you are turned to base64 encoding whether useful/necessary or not. This started somewhen before Python 3 was truly released, and it was still like this when i stopped looking at email content regulary not too far in the past, .. which must have been shorty before Mailman 2 was deprecated by support for Python 2 has ended, i think.) |>Especially since presence of non 7-bit clean data imposes MIME |>encoding, anyway? | |Hm. You might want to investigate the 8BITMIME SMTP extension, defined in |1993 and supported by every MTA I've looked at in this millenium. I have these RFCs (i have 6152 locally, it obsoleted 1652). But i do not think i have ever encountered usage of this myself. |R's, |John | |PS: I don't feel strongly about lifting the 1000 octet limit but I \ |would like |to understand how widely it's enforced by mail receivers. I would assume transmission is rejected for any such email? About line reading via fgets(3) and finite buffer .. this is really more common than one would think, especially in elder software. Ever since i "really" program this was a "oh no no no, do not do that!", so i personally ((basic ->) perl -> Java -> C++/C) never actively used this i think (when i could make a decision, ie, for C++/C). I surely have seen fly by commits of *BSD base-system software turning over such to dynamic line readers over the last decade, where still necessary (OpenBSD thus)! The Unix console no. 1 MUA mutt turned many many code places to a dynamic buffer type over the last hm maybe two years for sure, but it surely did it right before already. That is, from the MUA side i would not expect to many restrictions on the consumption side, at least in Unix i would expect them all to honour "be liberal in what you expect and strict in what you produce"; i have collected some test mails that happened to happen over the last decade, and at least at the beginning i compared how other Unix console mailers (and once even Apple Mail, of Snow Leopard, but no) behave ... hm, the longest header line is 1009 bytes; there is a References: that is folded but spans more than a full screen of a 212x58 screen, hmm, a (maybe manually made worse) spam mail ("ANGLO AMERICA PLATINUM UK ONLINE <*@outlook.com>") in 54.header-mem-booom.mbox. This is from 2015, i have forgotten whether i was still cross-testing by then. --End of <20210715201638.983BD238781A@ary.qy> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Fri Jul 16 11:13:08 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C3A3A3FB0 for ; Fri, 16 Jul 2021 11:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=enOl7ylD; dkim=pass (2048-bit key) header.d=taugh.com header.b=r0whzYAr 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 IMzVpRapi_bZ for ; Fri, 16 Jul 2021 11:13:00 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C593A3FB1 for ; Fri, 16 Jul 2021 11:13:00 -0700 (PDT) Received: (qmail 39991 invoked from network); 16 Jul 2021 18:12:58 -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=9c35.60f1cc2a.k2107; bh=i6kZ+cUx7bCM+2E2v4EdZ8In2znLuqiPHIhJXzAP9/k=; b=enOl7ylDwFJrccIOqZwvWNBWSA11xi0Co79Bxkm/muS6sSVZwasBFEzyD2NFezcXhCl2bkjB0LaYxzY5NXhTxGUUkiunVzAogTfYTR6dEwlyGT1RGb1N1uHEV6e9nP4BpCMhDx8N78ccOBSneFU05PolOf6q4p5+rqTR6CYSbQsxSRVz2FWWfqAiqX5gIE/cqZ0ZIPeVI4OMXPrDITApIpehDbT8xdrYf7s9uif/zx+RBEjQSxHsCclHqm2S4f0UtbdXulOgJl0SNfUVybMl8FXtXgeHDNLDA+b+zaleHnWxQZrPXSwyLRLcne1VoyLPjYOt/YhurP6CchXKbk8/FQ== 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=9c35.60f1cc2a.k2107; bh=i6kZ+cUx7bCM+2E2v4EdZ8In2znLuqiPHIhJXzAP9/k=; b=r0whzYArG0it54F/ZyGDZYftn4JtZX98IBK2lRTrZ2fZRn10O3YqMLisppvQpqq9BKyVfjAg/w1yQ/CRlvXwt+JmUYZAdbBIHS5YDvMDrtkuzXQblQzt+lrXxbJynOZNUu6vh2gHTsvIRgRfeHSo8MCv1C+Q32INbDkHOBde0WJYfwnGyA1bN9cqiOqTd4TpO1XgUasSb/QcUBicdpyH/3BjtRL4f3gtrAR2nKht5TncWgKPvqY4uqlhd58+0MBS+XjGRj3s8vavEGu+a9/tXbcpUp0fGWW7TwEmJruV3QLQaw3+Q9GUBLy9wbYeLyZvIMQih8qOSkUaSbX0DwSf+Q== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 16 Jul 2021 18:12:57 -0000 Received: by ary.qy (Postfix, from userid 501) id E397D247DB2A; Fri, 16 Jul 2021 14:12:57 -0400 (EDT) Date: 16 Jul 2021 14:12:57 -0400 Message-Id: <20210716181257.E397D247DB2A@ary.qy> From: "John Levine" To: emailcore@ietf.org In-Reply-To: <20210716162913.mo0D2%steffen@sdaoden.eu> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 18:13:06 -0000 According to Steffen Nurpmeso : > |>Especially since presence of non 7-bit clean data imposes MIME > |>encoding, anyway? > | > |Hm. You might want to investigate the 8BITMIME SMTP extension, defined in > |1993 and supported by every MTA I've looked at in this millenium. > >I have these RFCs (i have 6152 locally, it obsoleted 1652). But >i do not think i have ever encountered usage of this myself. I see unencoded UTF-8 in mssages bodies all the time. ¡Hola! 😕 > |PS: I don't feel strongly about lifting the 1000 octet limit but I \ > |would like |to understand how widely it's enforced by mail receivers. > >I would assume transmission is rejected for any such email? Not that I've ever seen but I haven't looked very hard. I think it's more common to stuff in a \r\n and continue. Anyway, I think we've agreed that the 1000 octet limit isn't changing. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Jul 17 09:17:19 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6743A16A9 for ; Sat, 17 Jul 2021 09:17:17 -0700 (PDT) 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 a6X8uV0ZbUe7 for ; Sat, 17 Jul 2021 09:17:10 -0700 (PDT) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975F33A16A8 for ; Sat, 17 Jul 2021 09:17:10 -0700 (PDT) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id 381C916056; Sat, 17 Jul 2021 18:16:59 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 0C64F334; Sat, 17 Jul 2021 18:16:57 +0200 (CEST) Date: Sat, 17 Jul 2021 18:16:57 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: John Levine Message-ID: <20210717161657.XGPW_%steffen@sdaoden.eu> In-Reply-To: <20210716181257.E397D247DB2A@ary.qy> References: <20210716181257.E397D247DB2A@ary.qy> Mail-Followup-To: John Levine User-Agent: s-nail v14.9.22-170-g4fc3932ea4 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 #14: G.7.8. Review different size limits 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, 17 Jul 2021 16:17:18 -0000 John Levine wrote in <20210716181257.E397D247DB2A@ary.qy>: |According to Steffen Nurpmeso : |>|>Especially since presence of non 7-bit clean data imposes MIME |>|>encoding, anyway? |>| |>|Hm. You might want to investigate the 8BITMIME SMTP extension, defined= \ |>|in |>|1993 and supported by every MTA I've looked at in this millenium. |> |>I have these RFCs (i have 6152 locally, it obsoleted 1652). But |>i do not think i have ever encountered usage of this myself. | |I see unencoded UTF-8 in mssages bodies all the time. =C2=A1Hola! =F0=9F= =98=95 Your MUA created the according MIME headers, but whether it used the 8BITMIME SMTP extension when passing this over to a MTA, that is here the question. Some may not, the one i took maintainership of for example surely never did, yet supports 8bit and simply passed it over, and whereas i changed the default content- transfer-encoding the SMTP code is more or less unchanged in released versions. (That will change with the next, whenever that is, i am late by half a year at minimum, but 8BITMIME not yet in there, so you maybe even earned a credit in defiance of your invalid mail address.) I have not encountered problems from the SMTP side when actually trying out aka using these defaults (years ago), so it seems there are quite liberal SMTP engines around. |>|PS: I don't feel strongly about lifting the 1000 octet limit but I \ |>|would like |to understand how widely it's enforced by mail receivers. |> |>I would assume transmission is rejected for any such email? | |Not that I've ever seen but I haven't looked very hard. I think it's |more common to stuff in a \r\n and continue. You surely do not change body content but by doing the full MIME dance right. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Sat Jul 17 09:50:42 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA303A17F3 for ; Sat, 17 Jul 2021 09:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=1kod6+ZV; dkim=pass (2048-bit key) header.d=wizmail.org header.b=foNqPbsi 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 zEcs6ALnPQjt for ; Sat, 17 Jul 2021 09:50:33 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A8C23A17F0 for ; Sat, 17 Jul 2021 09:50:32 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=S1bbbdOPM/UFWwgdfdGGpYGZ8/V+cVMkcSL2Hcw8t5Q=; b=1kod6+ZVzn2ATe+uilB7jNuxaD djrEQHOA8aTbuDbu7hCOrsJ05YpFi5Q9WxQC+0ZTEyyzb6v6nPkcXGNYN8Cg==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=S1bbbdOPM/UFWwgdfdGGpYGZ8/V+cVMkcSL2Hcw8t5Q=; b=foNqPbsicc9vjpXDJw4IsuBJzJ AfB5aJDudQ/+BlRq5DVMgzmO3BTsRzc0xp49sakkfrzAQrdxvp8rT+Mt9bLKWaMrem6Xa24ShoT3n QplE1IdCS0ZO/RRoVGppLYUnS5GrMhi2X0blfXbeYnsfWr9mlJUhYzCDDV7fzXz7EqFRp/oz4B0iu lCLKyVArU31YJNMEoxzfzrjbeXyESqFC2I09lRF6UPCrjlVKF/UW7qJOqAC5gYcgG4hEpAN39oiFR Nr63dUPjFXj2U2f5F3PZ7Apt2r/Li+SMY9SwZ21wta7ipgDsDfu2IzGZLd5khVUgE5UuZz3luUgAP Ql/Spcqw==; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.94.128) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1m4nWH-005aMr-Cx for emailcore@ietf.org (return-path ); Sat, 17 Jul 2021 16:50:29 +0000 To: emailcore@ietf.org References: <20210716181257.E397D247DB2A@ary.qy> <20210717161657.XGPW_%steffen@sdaoden.eu> From: Jeremy Harris Message-ID: <7167164a-5c14-f6f2-4692-06da2506d158@wizmail.org> Date: Sat, 17 Jul 2021 17:50:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210717161657.XGPW_%steffen@sdaoden.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits 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, 17 Jul 2021 16:50:40 -0000 On 17/07/2021 17:16, Steffen Nurpmeso wrote: > Your MUA created the according MIME headers, but whether it used > the 8BITMIME SMTP extension when passing this over to a MTA, that > is here the question. See https://cr.yp.to/smtp/8bitmime.html for one opinion, written quite a long time ago. Exim has been following that for the last nine years. -- Cheers, Jeremy From nobody Sat Jul 17 11:14:19 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6012C3A1AAB for ; Sat, 17 Jul 2021 11:14:18 -0700 (PDT) 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 N6y8CmmMyEDf for ; Sat, 17 Jul 2021 11:14:12 -0700 (PDT) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46DB03A1AA9 for ; Sat, 17 Jul 2021 11:14:11 -0700 (PDT) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id BD76816056; Sat, 17 Jul 2021 20:14:00 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id B732C343; Sat, 17 Jul 2021 20:13:58 +0200 (CEST) Date: Sat, 17 Jul 2021 20:13:58 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Jeremy Harris Cc: emailcore@ietf.org Message-ID: <20210717181358.sHnj6%steffen@sdaoden.eu> In-Reply-To: <7167164a-5c14-f6f2-4692-06da2506d158@wizmail.org> References: <20210716181257.E397D247DB2A@ary.qy> <20210717161657.XGPW_%steffen@sdaoden.eu> <7167164a-5c14-f6f2-4692-06da2506d158@wizmail.org> Mail-Followup-To: Jeremy Harris , emailcore@ietf.org User-Agent: s-nail v14.9.22-170-g4fc3932ea4 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits 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, 17 Jul 2021 18:14:18 -0000 Jeremy Harris wrote in <7167164a-5c14-f6f2-4692-06da2506d158@wizmail.org>: |On 17/07/2021 17:16, Steffen Nurpmeso wrote: |> Your MUA created the according MIME headers, but whether it used |> the 8BITMIME SMTP extension when passing this over to a MTA, that |> is here the question. | |See https://cr.yp.to/smtp/8bitmime.html for one opinion, written quite |a long time ago. Exim has been following that for the last nine years. I have to say i never quite understood the "an email message must be human readable text" approach. It is fine in Plan9 Nupas or something, were (the individual parts of) your mail messages are converted to files which are accessible with the normal Unix text processing tool chain, via a "pseudo" filesystem. But for over- the-wire, or even local storage, noone ever cared (mostly) for binary storage of databases, office documents, calendars or whatever. I mean yes of course they do, but mostly not in respect to "i can use my normal Unix text toolchain on those files". (Just in case anyone feels RTF or XML or VCARD or JSON or whatever is something really humanoid.) I for one hate it that i have to add JSON parsing for SMTP and other protocols just for the OAUTH authentication handshake, where K1=V1\0K2=V2\0\0 would do, (i will use jsmn, many open source people do, also from mailers, take nmh for example, but mind you, it maps to "object"s with "length"s, 'thus provides the full JSON power), but get the "we are so much better than you and you just do not get it right" attitude when i claim that a mail message in raw form is just a container of some type. I have no problem with MBOX and MIME content encoding, and why Maildir is easier to dig for humans given the file naming scheme than MBOX is, i never understood. So technical 7-bit limits have long vanished, and 8-bit with many NULs (given the UTF-16 common in some worlds, and of course in binary anyway) is no problem, for message data as such i never got that message/global and everything is just human text thing. Calling the sewer that a real life message is human text is a cultural bankruptcy and philosophically contemptible. Not that engineers ever cared those aspects of life (as long as the code of conduct is followed), but it may be mentioned once. And while mentioning things, one or two months ago i created a Microsoft Outlook account because i wanted to check OAuth updates that my little MUA needs, and whereas IMAP just worked out of the box POP3 did not at all even though checked, and SMTP also did not because i never knew, and when after several unsuccessful tries i was sending Date: Sat, 05 Jun 2021 23:02:56 +0200 From: Steffen Nurpmeso To: steffen@sdaoden.eu Subject: Please, i want SMTP for microsoft Message-ID: <20210605210256.gx5cQdqq@outlook.com> Yea?? they locked my account and want my phone number to get out of that, because of policy violation, and so i thought it was time to quit. However i was long enough there to find it applicable to add several _classes_ of mail headers to my ignore list (^IronPort ^MGA ^Spam ^(Accept|Content)-Language ^Thread-) (for message saving only). A nice Sunday everybody. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Sat Jul 17 15:09:53 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9453A23F5 for ; Sat, 17 Jul 2021 15:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=hZFDw4pY; dkim=pass (2048-bit key) header.d=taugh.com header.b=EZMwql0o 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 9SAYFyqKSbVx for ; Sat, 17 Jul 2021 15:09:44 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2832E3A23F3 for ; Sat, 17 Jul 2021 15:09:43 -0700 (PDT) Received: (qmail 44226 invoked from network); 17 Jul 2021 22:09:41 -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=acbf.60f35525.k2107; bh=ZpVg7TEuHvd/OZBh2YRl0qRjFatN5CeeYFNBGubTy9g=; b=hZFDw4pYSfS9ygqOjIBl4sZ2NO/4XzX30e81N0hXh1nIMn6xsDMS/1KFkOXK8KHTXer7exYKCYWTNhOylAboQDIuWO+ITrvlVxvNNmkXlYfZOhHNEO7VOg9E3c4rJnmujuKO3x+BK79WWKFudcETm66Q7hhHjQn+wHptIz/ydmbxFDgF/CgqfbW3GDM0fdwTVf2HR3lpmj+rO3y4Uf25PpPASExRRR6II8AmfpyX6t9wl+o6KElvbinzcJVO2KJTV1UlbgjXn26/OgIAdEp+AnPVddcSSdCXFVtzNZwYFByFEetdBynD9xr42H0rQcvX1Mhs9C+9yMPfSZXsAGsT3w== 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=acbf.60f35525.k2107; bh=ZpVg7TEuHvd/OZBh2YRl0qRjFatN5CeeYFNBGubTy9g=; b=EZMwql0oKTWFjNYGBLaFP3yTzfhj8zd+3znvOSbMvXCuJYOlX3HTq2kU3T6jfQy2Lp2J6i7n3UXOaOX8JPbPJAcPCHY/PGQ78+qwY+5T/JKiV7KiIP9ge+OPp0WOti9XveEbWrdKC0tVFkL9olUeNHQ+/Q6oNJWDZlzNdXyzFFKfB1oNFIpxWmMttD8G7fDoyDPmJlvr06KPr6CX+I8hqKgzHbbdPl2K8SQIAHsZRcqMBC5ony2vk+HMHxnF9KV4wXtQm6SyQiIKeFv/O+y25H0zSiCKPwGQcYPwuwxzixhEyvi+c2HVi0iFDgKnwC+8pKJU7gxok1CTpa9+ErK2gQ== 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; 17 Jul 2021 22:09:41 -0000 Received: by ary.qy (Postfix, from userid 501) id E225824AAB35; Sat, 17 Jul 2021 18:09:40 -0400 (EDT) Date: 17 Jul 2021 18:09:40 -0400 Message-Id: <20210717220940.E225824AAB35@ary.qy> From: "John Levine" To: emailcore@ietf.org In-Reply-To: <20210717161657.XGPW_%steffen@sdaoden.eu> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits 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, 17 Jul 2021 22:09:51 -0000 It appears that Steffen Nurpmeso said: > |I see unencoded UTF-8 in mssages bodies all the time. ¡Hola! 😕 > >Your MUA created the according MIME headers, but whether it used >the 8BITMIME SMTP extension when passing this over to a MTA, that >is here the question. The answer is yes. My MTA is qmail which has never recoded stuff on the fly. Neither does Postfix or sendmail, at least not with their default settings. >I have not encountered problems from the SMTP side when actually >trying out aka using these defaults (years ago), so it seems there >are quite liberal SMTP engines around. Everyone still accepts everything they've accepted over the past 30 years. I tried sending a message with Chinese text from Hotmail/Outlook and it arrived with a MIME GB2312 encoding. Yuck, but it worked. > |Not that I've ever seen but I haven't looked very hard. I think it's > |more common to stuff in a \r\n and continue. > >You surely do not change body content but by doing the full MIME >dance right. On outgoing mail, sure. On ill-formatted incoming mail where your options are limited, not necessarily. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Jul 17 15:17:14 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1AF3A2434 for ; Sat, 17 Jul 2021 15:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=Tw3jWtQh; dkim=pass (2048-bit key) header.d=taugh.com header.b=s2e/TEdx 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 AWWEgTf757tZ for ; Sat, 17 Jul 2021 15:17:05 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 847933A2432 for ; Sat, 17 Jul 2021 15:17:05 -0700 (PDT) Received: (qmail 45363 invoked from network); 17 Jul 2021 22:17:04 -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=b131.60f356e0.k2107; bh=dQJPnCtCtXckJT9ViKXX9cQDGvLwro/fGtZoFDaSfEc=; b=Tw3jWtQhW73MhmDmC5sLeIsSrMRak57CCIkwKRETss5J+QXSP3KPh1eXdSw23ZJ0lA2DXB+duCXSypst3cwrIDuoGn5MHws4KpbwAY2IaDDfki0uQHmi+KKVgu+5YrxJuOqtIMWSJvcWGTlu2WYnXH9tOJmG/fQm7OYLdDhVP9yF2O+wfIQ+dmDK/kIct5vGzrXYtreFVTXN6MgCITwWaAJyCaokjmrmJOyU1WhOhn+psBqmTTMmBMzIdw20tpdgQX3QwtK4H/Cu9ABnUbqT5B5bXBkeoPg3DspUzMWByqQ+ipHVfWcH5OdTM6HMusQ5VXWOZ5k7Z+UcYYczIEeBXg== 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=b131.60f356e0.k2107; bh=dQJPnCtCtXckJT9ViKXX9cQDGvLwro/fGtZoFDaSfEc=; b=s2e/TEdxd24DYsRTae8DEwia9VAL87xLUWW2PKNQxe4IvpD595Eo9s3xJ6aD4fQ0qX6GOufz3SO1ARZucHwoyCfl4kk0OrmWx5N0UBTp8pdiYjR1JF+tmhHTyt1we+67w7/Rxx2VsmjpiU01h7O40du+u8lsCCkLz9mHX162Y395mttDO/gVCFl2CGPRiq9tN60fJo9NBWaGHA4F7ppCKeOxXuasPcW8YQQwv632a0AsiJ09NJzE2pLr99HiXvPBvutOFjZXegc2+OIfob/teP+uBN39IsbzBurMakfyLUriW8ahCalbT6CPdHsfBM9EfnwrsK4E80KJVVILwoWSBg== 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; 17 Jul 2021 22:17:03 -0000 Received: by ary.qy (Postfix, from userid 501) id 0CBF924AABD7; Sat, 17 Jul 2021 18:17:02 -0400 (EDT) Date: 17 Jul 2021 18:17:02 -0400 Message-Id: <20210717221703.0CBF924AABD7@ary.qy> From: "John Levine" To: emailcore@ietf.org In-Reply-To: <20210717181358.sHnj6%steffen@sdaoden.eu> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] encodings, was Ticket #14: G.7.8. Review different size limits 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, 17 Jul 2021 22:17:13 -0000 It appears that Steffen Nurpmeso said: >Jeremy Harris wrote in > <7167164a-5c14-f6f2-4692-06da2506d158@wizmail.org>: > |On 17/07/2021 17:16, Steffen Nurpmeso wrote: > |> Your MUA created the according MIME headers, but whether it used > |> the 8BITMIME SMTP extension when passing this over to a MTA, that > |> is here the question. > | > |See https://cr.yp.to/smtp/8bitmime.html for one opinion, written quite > |a long time ago. Exim has been following that for the last nine years. > >I have to say i never quite understood the "an email message must >be human readable text" approach. djb wrote that in 1998 when MUAs that support MIME were a lot less ubiquitous than they are now, and I don't know anyone who objects to base64 encoding of PDFs and JPEGs. But 7bit MTAs were gone in 1998 and they're even more gone now so there is no point in encoding anything that is an 8 bit extended ASCII like UTF-8 or ISO-8859-x. R's, John From nobody Sat Jul 17 18:56:36 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114A63A2D4E for ; Sat, 17 Jul 2021 18:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ux6WUdwjR_05 for ; Sat, 17 Jul 2021 18:56:29 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 4B23F3A2D4D for ; Sat, 17 Jul 2021 18:56:29 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 894DCDBD7F; Sat, 17 Jul 2021 21:56:27 -0400 (EDT) Date: Sat, 17 Jul 2021 21:56:27 -0400 From: Viktor Dukhovni To: emailcore@ietf.org Message-ID: Reply-To: emailcore@ietf.org References: <20210717161657.XGPW_%steffen@sdaoden.eu> <20210717220940.E225824AAB35@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210717220940.E225824AAB35@ary.qy> Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits 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, 18 Jul 2021 01:56:34 -0000 On Sat, Jul 17, 2021 at 06:09:40PM -0400, John Levine wrote: > My MTA is qmail which has never recoded stuff on the fly. Neither > does Postfix or sendmail, at least not with their default settings. Actually, given an 8BITMIME message and a nexthop SMTP server that does not support 8BITMIME, Postfix will in fact (by default) do on the fly MIME quotable-printable encoding. http://www.postfix.org/postconf.5.html#disable_mime_output_conversion -- Viktor. From nobody Sat Jul 17 19:12:50 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68ADD3A2DEF for ; Sat, 17 Jul 2021 19:12:48 -0700 (PDT) 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 CloAGCFV89IK for ; Sat, 17 Jul 2021 19:12:43 -0700 (PDT) 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 982563A2DE9 for ; Sat, 17 Jul 2021 19:12:43 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1IPUCRTM800H9SM@mauve.mrochek.com> for emailcore@ietf.org; Sat, 17 Jul 2021 19:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1626574059; bh=ICF8GigbwZmW4+UydsGxOVqukVoCGUJeaSOtl5t7b/s=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=r4QVik2UOKNof2C5+JYAltD+UiiHDEicE8/7dCtxYJ3yMcYxcwXMZv51Aqk25k/z8 +QqmoC28cnoTsV27VOo/Fgc2sbSgMsdo16nBd/CEcIEyp0/ant2GC7948DLYXXyXgA njn+xPwXiqHtjfrsq+6cJdmxm1/isWU1+n+EDUUg= 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 <01S0F3SXH38G005PTU@mauve.mrochek.com>; Sat, 17 Jul 2021 19:07:36 -0700 (PDT) Cc: emailcore@ietf.org Message-id: <01S1IPUAUTZ6005PTU@mauve.mrochek.com> Date: Sat, 17 Jul 2021 19:06:34 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 17 Jul 2021 21:56:27 -0400" References: <20210717161657.XGPW_%steffen@sdaoden.eu> <20210717220940.E225824AAB35@ary.qy> To: Viktor Dukhovni Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits 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, 18 Jul 2021 02:12:48 -0000 > On Sat, Jul 17, 2021 at 06:09:40PM -0400, John Levine wrote: > > My MTA is qmail which has never recoded stuff on the fly. Neither > > does Postfix or sendmail, at least not with their default settings. > Actually, given an 8BITMIME message and a nexthop SMTP server that does > not support 8BITMIME, Postfix will in fact (by default) do on the fly > MIME quotable-printable encoding. > http://www.postfix.org/postconf.5.html#disable_mime_output_conversion Our MTA defaults to this as well. But it's trivial to switch off, and I have no way of knowing how many sites do so. Ned From nobody Sat Jul 17 19:42:58 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C6F3A08F8 for ; Sat, 17 Jul 2021 19:42:56 -0700 (PDT) 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 pgdCeDBecv6S for ; Sat, 17 Jul 2021 19:42:51 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F1D3A08EB for ; Sat, 17 Jul 2021 19:42:51 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m4wlT-000CtO-FF; Sat, 17 Jul 2021 22:42:47 -0400 Date: Sat, 17 Jul 2021 22:42:41 -0400 From: John C Klensin To: Ned Freed , Viktor Dukhovni cc: emailcore@ietf.org Message-ID: In-Reply-To: <01S1IPUAUTZ6005PTU@mauve.mrochek.com> References: <20210717161657.XGPW_%steffen@sdaoden.eu> <20210717220940.E225824AAB35@ary.qy> <01S1IPUAUTZ6005PTU@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits 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, 18 Jul 2021 02:42:56 -0000 --On Saturday, July 17, 2021 19:06 -0700 Ned Freed wrote: >> Actually, given an 8BITMIME message and a nexthop SMTP server >> that does not support 8BITMIME, Postfix will in fact (by >> default) do on the fly MIME quotable-printable encoding. > >> http://www.postfix.org/postconf.5.html#disable_mime_outpu >> t_conversion > > Our MTA defaults to this as well. But it's trivial to switch > off, and I have no way of knowing how many sites do so. Completely out of curiosity, as the amount of traffic that does not use Latin script increases (IMO, quoted-printable is far less useful when most of the characters are outside the ASCII repertoire), do either of you do the fairly minimal analysis needed to decide when Base64 would be more compact and no less useful? Or provide a switch s.t. if encoding is to be done, Base64 might be preferred by the configuration instead of quoted-printable? It seems like that might be worthwhile if one were carrying a significant amount of non-Latin-script, traffic. of course, none of this has anything to do with changes that might be needed in rfc5321bis, AFAICT. best, john From nobody Sat Jul 17 20:09:26 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C933A0AE4 for ; Sat, 17 Jul 2021 20:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=lfYBQUek; dkim=pass (2048-bit key) header.d=taugh.com header.b=ROvKFERw 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 sfWt7zBa2S6m for ; Sat, 17 Jul 2021 20:09:18 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30123A0AE2 for ; Sat, 17 Jul 2021 20:09:17 -0700 (PDT) Received: (qmail 5708 invoked from network); 18 Jul 2021 03:09:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=164a.60f39b5c.k2107; bh=OMGYeDeeQI6iwj/G55FwypNwSUAeThgowrnLR1cB8ss=; b=lfYBQUekNsL9O+80at9ZawVNSQUXJ8V9F7/50l4Yhpr7h8uMgDYwr25hEoiSdvr9XErPZSvoZV9taUj7AkhI2cj1qnhz62kpPxBOU24mjzormXUx2uVNpMz2HSK1jVrnW1uP/+nvlM3NBJL2PUJ8XdCTGgNU1SJ5/u8G5qkXGZkG6ktrYHo99OINV1h07pK3qn8S6suEdKkdT4jS1aN5BIy2Y8vHmJdbUke4DlKOUqs5xrS2FRzNIhKylQEzoLr3Fa7AHQmp513/+avCVRVYO2uikMJcFxEKsiT8TnB8/ncGlS1Qmr1ZzjfjVX3+GPxf8fwV1e7qLhlBc/NUyr6uzA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=164a.60f39b5c.k2107; bh=OMGYeDeeQI6iwj/G55FwypNwSUAeThgowrnLR1cB8ss=; b=ROvKFERwUlPhvYUGA5RZucil4BvTb3e091xtarvY2u72oCM5oOPuS2TH8+cVXQ+Sn9T0X692HJcZTAZkoqeYfEHn71vez2VwAnFjfuxm5Z5zL/Rk36HfNPvNkKh7dQ1NACorPSEn/ihvhRYCfFa6VxIIEsuiDRCKmRJDTvlWube23z+8VCaJr0w+bdcJGy+5xiR5z50ezgOTxGln9gjMQ/TurfgBt8plWZkO14bpjHm1Y4UsVTUYft20xwuTEquBwZZ/uO7uj6IuwhcAG3xwCjXBIBrHF3IVTvgEpmcZ0vJ/w9pMbVmZpJ6ihWPga1/wLZ+vFt63VlN1kV0pFtgpCA== 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 Jul 2021 03:09:16 -0000 Received: by ary.qy (Postfix, from userid 501) id C12DE24ACE83; Sat, 17 Jul 2021 23:09:14 -0400 (EDT) Date: 17 Jul 2021 23:09:14 -0400 Message-Id: <20210718030915.C12DE24ACE83@ary.qy> From: "John Levine" To: emailcore@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits 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, 18 Jul 2021 03:09:24 -0000 It appears that Viktor Dukhovni said: >On Sat, Jul 17, 2021 at 06:09:40PM -0400, John Levine wrote: > >> My MTA is qmail which has never recoded stuff on the fly. Neither >> does Postfix or sendmail, at least not with their default settings. > >Actually, given an 8BITMIME message and a nexthop SMTP server that does >not support 8BITMIME, Postfix will in fact (by default) do on the fly >MIME quotable-printable encoding. > > http://www.postfix.org/postconf.5.html#disable_mime_output_conversion I believe it, but I don't believe it's useful any more. IN 2019 I collected some stats for the UASG, going through TLD zone files, finding hosts with MX records, and sniffing the SMTP EHLO response for 8BITMIME and SMTPUTF8. While I didn't find all that many advertising SMTPUTF8, the number that advertised 8BITMIME rounded to 100% to several digits of precision. R's, John From nobody Sat Jul 17 21:18:49 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590B03A0919 for ; Sat, 17 Jul 2021 21:18:47 -0700 (PDT) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlyBy1qK5B-z for ; Sat, 17 Jul 2021 21:18:40 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 A8D213A0914 for ; Sat, 17 Jul 2021 21:18:40 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 024BEDC2D5; Sun, 18 Jul 2021 00:18:39 -0400 (EDT) Date: Sun, 18 Jul 2021 00:18:38 -0400 From: Viktor Dukhovni To: emailcore@ietf.org Message-ID: Reply-To: emailcore@ietf.org References: <20210717161657.XGPW_%steffen@sdaoden.eu> <20210717220940.E225824AAB35@ary.qy> <01S1IPUAUTZ6005PTU@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits 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, 18 Jul 2021 04:18:47 -0000 On Sat, Jul 17, 2021 at 10:42:41PM -0400, John C Klensin wrote: > > Our MTA defaults to this as well. But it's trivial to switch > > off, and I have no way of knowing how many sites do so. > > Completely out of curiosity, as the amount of traffic that does > not use Latin script increases (IMO, quoted-printable is far > less useful when most of the characters are outside the ASCII > repertoire), do either of you do the fairly minimal analysis > needed to decide when Base64 would be more compact and no less > useful? No, because message sizes are rarely dominated by the text parts. The large attachments that dominate message sizes are typically already Base64 encoded. Just using quoted-printable is not a problem for the 8bit text, even when not optimal. -- Viktor. From nobody Sat Jul 17 21:49:19 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D7E3A0B67 for ; Sat, 17 Jul 2021 21:49:17 -0700 (PDT) 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 5tYWz64tHPh1 for ; Sat, 17 Jul 2021 21:49:13 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E9143A0B65 for ; Sat, 17 Jul 2021 21:49:12 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m4yjn-000D67-Ea for emailcore@ietf.org; Sun, 18 Jul 2021 00:49:11 -0400 Date: Sun, 18 Jul 2021 00:49:06 -0400 From: John C Klensin To: emailcore@ietf.org Message-ID: <27DFEEF9F70700A8298F6DFA@PSB> In-Reply-To: References: <20210717161657.XGPW_%steffen@sdaoden.eu> <20210717220940.E225824AAB35@ary.qy> <01S1IPUAUTZ6005PTU@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits 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, 18 Jul 2021 04:49:17 -0000 --On Sunday, July 18, 2021 00:18 -0400 Viktor Dukhovni wrote: > On Sat, Jul 17, 2021 at 10:42:41PM -0400, John C Klensin wrote: > >> > Our MTA defaults to this as well. But it's trivial to switch >> > off, and I have no way of knowing how many sites do so. >> >> Completely out of curiosity, as the amount of traffic that >> does not use Latin script increases (IMO, quoted-printable is >> far less useful when most of the characters are outside the >> ASCII repertoire), do either of you do the fairly minimal >> analysis needed to decide when Base64 would be more compact >> and no less useful? > > No, because message sizes are rarely dominated by the text > parts. The large attachments that dominate message sizes are > typically already Base64 encoded. Just using quoted-printable > is not a problem for the 8bit text, even when not optimal. Makes sense, especially if there are non-text body parts. And John Levine's observation that 8BITMIME appears to be universally supported at this stage makes the whole issue moot although, perhaps just out of habit, I continue to worry about people who have much worse Internet connections than those participating in this discussion.. tnanks, john From nobody Sun Jul 18 16:38:25 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCF83A156A for ; Sun, 18 Jul 2021 16:38:22 -0700 (PDT) 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 KeZYE__tzJIn for ; Sun, 18 Jul 2021 16:38:17 -0700 (PDT) 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 7DD413A1562 for ; Sun, 18 Jul 2021 16:38:17 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1JYR6H26O00IPI7@mauve.mrochek.com> for emailcore@ietf.org; Sun, 18 Jul 2021 16:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1626651191; bh=4Bxov2Kaanket3J8LYJEsOZIbkrR8PkzFKH69oO2ALM=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=jiio4E5/tzC4IkBValB6fz0krIft1uooqvBaHqsAx8GkdL4g9bW7doJsOaWYa3hWe SXR7d1mf/kOm8EC0P14QSzkYnserK82s3UIwm0OtPX3VYOQx6ecKEvqShleVZhQQbW n+sXWCM15ULo3HtPs9tn+gytVDNDZafqeIsFtz8M= 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 <01S0F3SXH38G005PTU@mauve.mrochek.com>; Sun, 18 Jul 2021 16:33:08 -0700 (PDT) Cc: Ned Freed , Viktor Dukhovni , emailcore@ietf.org Message-id: <01S1JYR4AO6E005PTU@mauve.mrochek.com> Date: Sun, 18 Jul 2021 16:26:17 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 17 Jul 2021 22:42:41 -0400" References: <20210717161657.XGPW_%steffen@sdaoden.eu> <20210717220940.E225824AAB35@ary.qy> <01S1IPUAUTZ6005PTU@mauve.mrochek.com> To: John C Klensin Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits 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, 18 Jul 2021 23:38:23 -0000 > --On Saturday, July 17, 2021 19:06 -0700 Ned Freed > wrote: > >> Actually, given an 8BITMIME message and a nexthop SMTP server > >> that does not support 8BITMIME, Postfix will in fact (by > >> default) do on the fly MIME quotable-printable encoding. > > > >> http://www.postfix.org/postconf.5.html#disable_mime_outpu > >> t_conversion > > > > Our MTA defaults to this as well. But it's trivial to switch > > off, and I have no way of knowing how many sites do so. > Completely out of curiosity, as the amount of traffic that does > not use Latin script increases (IMO, quoted-printable is far > less useful when most of the characters are outside the ASCII > repertoire), do either of you do the fairly minimal analysis > needed to decide when Base64 would be more compact and no less > useful? In our case it depends on when the downgrade occurs. If we're doing it on the fly with an open SMTP connection we just go with a default; we don't do the analysis. If we're doing it earlier when we have the data we do the calculation and pick the better encoding. > Or provide a switch s.t. if encoding is to be done, > Base64 might be preferred by the configuration instead of > quoted-printable? It seems like that might be worthwhile if > one were carrying a significant amount of non-Latin-script, > traffic. I've had storing the analysis results on the to-do list literally for decades. But it's never been a sufficient issue that it's ever budged from its position near the bottom of the list. At this point it's unlikely it ever will. > of course, none of this has anything to do with changes that > might be needed in rfc5321bis, AFAICT. No, it doesn't. Ned From nobody Mon Jul 19 06:17:41 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F98D3A3372 for ; Mon, 19 Jul 2021 06:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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 L8HCU8Wu9D1U for ; Mon, 19 Jul 2021 06:17:33 -0700 (PDT) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA27D3A336E for ; Mon, 19 Jul 2021 06:17:33 -0700 (PDT) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id 8F21816056; Mon, 19 Jul 2021 15:17:25 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id E480F3B1; Mon, 19 Jul 2021 15:17:21 +0200 (CEST) Date: Mon, 19 Jul 2021 15:17:21 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: "John Levine" Message-ID: <20210719131721.8n6Cy%steffen@sdaoden.eu> In-Reply-To: <20210717221703.0CBF924AABD7@ary.qy> References: <20210717221703.0CBF924AABD7@ary.qy> Mail-Followup-To: "John Levine" User-Agent: s-nail v14.9.22-170-g4fc3932ea4 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] encodings, was Ticket #14: G.7.8. Review different size limits 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, 19 Jul 2021 13:17:41 -0000 John Levine wrote in <20210717221703.0CBF924AABD7@ary.qy>: |It appears that Steffen Nurpmeso said: |>Jeremy Harris wrote in |> <7167164a-5c14-f6f2-4692-06da2506d158@wizmail.org>: |>|On 17/07/2021 17:16, Steffen Nurpmeso wrote: |>|> Your MUA created the according MIME headers, but whether it used |>|> the 8BITMIME SMTP extension when passing this over to a MTA, that |>|> is here the question. |>| |>|See https://cr.yp.to/smtp/8bitmime.html for one opinion, written quite |>|a long time ago. Exim has been following that for the last nine years. |> |>I have to say i never quite understood the "an email message must |>be human readable text" approach. | |djb wrote that in 1998 when MUAs that support MIME were a lot less \ |ubiquitous |than they are now, and I don't know anyone who objects to base64 encoding |of PDFs and JPEGs. But 7bit MTAs were gone in 1998 and they're even more |gone now so there is no point in encoding anything that is an 8 bit \ |extended |ASCII like UTF-8 or ISO-8859-x. Well the paper may have inspired people to try out and use pure 8-bit paths for good twenty years ago. ..and of course except message generators have to because of the constraints (length limits, ^From_, invalid bytes) which do exist. And attachments / signatures and massive header pollution also make a raw internet message unpleasant to look at. So but for debugging maybe any desire or even praising of message/global seemed a bit artificial to me. --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 Wed Jul 21 11:41:16 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080953A2481; Wed, 21 Jul 2021 11:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 NtirbttJwEpX; Wed, 21 Jul 2021 11:41:08 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D01F3A2480; Wed, 21 Jul 2021 11:41:08 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9577854804E; Wed, 21 Jul 2021 20:41:01 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8E8C64E7AE7; Wed, 21 Jul 2021 20:41:01 +0200 (CEST) Date: Wed, 21 Jul 2021 20:41:01 +0200 From: 'Toerless Eckert' To: "STARK, BARBARA H" , emailcore@ietf.org Cc: "'glen@amsl.com'" , "'john-ietf@jck.com'" , tools-discuss@ietf.org Message-ID: <20210721184101.GR57276@faui48e.informatik.uni-erlangen.de> References: <20210716161105.GM24216@faui48e.informatik.uni-erlangen.de> <20210721165527.GP57276@faui48e.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Emailcore] [Tools-discuss] emails being truncated 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, 21 Jul 2021 18:41:14 -0000 Let me add emailcore On Wed, Jul 21, 2021 at 05:29:54PM +0000, STARK, BARBARA H wrote: > Hi Toerless, > I'm fairly sure the problem lies within the AT&T email systems, which are very convoluted (for security reasons). Thanks. > I don't think this is a problem that can be solve by IETF. Let me disagree! It is of course very frustrating to see such bugs in deployments for a spec from 1982 (RFC821/RFC5321). But if the problem does happen in a large enterprise as ATT, it likely happens elsewhere too, and after 43 years its clear it will not go away by itself: I suspect that after 43 years this is not even bad old code, but badly written "recent" SMTP code. SMTP sending looks from the outset so simple, many attempt to just re-implement it as few lines of code in their app and of course miss out on details. I know i did (statue of limitations for me ;-). emailcore is working on RFC5321bis. Hardening protocol state machineries against broken peers is IMHO extremely important, for sond principles such as "be lenient in what you accept and diligent in what you send", or providing good error diagnostics. This particular part of the SMTP state machinery is one which doesn't do either. In my memory almost the only. I do suspect ATTs broken sender would continue to send the message body after the ".", but the SMTP peer will just interpret that as broken SMTP. If that is the case, it should be possible to use an expanded SMTP state machinery with such an error recognition, even if just heuristic. And heuristic is good enough. It just takes few correctly triggeed error email notifications from the heuristic to get bugs like this fixed over the years, especially when the error email generated was easy to understand. I would be happy to suggest a heuristic if emailcore was willing to think about adding this as an item to fix for draft-ietf-emailcore-rfc5321bis. Worst case, you might need to send more emails with the problematic 76 characters to test the theory ;-) Cheers Toerless > I'm not particularly incented to try to fix the AT&T email issue because such things always involve going through a Tier 1 "help" desk that will want to invasively take control of my laptop to try to "fix" my problem (because all problems are on users' local machines, of course). They may break something that works, while doing this. I would then have to convince this person half a world a way to please escalate. It's not worth it to me, so I'm going to leave it here. > Barbara > > > Thanks, Barbara, but i can still not make out heds or tails > > (adding Glen and John) > > > > a) Was the bug now fixed ? Aka: when you repeat this, will it work now ? > > > > b) Whether fixed or not, which piece of software is the culprit ? > > > > AFAIK: > > > > The "old" behavior you refer to is the standard SMTP end-of-mail-data > > "." behavior of 1982 RFC821 section 3.1 that must go > > along with the transparency procedure of section 4.5.2. Current > > SMTP RFC5321 does not change this behavior. > > > > So, you can see why i am curious about any software having a bug > > about a procedure that has been used in gazillions (too many to count) > > of emails since 1982. > > > > The way you describe it sounds as if an Exchane server must be > > speaking SMTP, and it is folding long lines AFTER performing the > > SMTP transparency fixup, which is the wrong order. > > > > The only SMTP server/message-receiver side issue i can think of is > > confusion introduced when going beyond ASCII about what constitutes > > a ".". RFC5321 hints at this, but does not explain the breaking workflow. > > > > Cheers > > Toerless > > > > On Wed, Jul 21, 2021 at 03:33:35PM +0000, STARK, BARBARA H wrote: > > > Following up for those who may be curious... > > > I did email the support team with copies of the sent and received versions of > > emails. Glen correctly diagnosed the problem. > > > My email contained a line with exactly 76 characters, with last character ".", > > and followed by carriage return. Apparently, my Exchange server wrapped this > > line at 75 characters to put that "." all by itself on a line (with the carriage > > return). > > > The emails I received were being truncated directly before that ".". > > > This is a known bizarre issue. > > > > > https://urldefense.com/v3/__https://unix.stackexchange.com/questions/38156 > > /sendmail-procmail-exchange-truncating- > > mail__;!!BhdT!y4NKbaHihIlZDD_qjVaDSgFEXbVqZpRI00Bnmb63dTsUcMAY6vSUA > > QCQI5jkaA$ > > > > > > The answer there explains that > > > " - Exchange: on accepting a piece of mail for delivery, it appears to reformat > > a plain text message, encoding and wrapping its lines to 75 characters. > > > - sendmail: An old (but known) behaviour was being followed in that mail > > with a bare period on a line was interpreted as end-of-message and then > > delivered, effectively truncating the actual mail body." > > > > > > Well, I feel better now. > > > > > > Barbara > > > > > > > Do you have an example date / message id of such an email ? > > > > > > > > Does the dnssd email archive have the email untruncated but only group > > > > members > > > > report that it was truncated on their end, or is it also truncated on the > > > > list archive ? > > > > > > > > I had once email recently from an AD via draft-alias and WG expander, > > > > which arrived truncated on my side, but made it untruncated to > > > > the WG alias. > > > > > > > > Alas, i have not been able to track thast one down, even > > > > through it was a mayor issue for me (AD review of one of my drafts > > > > that i received truncated. Imagine how i felt when the AD told me: > > > > why did you stop fixing nits after 25% of my review... ;-)) > > > > > > > > Cheers > > > > Toerless > > > > > > > > On Fri, Jul 16, 2021 at 02:50:51PM +0000, STARK, BARBARA H wrote: > > > > > My emails (to dnssd@ietf.org) are suddenly being strangely truncated. I've > > > > never seen this before. Is anyone else experiencing this, or experienced this > > in > > > > the past? > > > > > Barbara > > > > > > > > > > ___________________________________________________________ > > > > > Tools-discuss mailing list - Tools-discuss@ietf.org > > > > > This list is for discussion, not for action requests or bug reports. > > > > > * Report datatracker and mailarchive bugs to: datatracker- > > project@ietf.org > > > > > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > > > > > * Report all other bugs or issues to: ietf-action@ietf.org > > > > > List info (including how to Unsubscribe): > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tools- > > > > discuss__;!!BhdT!y69XSrVx9_N0CqsoYvkdc4xaLGtXfH6kh- > > > > qvbmUhVIgNfw0yBw6GXgb2ZApVtA$ > > > > > > > > -- > > > > --- > > > > tte@cs.fau.de > > > > -- > > --- > > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Wed Jul 21 15:25:12 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398343A2CB1 for ; Wed, 21 Jul 2021 15:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 22uc93Mmy3XU for ; Wed, 21 Jul 2021 15:25:04 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360413A2CB8 for ; Wed, 21 Jul 2021 15:25:03 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 39E1F548042; Thu, 22 Jul 2021 00:24:57 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 346014E7AEB; Thu, 22 Jul 2021 00:24:57 +0200 (CEST) Date: Thu, 22 Jul 2021 00:24:57 +0200 From: Toerless Eckert To: John Levine Cc: emailcore@ietf.org, bs7652@att.com Message-ID: <20210721222457.GS57276@faui48e.informatik.uni-erlangen.de> References: <20210721184101.GR57276@faui48e.informatik.uni-erlangen.de> <20210721212122.055B224D27E8@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210721212122.055B224D27E8@ary.qy> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Emailcore] [Tools-discuss] emails being truncated 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, 21 Jul 2021 22:25:09 -0000 Removing tools-discuss. John, As far as i see it, your "its a known failure of the other side, go tell microsoft" approach has not succeeded to get rid of the issue. Hence i suggested to think about how SMTP spec could be improved by hardened it against misbehaving peers, specify how it can be more lenient and or provide diagnostics. IMHO, this particular case is a day 1 weak part of SMTP because there is no specification for detecting/diagnosing misbehavior. That is much better in most other error cases in SMTP: Getting truncated emails without any error diagnostics when only one SMTP peer is wrong is a weak protocol behavior. If you do not want to improve SMTP but only hold a grudge aainst Microsoft, consider the following: I have seen more than one occurrances of router CLI commands called "vendorX-bug-foo-workaround", and guess what - that public shaming did help for vendorX to fix those bugs a lot faster then it would have happened otherwise. Diagnostic emails would effectively result in very much the same type of public shaming. Much better than any of us going to Microsoft and complaining about it could do. Cheers Toerless P.S.: and yes, i also see hat none of this would likely help Barbara directly given how the next peer after what even calls itself outlook in its received line is yet another enterprise SMTP peer equally likely not to be bug fixed in an agile way. As i said, this is about what should be considered good for hardening the protocol. On Wed, Jul 21, 2021 at 05:21:21PM -0400, John Levine wrote: > It appears that \'Toerless Eckert\' said: > >> I don't think this is a problem that can be solve by IETF. > > > >Let me disagree! > > > >It is of course very frustrating to see such bugs in deployments > >for a spec from 1982 (RFC821/RFC5321). But if the problem does happen in > >a large enterprise as ATT, it likely happens elsewhere too, > >and after 43 years its clear it will not go away by itself: > > > >I suspect that after 43 years this is not even bad old code, but > >badly written "recent" SMTP code. SMTP sending looks from the outset so > >simple, many attempt to just re-implement it as few lines of > >code in their app and of course miss out on details. I know > >i did (statue of limitations for me ;-). > > An interesting guess, but clearly wrong, since it's still a well known bug > in Microsoft Exchange. > > How about if you pop up to Redmond, explain to Microsoft what they're doing > wrong, and let us know what they say? > > R's, > John -- --- tte@cs.fau.de From nobody Fri Jul 23 05:22:13 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9E83A1690 for ; Fri, 23 Jul 2021 05:22:11 -0700 (PDT) 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, NICE_REPLY_A=-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 aoCb9WVrtHW9 for ; Fri, 23 Jul 2021 05:22:07 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id D96083A168D for ; Fri, 23 Jul 2021 05:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1627042925; d=isode.com; s=june2016; i=@isode.com; bh=Bfmi9IwGt/udF3UtejmfEn7JEWbDubTGmmLg0ZcIQ6E=; 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=Cs53Z6bgdUsbveYTfEAYZkBtjbkipdBfJKIVvwlWQ83EK+xtwqFZlTuVMRmuDDecNkG4WA GVdKksiOI5taeSH7flQxKRBfFBrYD17G3LBZ0B2+i+sEY2tw2Ft1f39bvPh5zuHkxrjUAt TKfwk4qyd7upNsebr3LHFDfan4xpQeQ=; Received: from [192.168.1.222] (host5-81-100-7.range5-81.btcentralplus.com [5.81.100.7]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 23 Jul 2021 13:22:05 +0100 From: Alexey Melnikov To: emailcore@ietf.org References: Message-ID: <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.com> Date: Fri, 23 Jul 2021 13:21:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Ticket #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: Fri, 23 Jul 2021 12:22:12 -0000 Dear WG participants, I would like to get closure on this ticket, which was briefly discussed=20 on the mailing list and also during IETF 109 & 110. Below is a updated=20 strawman text: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Add to the IANA Considerations of rfc5321bis: IANA is requested to create a new subregistry for email header fields=20 that can be added to a message header section by a MSA/MTA/MDA. The new=20 subregistry would show whether a header field can be added by a "message=20 submission", =E2=80=9Crelay=E2=80=9D, =E2=80=9Cdelivery=E2=80=9D system or s= ome combination of them.=20 Headers appearing in this subregistry SHOULD also be registered in=20 >=20 (whether it is registered as a Permanent Message Header Field Name or as=20 a Provisional Message Header Field Name). The registration template has=20 the following fields: 1) Name of the header field name 2) Can be added by an MSA? 3) Can be added by an MTA? 4) Can be added by an MDA? 5) Optional reference field that points to one or more document=20 describing the header field. 6) Optional comment Registration policy for this new subregistry is =E2=80=9CExpert Review=E2=80= =9D.=20 Designated Experts should only check correctness of the information in=20 the registration template without passing any judgement on usuability of=20 a specific header field being registered. Updates to existing entries undergo the same process as registration of=20 new header fields. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Let me know your thoughts. Best Regards, Alexey From nobody Fri Jul 23 05:43:23 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C2D3A1953 for ; Fri, 23 Jul 2021 05:43:22 -0700 (PDT) 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, NICE_REPLY_A=-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 gLNRBTFOfYnb for ; Fri, 23 Jul 2021 05:43:17 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 2A29D3A1983 for ; Fri, 23 Jul 2021 05:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1627044196; d=isode.com; s=june2016; i=@isode.com; bh=G+Kp/zqWhdMoO4wRHmkADPnsMhY3zyrLP1myTH2EzdI=; 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=hO2x/HT6pLPlK54+uYDZ3Qt7CvSjKhXJor1fGVVWF9CME8ZrX7YgUQVOOCneECuhmoDaCw rLhynjTKh2+gKmoMPY9OwE7nmgOdgwK9DcRhJ6KYtqWnozhV6c5MrEMfKT8PBw8jWIa/xP fofavBRRgae2OuJE42O0qkDC+1aYRS8=; Received: from [192.168.1.222] (host5-81-100-7.range5-81.btcentralplus.com [5.81.100.7]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 23 Jul 2021 13:43:15 +0100 From: Alexey Melnikov To: emailcore@ietf.org References: <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.com> Message-ID: Date: Fri, 23 Jul 2021 13:43:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 In-Reply-To: <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Ticket #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: Fri, 23 Jul 2021 12:43:22 -0000 On 23/07/2021 13:21, Alexey Melnikov wrote: > Dear WG participants, > > I would like to get closure on this ticket, which was briefly=20 > discussed on the mailing list and also during IETF 109 & 110. Below is=20 > a updated strawman text: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Add to the IANA Considerations of rfc5321bis: > > IANA is requested to create a new subregistry for email header fields=20 > that can be added to a message header section by a MSA/MTA/MDA. The=20 > new subregistry would show whether a header field can be added by a=20 > "message submission", =E2=80=9Crelay=E2=80=9D, =E2=80=9Cdelivery=E2=80=9D = system or some combination=20 > of them. Headers appearing in this subregistry SHOULD also be=20 > registered in=20 > >= =20 > (whether it is registered as a Permanent Message Header Field Name or=20 > as a Provisional Message Header Field Name). The registration template=20 > has the following fields: > > 1) Name of the header field name > > 2) Can be added by an MSA? > > 3) Can be added by an MTA? > > 4) Can be added by an MDA? > > 5) Optional reference field that points to one or more document=20 > describing the header field. > > 6) Optional comment > > Registration policy for this new subregistry is =E2=80=9CExpert Review=E2= =80=9D.=20 > Designated Experts should only check correctness of the information in=20 > the registration template without passing any judgement on usuability=20 > of a specific header field being registered. > > Updates to existing entries undergo the same process as registration=20 > of new header fields. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Let me know your thoughts. Speaking as a participant: I am happy with this text in rfc5321bis or A/S. From nobody Fri Jul 23 06:01:29 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5303A1B84 for ; Fri, 23 Jul 2021 06:01:27 -0700 (PDT) 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMAIantOELHq for ; Fri, 23 Jul 2021 06:01:23 -0700 (PDT) Received: from dragonfly.birch.relay.mailchannels.net (dragonfly.birch.relay.mailchannels.net [23.83.209.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4002A3A1B83 for ; Fri, 23 Jul 2021 06:01:22 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 73FF25A2817; Fri, 23 Jul 2021 13:01:20 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (100-96-16-95.trex-nlb.outbound.svc.cluster.local [100.96.16.95]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 29B975A23B6; Fri, 23 Jul 2021 13:01:18 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.16.95 (trex/6.3.3); Fri, 23 Jul 2021 13:01:20 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Thread-Occur: 0d310b1d5a12a2d8_1627045279706_909363193 X-MC-Loop-Signature: 1627045279705:4112814556 X-MC-Ingress-Time: 1627045279705 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 3266E110F425; Fri, 23 Jul 2021 13:01:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1627045277; bh=SdfrvtsaFt7DOfsfvMJLrsGRjThYPryY1Pef9CroEyA=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=f0DwJq9fSGd9qwIJ8htFDOIHGyjBFwY4IUyvHkpBsrykXLerpkzMohQgYnHhu06wv 9TCS/yQQoAB1oww6VtvFDcAvijQV9aEFsiNGMNlCH3cPwSKFO7tM0edBLF2iYXqHgg FmxS5zTXD9wZ40ZQ81ZNW0smZ8a/uCQIycdhO7kTc/EoQYKRWXI0aSF9m0Ysw0b3Um OV3FS/1w5ZiQsha7pZpWQfobsnsr5DMDJCfqjTrTqkZSHm/8nwWFPY3QYW//kfq6Lb jVPDj6NsqGB45zasSMyoxXSH6wV14QWnzCnPqqVdpwf56Dd+E8icP5DG76Jum7WM4G cOKKoyPqqgwfA== Reply-To: dcrocker@bbiw.net To: Alexey Melnikov , emailcore@ietf.org References: <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Fri, 23 Jul 2021 06:01:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Fri, 23 Jul 2021 13:01:28 -0000 On 7/23/2021 5:21 AM, Alexey Melnikov wrote: > 2) Can be added by an MSA? > > 3) Can be added by an MTA? > > 4) Can be added by an MDA? Shouldn't the list of choices include MUA (ie, either the author or possibly even the recipient)? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jul 23 06:43:38 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80133A074D for ; Fri, 23 Jul 2021 06:43:31 -0700 (PDT) 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, NICE_REPLY_A=-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 CQ2qzUq0tl4b for ; Fri, 23 Jul 2021 06:43:27 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 9599F3A0597 for ; Fri, 23 Jul 2021 06:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1627047806; d=isode.com; s=june2016; i=@isode.com; bh=UnwRztBMEH3lX8rg5JRX59BP+Db0VgHL/+tssMDq1ps=; 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=MDmPYJlnlpj80ab94IZ8RfHDLuUY07s41oojRmUTSKyPEB7gFrl2/yNIkUkqEsZZ8l86wR eusYWaL53OlFZW28oEL83TGsQU8KVLJ42yL20GilU3j4WkypZhN8hfNs88XGRUEoQLd1SZ iELGPhuPOHQUNB2Izo7Nj36z/PS5Z6M=; Received: from [192.168.1.222] (host5-81-100-7.range5-81.btcentralplus.com [5.81.100.7]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 23 Jul 2021 14:43:26 +0100 To: dcrocker@bbiw.net, emailcore@ietf.org References: <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.com> From: Alexey Melnikov Message-ID: <1e275647-3a00-8a9f-6b11-a087ab9ec7bb@isode.com> Date: Fri, 23 Jul 2021 14:43:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB 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: Fri, 23 Jul 2021 13:43:37 -0000 Hi Dave, On 23/07/2021 14:01, Dave Crocker wrote: > On 7/23/2021 5:21 AM, Alexey Melnikov wrote: >> 2) Can be added by an MSA? >> >> 3) Can be added by an MTA? >> >> 4) Can be added by an MDA? > > Shouldn't the list of choices include MUA (ie, either the author or > possibly even the recipient)? Yes. Best Regards, Alexey From nobody Fri Jul 23 07:30:13 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3813A0B6C for ; Fri, 23 Jul 2021 07:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 j3K8xnyb_CIX for ; Fri, 23 Jul 2021 07:29:57 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id B0FF33A0B37 for ; Fri, 23 Jul 2021 07:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1627050596; d=isode.com; s=june2016; i=@isode.com; bh=tpkx+eHOloxdfCS66HFZg/ypbONjKCsIhuM14TKe3i8=; 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=LqEUebBV1PO5fi00k4K4fSG7hDPilWC7x5lGMrea71su4/xR7inZqnNQwBwtI2fBolXYwG T6S5ydUIcNSDdjUOcq7V6cm1yDXgyxyEw+Vf6/+fOPaM2Z+NmcwUR8j7J0FXGBs5treSJo P0Gx4WWYGlpUuH4wXxZByuVeiHHRkfc=; Received: from [192.168.1.222] (host5-81-100-7.range5-81.btcentralplus.com [5.81.100.7]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 23 Jul 2021 15:29:56 +0100 To: emailcore@ietf.org From: Alexey Melnikov Message-ID: <39fea9e5-907e-2dfd-ba88-5e0e21e9685f@isode.com> Date: Fri, 23 Jul 2021 15:29:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.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 #7: Trace header field related text in rfc5321bis X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 14:30:08 -0000 Hi all, I scanned the draft and hopefully captured all cases where trace header=20 fields/Received are mentioned. Below is a strawman of what might be a=20 good idea to update: Add a new section that introduces Trace header fields. Possibly change=20 4.4 to be that section and move definition of the Received header field=20 into a subsection of 4.4 (e.g. 4.4.1). I found the following text in RFC=20 822, which seems like a good definition: =C2=A0=C2=A0=C2=A0=C2=A0 Trace information is used to provide an audit trai= l of=C2=A0 mes- =C2=A0=C2=A0=C2=A0=C2=A0 sage=C2=A0 handling.=C2=A0=C2=A0 In=C2=A0 addition= ,=C2=A0 it indicates a route back to the =C2=A0=C2=A0=C2=A0=C2=A0 sender of the message. 2.3.10.=C2=A0 Originator, Delivery, Relay, and Gateway Systems =C2=A0=C2=A0 A "relay" SMTP =C2=A0=C2=A0 system (usually referred to just as a "relay") receives mail f= rom an =C2=A0=C2=A0 SMTP client and transmits it, without modification to the mess= age =C2=A0=C2=A0 data other than adding trace information, to another SMTP serv= er for =C2=A0=C2=A0 further relaying or for delivery. Add a reference to the new 4.4. after "trace information". 3.6.3.=C2=A0 Message Submission Servers as Relays =C2=A0=C2=A0 As discussed in Section 6.4, a relay SMTP has no need to inspe= ct or =C2=A0=C2=A0 act upon the header section or body of the message data and MU= ST NOT =C2=A0=C2=A0 do so except to add its own "Received:" header field (Section = 4.4) Add "and possibly other trace header fields" at the end of the above line. =C2=A0=C2=A0 and, optionally, to attempt to detect looping in the mail syst= em (see =C2=A0=C2=A0 Section 6.3).=C2=A0 Of course, this prohibition also applies t= o any =C2=A0=C2=A0 modifications of these header fields or text (see also Section= 7.9). 7.6.=C2=A0 Information Disclosure in Trace Fields =C2=A0=C2=A0 In some circumstances, such as when mail originates from withi= n a LAN =C2=A0=C2=A0 whose hosts are not directly on the public Internet, trace =C2=A0=C2=A0 ("Received") header fields produced in conformance with this Change '("Received")' to '(e.g. "Received")' =C2=A0=C2=A0 specification may disclose host names and similar information = that =C2=A0=C2=A0 would not normally be available. Thoughts? Best Regards, Alexey From nobody Fri Jul 23 07:38:39 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F6D3A0C54 for ; Fri, 23 Jul 2021 07:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 1mApbiVFU8qB for ; Fri, 23 Jul 2021 07:38:32 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3943A0C51 for ; Fri, 23 Jul 2021 07:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1627051111; d=isode.com; s=june2016; i=@isode.com; bh=qcmGq3pDklJLvIY41NS/AisYexqRBC62vLOmSYHfnag=; 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=Um6jcGU5yfQt+3VZy7Jjwj6BSAWM5/WIj+NwRz03+MkN1racnevvKGwJolhgEzOvTLJ0DY GAg7zxb3soehCgsWbCi6mvtfU6nlJMHL0XwdYTKixaa75h3AtWsSIdksl3CKIvktpr3AiS wYBSQmai0IvbjdtxVRpGJquvo3MUdTM=; Received: from [192.168.1.222] (host5-81-100-7.range5-81.btcentralplus.com [5.81.100.7]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 23 Jul 2021 15:38:31 +0100 To: emailcore@ietf.org From: Alexey Melnikov Message-ID: <33e584b5-23dd-a353-edd8-646675bcbee2@isode.com> Date: Fri, 23 Jul 2021 15:38:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 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] Ticket #50: Use of top level domains in SMTP X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 14:38:37 -0000 Dear WG participants, I believe this was discussed on the mailing list, but after doing a quick mailing list search I couldn't find the discussion thread. But let's have a quick discussion of this. I believe there was rough agreement in the past that use of top level domains is going to cause interop problems, as depending on context they might not be distinguishable from local hostnames. If people agree, I think the Applicability Statement draft should talk briefly about this. Best Regards, Alexey From nobody Fri Jul 23 07:41:59 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6233A0C95 for ; Fri, 23 Jul 2021 07:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=digilicious.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 aIRzajzYzNwX for ; Fri, 23 Jul 2021 07:41:52 -0700 (PDT) Received: from digilicious.com (digilicious.com [108.83.36.113]) (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 A36533A0C94 for ; Fri, 23 Jul 2021 07:41:52 -0700 (PDT) Received: from digilicious.com (digilicious.com [108.83.36.113]) by digilicious.com (Postfix) with ESMTPSA id 741BF260209; Fri, 23 Jul 2021 07:41:51 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 digilicious.com 741BF260209 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digilicious.com; s=default; t=1627051311; bh=gLZk/8YS+tYvBpNGo4+y8CfsZIijCiWtLXiesBEi72Y=; h=Subject:To:References:From:Date:In-Reply-To:From; b=DHYoJtzu+PYfJtIy6f9VTf5wdGii/9x+kXP3GW91ByQ4ervxwjMStu2Gc3V2Zjmar hx06SG97AY7iG1AtxENI2QxZMMbI4XDZb1DUywEzdieUuBgisS1+Rj4JbSzVKdmuFK FMati2TJuUWUmMpYM/hGqBhclcrTPAQEnbsJZhKQ= To: John Levine , emailcore@ietf.org References: <20210715201638.983BD238781A@ary.qy> From: Gene Hightower Autocrypt: addr=gene@digilicious.com; prefer-encrypt=mutual; keydata= mQINBFcNhXQBEACVVW/XRrbw5OYHFUutwUPTRODmGwowpFP0oJayfLiyyXUbOrW7GzFQBy9d l0hIqu4+fOE91C0iJ+o9f3VJ5O8LqsubX2kVi/G0AAzYpLXJhviJbtVXJ0vleBX6Ool37BVN qvX67zlWENc9G1WuI4kAtaRfLAqvcMKVC4Sgnrcvt8dvOZDtYf+TB5+Hjs9k6Q6bHXBxhdj0 iuT97wyIm2Vxl2VTPsiP1g5iQBXIoyJ0+hHPtEG8clUdYrfhkYiF3shoEuhhgkEy33Yh8C28 2SztTmKX/o6+kAKoPZJPUVZK9Um+j1dctlIIv2ajNThM6PLQVvSCD6/UYAv6FuOoIh933b4p oMPL2HLQE3ypsvuk4F0TyLEg08EWtrhS34DHi+p223qyyKNP1p/eUrGRv4tpjUdKPQavSTL5 M9/Aah4Sthwf54OY4uG307l7ni8d0Oho6NnWgr1/qHrCKFXWfHCoCgRsCfFVZ3vHZ/faLe8O tD7JoC04E6DqjbGNoBCawdrdvOm6+khrRP/FcF2j4oW1/+ozdZqif9Rn9ysD9Ikp4qd8LgN1 oQCgIXkDbxS0+amTFNJHG4tcZrcyp3CCiNyrpNTIHLOUkXOjVA/EBAnEptipdIYWXzRLQzdD VmHYv4V08vKVZbaDdcMvDPJFHwsx4hFP40wCXgdRZB9r5X1ZdQARAQABtCVHZW5lIEhpZ2h0 b3dlciA8Z2VuZUBkaWdpbGljaW91cy5jb20+iQI3BBMBCAAhBQJXDYV0AhsDBQsJCAcCBhUI CQoLAgQWAgMBAh4BAheAAAoJEPDFbaYR6kj1MJsP+gP6g7gjGrtupc83/JjyxPeY0Fsc8lzB N5dUIJ+ybDs4hz7oq2JRIFQxgZkFH9H1a7xlB1q+4PpfvciBxHyRMgvuGU54LUYFfZ72+nsI mzwuYJIIwrZWPiqPzo1YqiziQIiFIl7cfB3YacqJC2rkCTnJxptKIGfLUcDDBRah//9nnkit vuIuOtg/4lB7LqR5bkyg3+Lwk4D7/8Nfd0hLjC7uI+8Yujrdp8neGFfO6+EkugpkHvaFjjT5 ODGAPjh+vB8/u+Krp7M3gNkMQJ4eEof0stexXV8tIPZEsupoaSTgja30oTIoctdblYef5IZB H2uohCmgSNL1EvffbHJ93dkVe7wQk3zCGD1sUVKYLy4ZwO+TpX08stTRboLBbPFBCYT8bCTi +7aewQS+JaJw1rH41La1SPjvnLHOHgF5Q+QHj/VK2teqA1ScbdaHq6ouKO6CP/TbvDE8g2ZI OEfdwUYFC1bqefAj1Cl4g5DYeYze9Yv3pq+fEry901c/A7uQ2Zd5U5QnmzkFDD4EBKLidvtz sJ45EPdBQODZl0QlOgs7p7VEH/pVgVSuOOZ2wksOlEBp0fcy2hyqMBXUP0k2gWBUF4kkpZ8/ UOaIcTavpa7Ahxzd61gr2GaKVpc8mOFd9xYnD3oylLiVJFcQBkznuFYzh/KdPEOXmD911uYj I5gCuQINBFcNhXQBEADxCwKHWaebWLf1szMs77+BI6QOUn3/vR8eQ0omuYI7Uk1psg6siZIe HSm9bQxV3M4MMUayipCmKbRDmNmsFjkjIy+xOlDJZM3xQZ4iLrBtPTyJyS8nhwqPZ9lLxIWD CMfnpgiRM34NjIm7fcVxhiVNXL51+TqjhyzPrZCdAeJBq8htyluPMJ4bhZ1VA1wdR4xQIWih MIykyoixUOdXgypdU4m+9atpeSGJYLQkbHHT3U2XEChMHRfh9M47ylJpFlGJ/EJWmk+SWLg8 7YxeMYx8dA1JZGtkOB3WYkdgnGXwMIVphZed3+pAVbRjBJ9uAjnjmFLUfBJAX7s8cB5RJB+J uF+aA3hs3YAzHF6l15HKyaC4fWYDkN1Xp2x5+9/eREA9TtkvKexUFa2cEfz2wQqyXJY0Kl/U 3QKCy0P/8EcqqLFxiHl38/Xh0QdQdo2NAVobLvAVww2ExfHDRoKGM2oCcv29ytJgFXtvxry2 nZtZcBSENypFr4TZCxlpL6gQ82Cyo7kqmirS5UBvCPZZ8IzYaxwhICQgXbN64Gp+BpdJvcRh p9WfvsNHAR2RV8TTRGFLlr7BmmUyaAKpCXq4yvJ17U88jnqA4f+YOcAx9jl3cKvRgmR6b8iC tug2eWRIRoEqpvTPfIX+u5mQ7sfGeGEy8+5YKIVSFQFeNblVRAqA7wARAQABiQIfBBgBCAAJ BQJXDYV0AhsMAAoJEPDFbaYR6kj1MJ8P/2Ut2hxqJ/3DqA+QqhhT0uW42aWYzS6XtWwzLElE /vUOqUPcZqMp5rBmNFMP5NbGShqHNGpVzxbEHIg1W5cNu16q3JzT/eXJdx/u7BHseTFuK1YJ brmC6Xm7Y/pCHFqxa/hFbLaHUBXQ7UTckUTh/IwSD7BvHSsqQhZPGIK4SoXAihBwbZqSLAYR kfvsTV13qeGGtH3jhFAvi9ToOd7lD0xnK26pz+IrmWWTSuTlsVUVykItVgOaNEOo1vmvwTmq Fq/FmOFmkkj+8hGyABdht8k8ZSC6n5vvW4HWdb/scRZZohxJIS94hXrXrNWBlJZmn+uKA/Aq B7quLkpUz/Nc5ZyrATs6nIgUEUYBLTnGmhMKA9bfuoV09ex+nrMJPx/bMzduMqh8ED9YIlGb t3abPgZEtL2E9BGRHz+xbdU9awc9OboHPeNxNzrODdUHasFiF+ozCu1Y4kM2oUE+HdWSYSOt YSRH4tlmSkF09DnCQhjDDsDfOvxp2c2fB5er5eUpwOhSCFbHu1U/h1/iu9g0MxRl0dk0LeNT GLOuUkPnX87/dgSTjjwahgdTrWwkxY/MRTRDQrTd2OmbHAG4YyrU9P9LiJafapYMpZMEfRwU XXHpQ4wEHDQRQAhQFXtRj/GoQu1Wx6bo03B8VbaabrA9R23ev22XXN7WAMqE9Ea2JSOV Message-ID: Date: Fri, 23 Jul 2021 07:41:50 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20210715201638.983BD238781A@ary.qy> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NqWPaQzu5H9yg8u7RYAGZFr9v5NzAQ2he" Archived-At: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 14:41:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NqWPaQzu5H9yg8u7RYAGZFr9v5NzAQ2he Content-Type: multipart/mixed; boundary="eP45FRqO6NVyOktqrDwDTjI1LdTdYFp9c"; protected-headers="v1" From: Gene Hightower To: John Levine , emailcore@ietf.org Message-ID: Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits References: <20210715201638.983BD238781A@ary.qy> In-Reply-To: <20210715201638.983BD238781A@ary.qy> --eP45FRqO6NVyOktqrDwDTjI1LdTdYFp9c Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 15/07/2021 13:16, John Levine wrote: > PS: I don't feel strongly about lifting the 1000 octet limit but I woul= d like > to understand how widely it's enforced by mail receivers. I routinely get messages from ups.com that contain an HTML part all in one line. With "Content-Type: text/html; charset=3DUTF-8" and no Content-Transfer-Encoding. Tens of thousands of bytes, which are UTF-8 code units. My MTA spits a warning to the logs when a message comes in (via DATA, not BDAT) containing a line >1000 bytes. It's not very common, but I do see it. Most email I see nowadays is Quoted-Printable. --eP45FRqO6NVyOktqrDwDTjI1LdTdYFp9c-- --NqWPaQzu5H9yg8u7RYAGZFr9v5NzAQ2he Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEWOWxKLajOgqXlD8w8MVtphHqSPUFAmD61S4ACgkQ8MVtphHq SPVxPQ/+IJrBzUD0GXCzZ9fVR0jU4n5jlxBP4om69ATLtuQ5fQ1ZpxoCzA5UJDLx LRwPGrPBEuLO8r8jei0pj0TCu19wi4dGgmV78qPi9tqBN1+Q08laZXf2kmyyoTMk MOYnIMPS4IPnd1wfeGWb534SGfB3povZElHtIdQupZQVZsHhIinSHazI37BZPFb3 YNKZUyX3JBq7S7ivL+0qfXXE7gnc6oVDUBbOm6JqUaSnSAyVEcm81zo9fQoe/QsH UL0uBiGxfNxuym7Xr10vDBmpPAT5+zcJxfJIrjJriwh9nLBXFt5c7kAVpzV++f1E qddP6OBNlhMEm7xPUV4uDF41o/HNLq1PYo04optNCG+lN0zNGQgfqI5Xk9qirQmG 8KFkyx3s/cCAO6i1exAYU6413obv7rVi4CtC/PixeriJ9JCkGoEwBLiELU+bE4Y1 D8oiYsxMv5WH41vQY2a24In67UQpfXg1f3YHY43ZxR2SZ4Z0dCsRII7OJUfSqxVf YWtXsb8JPMjhsSOpy5pBqZ/gnWdnjBEotBXbtPhLD9Y7rdjBQG+1m6S8YSbzRXpC a/Ws3u4Lc6/GxlE1unskKMo4ZlDedehDEUxoeJtYi0Ofp/+vgRpTc5nP5LlGm6dn TuO5Il3sPQUQnVcs3hw8/XZgmRAO0kkkebioZS95SIPSdU/cGjI= =8OFx -----END PGP SIGNATURE----- --NqWPaQzu5H9yg8u7RYAGZFr9v5NzAQ2he-- From nobody Fri Jul 23 07:53:21 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7773A0DC1 for ; Fri, 23 Jul 2021 07:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 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_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RV3UjLldjpi for ; Fri, 23 Jul 2021 07:53:08 -0700 (PDT) Received: from antelope.elm.relay.mailchannels.net (antelope.elm.relay.mailchannels.net [23.83.212.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53F93A0DB0 for ; Fri, 23 Jul 2021 07:53:07 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 6B2446429F0; Fri, 23 Jul 2021 14:53:04 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (100-101-162-69.trex.outbound.svc.cluster.local [100.101.162.69]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 4E2D4642A15; Fri, 23 Jul 2021 14:53:03 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (35.45.192.35.bc.googleusercontent.com [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.101.162.69 (trex/6.3.3); Fri, 23 Jul 2021 14:53:04 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Tart-Illustrious: 2949e9f107b0b555_1627051984171_3849315364 X-MC-Loop-Signature: 1627051984171:1928135771 X-MC-Ingress-Time: 1627051984171 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 7475530B5560; Fri, 23 Jul 2021 14:53:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1627051982; bh=cjAdtRIT+yTJVfd3cV4C9uObsihLC8k/PA1wxJyGjOM=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=bYKiEMP1oZT79MoEPOVXa2/4ZjwEh26ZyY97UvZxI/YqLWuOjdEWdZvnWUwdMTt2U R7vK/qr57wkSmhEHcvOtuvzxzWABEpZxnn4Sm1WTVwVnun293Ft7F8rqgC5USLTGC/ moVpektJR9rq5usvqIGR9l9fGIv5SLI5BrvpUWB/f1PbZzDqjQJi2JUaJM8aPHJF2e eyBfTEmIz0MrVF2ojTNBKNWuCWJQRJ1+oow5ianbVbqx7txnfIndI+ZNmcypLRyx/r RD7h64bSq4DWDtbkUSU29md/ewyAV0kBZZC1Cq8NG3ndykmxZnoEzmUN6ETi8T69qh AO/3Xf15Nq5CQ== Reply-To: dcrocker@bbiw.net To: Alexey Melnikov , emailcore@ietf.org References: <33e584b5-23dd-a353-edd8-646675bcbee2@isode.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Fri, 23 Jul 2021 07:52:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <33e584b5-23dd-a353-edd8-646675bcbee2@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #50: Use of top level domains in SMTP X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 14:53:19 -0000 On 7/23/2021 7:38 AM, Alexey Melnikov wrote: > I believe there was rough agreement in the past that use of top level > domains is going to cause interop problems, as depending on context they > might not be distinguishable from local hostnames. If people agree, I > think the Applicability Statement draft should talk briefly about this. Yes, as long as the language makes clear that the conflict is between an enhanced, standardized bit of functionality, with local, non-standardized functionality. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jul 23 09:21:40 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74093A09F6 for ; Fri, 23 Jul 2021 09:21:30 -0700 (PDT) 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 uASRIsZkkDUb for ; Fri, 23 Jul 2021 09:21:26 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FCA33A09F2 for ; Fri, 23 Jul 2021 09:21:26 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m6xvO-000Eqo-2q; Fri, 23 Jul 2021 12:21:22 -0400 Date: Fri, 23 Jul 2021 12:21:16 -0400 From: John C Klensin To: dcrocker@bbiw.net, Alexey Melnikov , emailcore@ietf.org Message-ID: <6DE94CD481CE96AAD9FFED7B@PSB> In-Reply-To: References: <33e584b5-23dd-a353-edd8-646675bcbee2@isode.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] Ticket #50: Use of top level domains in SMTP X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 16:21:39 -0000 --On Friday, July 23, 2021 07:52 -0700 Dave Crocker wrote: > On 7/23/2021 7:38 AM, Alexey Melnikov wrote: >> I believe there was rough agreement in the past that use of >> top level domains is going to cause interop problems, as >> depending on context they might not be distinguishable from >> local hostnames. If people agree, I think the Applicability >> Statement draft should talk briefly about this. > Yes, as long as the language makes clear that the conflict is > between an enhanced, standardized bit of functionality, with > local, non-standardized functionality. Dave, I think I agree, but I'm not certain what you have in mind. Could you, or someone else, elaborate a bit? On a possibly-related topic, the DNSOP WG is considering proposals to officially allow private-use strings as top level domains. If those proposals are approved, is it necessary to add language to either the discussion of FQDNs in RFC5321bis (noting that ticket #41 has been closed) or to add language to the A/S to be clear that MTAs are expected to not let such things escape onto the public Internet, just as they are expected to prevent such addresses as example@local and user@example.local from escaping. best, john From nobody Fri Jul 23 09:35:49 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E4D3A0ACB for ; Fri, 23 Jul 2021 09:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeWzkNE0wtnq for ; Fri, 23 Jul 2021 09:35:40 -0700 (PDT) Received: from black.elm.relay.mailchannels.net (black.elm.relay.mailchannels.net [23.83.212.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9F53A0AD8 for ; Fri, 23 Jul 2021 09:35:34 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 84680123815; Fri, 23 Jul 2021 16:35:32 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (100-96-11-33.trex.outbound.svc.cluster.local [100.96.11.33]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 10951123804; Fri, 23 Jul 2021 16:35:31 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.11.33 (trex/6.3.3); Fri, 23 Jul 2021 16:35:32 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Wide-Eyed-Wide-Eyed: 25380ed079fdee22_1627058131755_4027949719 X-MC-Loop-Signature: 1627058131754:286386281 X-MC-Ingress-Time: 1627058131754 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 1361910E99F4; Fri, 23 Jul 2021 16:35:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1627058130; bh=MxWJ/4R3t6ydhXNSUjhXVzZ+eOaUOhKZF1PSXplE1tQ=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=enmU3tOSrofd1SCzu5iJpLapYs+my2coSvlEL6vcwz45jV3USlZcNc6Yb7gLgjPjb YpxU0au12QFjX08/V032UJnJr0mdSAujOCMhGu0GSHOii/myTYOFFvexpBKbhWTyXS 32PtwR4W6nPqSOdVV4ICibt0WmN+0k1zCW9QYA2KTz13+Z2lIj/TNFJL9Zkh3UlNiA dBIOjhGHG73RJepiFbjV34AbolWH9knTluU3iCf256SO7O981WA4TFEH1WWbRdk7TF X+jQs5A8EPyEKEaorst9YdZWNSFnRRSPuZwQpmCUk9OdyEZdpUKHMPxDh18GGTsk3A OJFShA7i+F1JQ== Reply-To: dcrocker@bbiw.net To: John C Klensin , dcrocker@bbiw.net, Alexey Melnikov , emailcore@ietf.org References: <33e584b5-23dd-a353-edd8-646675bcbee2@isode.com> <6DE94CD481CE96AAD9FFED7B@PSB> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <11162acc-85fe-0863-fb47-8c6365edf8e4@dcrocker.net> Date: Fri, 23 Jul 2021 09:35:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <6DE94CD481CE96AAD9FFED7B@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #50: Use of top level domains in SMTP X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 16:35:48 -0000 On 7/23/2021 9:21 AM, John C Klensin wrote: > > > --On Friday, July 23, 2021 07:52 -0700 Dave Crocker > wrote: > >> On 7/23/2021 7:38 AM, Alexey Melnikov wrote: >>> I believe there was rough agreement in the past that use of >>> top level domains is going to cause interop problems, as >>> depending on context they might not be distinguishable from >>> local hostnames. If people agree, I think the Applicability >>> Statement draft should talk briefly about this. > >> Yes, as long as the language makes clear that the conflict is >> between an enhanced, standardized bit of functionality, with >> local, non-standardized functionality. > > Dave, > > I think I agree, but I'm not certain what you have in mind. > Could you, or someone else, elaborate a bit? Support for TLDs as FQDNs is standardized, albeit new. Hence it can -- and should -- be within formal email standards specifications. Support for local -- ie, private -- names is fully and completely outside formal email standards specifications. There's nothing wrong with an operations-related specification noting the fact of private behaviors and possibly even offering commentary about their use. There's quite a lot wrong with having a formal specification incorporate support for private behaviors, because it them makes those private behaviors part of the public, official specification. So I'd guess it's fine to have language about this issue in the Applicability Statement, as long as it note that compliance to the standard requires giving precedence to legitimate, public domain names, which now includes TLDs. > > On a possibly-related topic, the DNSOP WG is considering > proposals to officially allow private-use strings as top level > domains. So the wg chartered for DNS operations issues is going to modify the DNS protocol? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jul 23 10:56:12 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12793A0EB6 for ; Fri, 23 Jul 2021 10:56:09 -0700 (PDT) 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 SO8GuUjom-oF for ; Fri, 23 Jul 2021 10:56:04 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240E63A0EB5 for ; Fri, 23 Jul 2021 10:56:03 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m6zOz-000F5k-8T; Fri, 23 Jul 2021 13:56:01 -0400 Date: Fri, 23 Jul 2021 13:55:55 -0400 From: John C Klensin To: dcrocker@bbiw.net, Alexey Melnikov , emailcore@ietf.org Message-ID: <4CBA816B04479B744DCDEA6E@PSB> In-Reply-To: <11162acc-85fe-0863-fb47-8c6365edf8e4@dcrocker.net> References: <33e584b5-23dd-a353-edd8-646675bcbee2@isode.com> <6DE94CD481CE96AAD9FFED7B@PSB> <11162acc-85fe-0863-fb47-8c6365edf8e4@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #50: Use of top level domains in SMTP X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 17:56:10 -0000 --On Friday, July 23, 2021 09:35 -0700 Dave Crocker wrote: > On 7/23/2021 9:21 AM, John C Klensin wrote: >> >> >> --On Friday, July 23, 2021 07:52 -0700 Dave Crocker >> wrote: >> >>> On 7/23/2021 7:38 AM, Alexey Melnikov wrote: >>>> I believe there was rough agreement in the past that use of >>>> top level domains is going to cause interop problems, as >>>> depending on context they might not be distinguishable from >>>> local hostnames. If people agree, I think the Applicability >>>> Statement draft should talk briefly about this. >> >>> Yes, as long as the language makes clear that the conflict is >>> between an enhanced, standardized bit of functionality, with >>> local, non-standardized functionality. >> >> Dave, >> >> I think I agree, but I'm not certain what you have in mind. >> Could you, or someone else, elaborate a bit? > > Support for TLDs as FQDNs is standardized, albeit new. Hence > it can -- and should -- be within formal email standards > specifications. > > Support for local -- ie, private -- names is fully and > completely outside formal email standards specifications. > > There's nothing wrong with an operations-related specification > noting the fact of private behaviors and possibly even > offering commentary about their use. > > There's quite a lot wrong with having a formal specification > incorporate support for private behaviors, because it them > makes those private behaviors part of the public, official > specification. > > So I'd guess it's fine to have language about this issue in > the Applicability Statement, as long as it note that > compliance to the standard requires giving precedence to > legitimate, public domain names, which now includes TLDs. Thanks. I think we are in complete agreement. >> On a possibly-related topic, the DNSOP WG is considering >> proposals to officially allow private-use strings as top level >> domains. > > So the wg chartered for DNS operations issues is going to > modify the DNS protocol? I am trying to not have an opinion about that. One interpretation of what is going on would certainly reach either that conclusion or that the propose to modify long-standing principles on which both people and code had come to depend. Another is that one or more clever tricks are being designed that stay in conformance with the DNS protocols (whether or not in conformance with standards on which the DNS, in practice, depends and therefore it is ok. But, if you (or anyone else here) are interested in those issues, probably best to either follow them their or watch to see if those proposal enter IETF Last Call and then comment. best, john From nobody Fri Jul 23 15:37:32 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3C83A1FE0 for ; Fri, 23 Jul 2021 15:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=OFEhAMnJ; dkim=pass (2048-bit key) header.d=taugh.com header.b=erqaZ0Gt 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 NB1eBtX1soxf for ; Fri, 23 Jul 2021 15:37:24 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCEE43A1FDC for ; Fri, 23 Jul 2021 15:37:23 -0700 (PDT) Received: (qmail 76085 invoked from network); 23 Jul 2021 22:37:21 -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=12932.60fb44a1.k2107; bh=ID/1OISmJAgKvHdl8FtftvA8UU6m4Y2kq0awA1gnwmQ=; b=OFEhAMnJ9j8VI6thQ67oRY/sr0ylh/pn7RnV4VOyoPmk7OlUQ1D7oCSbff1uBFl4CErSU8mEu677Cz5jEy761x0foHBudk7AkvtlL+hJTPoqER2zxpDC6kM+zHlDiqngPYxQuoPq6BGz7lyg0nmLhJpoanSQ+j27IleszbvTaMMSgOmV/uJVx1tU72p1oCmxBXNit+xbiqb5228ajOMjntdWrUv2/av9e/jz/UZgLqtruCaA7xyPWSnUMYgIuoXWspz6LpcQRpiU2Dn8HFU5vjXS/CaPODk8wGSY0i3h1gDXKouq2Z7v370d6DFon5njMdntKjyxwhY2hEDRIiiAuA== 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=12932.60fb44a1.k2107; bh=ID/1OISmJAgKvHdl8FtftvA8UU6m4Y2kq0awA1gnwmQ=; b=erqaZ0Gt3sypulZHo70wRYrD9UqyJdQdFdPS76+/RvOBq6H+bFB1pD8TA9Cb7mGLWlbC1sB8A36blEea/zeHtURlhH1fkkvdg6LErPSGlCY8XnjBSl1IZChUqTGif5sqnOUo1hJ4Nr9nCeqYOGEgdg2WkfvhKcNhFE5aRn6zm5jDuMY7o64DBgIzQwRm4kJXJSZVrPO5nFSM6FHcR/wJ6toBVAMXmZuN5qidCyJDIVD3P3LX1yUZSA2bAdrbW9Y60bN+t7BeaHN2y4AdYIipuQzM/YRx9N+WT9af8Bw8x+n4i4nen2ZafpMhZ/24Fq2NF3vPCT7v8rlIUYLtZ8jMXA== 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; 23 Jul 2021 22:37:21 -0000 Received: by ary.qy (Postfix, from userid 501) id C671B24EB689; Fri, 23 Jul 2021 18:37:19 -0400 (EDT) Date: 23 Jul 2021 18:37:19 -0400 Message-Id: <20210723223720.C671B24EB689@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #50: Use of top level domains in SMTP X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 22:37:30 -0000 It appears that Dave Crocker said: >On 7/23/2021 7:38 AM, Alexey Melnikov wrote: >> I believe there was rough agreement in the past that use of top level >> domains is going to cause interop problems, as depending on context they >> might not be distinguishable from local hostnames. If people agree, I >> think the Applicability Statement draft should talk briefly about this. > > >Yes, as long as the language makes clear that the conflict is between an >enhanced, standardized bit of functionality, with local, >non-standardized functionality. Ever since Paul Hoffman and I published RFC 7085 in 2013 I've been doing surveys of what's in the top level of TLDs. There are currently 17 ccTLDs that have MX records at the top, For most of them, even if you can persuade your MUA to send them mail, it doesn't actually work. GT. and TT. point their MX at Google, which I think is a surprise to Google. So I agree, if you want to interoperate, the domain in an address has to have at least two components. I suppose Dave's point is correct, but that applies to just about anything in any IETF standard. R's, John From nobody Fri Jul 23 15:41:09 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3363A1FF7 for ; Fri, 23 Jul 2021 15:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=mtwO190e; dkim=pass (2048-bit key) header.d=taugh.com header.b=ZRw/PHae 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 EBe-8XpLmY48 for ; Fri, 23 Jul 2021 15:41:01 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77CD93A1FF6 for ; Fri, 23 Jul 2021 15:41:01 -0700 (PDT) Received: (qmail 76764 invoked from network); 23 Jul 2021 22:41:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=12bd8.60fb457c.k2107; bh=dFNJf3u6SX0ro7G6bohC4kC6Lft/+uL4QHtyna293Zg=; b=mtwO190eiAtZ2ktoyo3Zy/7+xyC7MyI5xNMdvHd2QzhQtj0fVpIelevdULSGKviNRpv4kXSOlfdZ8vO9N/+u/8qcVxsV5jar5t7NpgPND3uFynFm8Nvy+UJMpy61Yv2stRyEKUO0xfEgrgsRn3uRFZ20MHVgAC7N1hADWoW7Lk5Fin+l4qUnnP9hpsH5Sq1tQjl5ZboHhji43YNzM4BQhEOdx+7J/QhDwTIGDvj/LBGphmemT+AcdAHv1I8gOYffLmyXMqhtF7jZdgo9BH1xm1aGMvqps2m5Edd0yKTgkKDkxkPY6lyPTcFdcdd9J8MNSCAzMAcM7b8BdGldEtGflQ== 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=12bd8.60fb457c.k2107; bh=dFNJf3u6SX0ro7G6bohC4kC6Lft/+uL4QHtyna293Zg=; b=ZRw/PHaeU04eUQAaOBWr//VnWswB/o4jPdnlP8jtOyllvIPCABYK6Wfc1TsnSF7SNiVhtByHlVuhbWLJUYB46ZKxogk+QDkXEKuKk6b41OMdD2UkrSMTDTU0gYuse6Q2LSzzkchqiSA7KoRuWMWFt45k63smw3nR8wkdKiKeEaJCGJ3BfwWD4/2YtV83FXvY9UX1wHN44AHzXBSfFC2pOeIFse0NncYpx1v/EJJJy1HKrSL1361GtrfqiWwxY/4/qR3U1B7vlJg/RjmndvRXBOL5K5DtCrbn1g5xkq2uuh7ZRxn2tg2X7HpUcJFyCzI90BpHN0EGifDaeiuOONq1AA== 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; 23 Jul 2021 22:41:00 -0000 Received: by ary.qy (Postfix, from userid 501) id 82A8724EB6D2; Fri, 23 Jul 2021 18:40:59 -0400 (EDT) Date: 23 Jul 2021 18:40:59 -0400 Message-Id: <20210723224059.82A8724EB6D2@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: john-ietf@jck.com In-Reply-To: <6DE94CD481CE96AAD9FFED7B@PSB> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #50: Use of top level domains in SMTP X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 22:41:07 -0000 It appears that John C Klensin said: >On a possibly-related topic, the DNSOP WG is considering >proposals to officially allow private-use strings as top level >domains. If those proposals are approved, is it necessary to >add language to either the discussion of FQDNs in RFC5321bis >(noting that ticket #41 has been closed) or to add language to >the A/S to be clear that MTAs are expected to not let such >things escape onto the public Internet, just as they are >expected to prevent such addresses as example@local and >user@example.local from escaping. I don't see why mail is special here. Why is it any different from a domain in a web page? For that matter, if I send a message with mailto: adddresses in an HTML body, or an attached PDF that includes javascript that shows clickable e-mail addresses, some of which are local, how hard should the MTA try to keep them from escaping? Let's not. R's, John From nobody Fri Jul 23 15:44:18 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAAE3A200D for ; Fri, 23 Jul 2021 15:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=TtM8mz3E; dkim=pass (2048-bit key) header.d=taugh.com header.b=D/qYjlgo 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 MlH84q35OEbm for ; Fri, 23 Jul 2021 15:44:11 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0513A200E for ; Fri, 23 Jul 2021 15:44:11 -0700 (PDT) Received: (qmail 77480 invoked from network); 23 Jul 2021 22:44:10 -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=12ea6.60fb463a.k2107; bh=arC65dHF6T7edrVr6doXuu5FPlRVeuA2tSsvMDpB74I=; b=TtM8mz3EIF8diDSfqQHA5cP1hbKpPBlbMtL9iBSdRwu3GI43cTFODKdHugX3DNPknRKn2Ij8+7+cc6edgwL3+2ThGNJJWFomXda0JfIRLxtSbxw4fYw0bD3es5wJ61NYA6U4IvtzCbbLe090eI/iTMEQsRJz9GZUkKWtMPOkpjR65yKe4qs1scqtzvt6NItncPqLPxcbwAjQ1gnUhXU0sesxAszW3r9jnoPAogBDDFrnDgmuYkDKJ8PTj6Os47SJ6/4+vK0z5BjEz0HebIz726SSYNgsIozsaf+Y/GMKmtiCxa8YJFdqZURXN1CTtIu5hZTcGT+1VudY4UN1dSIzxA== 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=12ea6.60fb463a.k2107; bh=arC65dHF6T7edrVr6doXuu5FPlRVeuA2tSsvMDpB74I=; b=D/qYjlgoE717VDpD14p46QbsWfG7uPKLoW7V8EdhOglEiFenpvX84dGyZcg80xrRbqBI6ahJhEFKEV6t0cMRIOx5uxXYFIUB57g/uXuRs9ylZg/CvFYErc4G2pXAljlEhdCVW+2vqMAnoSB6E3ZNAa3wVGahxxr2EalI9tEiQqpOEmhqDI8JyHT2Mjs/SWifiOaMbm+mvutTXrQx8MV/FrmYfJoSx2hlZFiRBOYUhGXTIuqm0DMlbQcHcLvOfCDnuZ/xs1Uh6xtX2IM699cZagr4X7OVHuRypG85huxdQQUFNqeKQGgcOC7jv/ejroeTCbyuyb1MjB6SFX6MazJvTQ== 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; 23 Jul 2021 22:44:09 -0000 Received: by ary.qy (Postfix, from userid 501) id 3B19724EB73C; Fri, 23 Jul 2021 18:44:08 -0400 (EDT) Date: 23 Jul 2021 18:44:08 -0400 Message-Id: <20210723224409.3B19724EB73C@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <11162acc-85fe-0863-fb47-8c6365edf8e4@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] Ticket #50: Use of top level domains in SMTP X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 22:44:17 -0000 It appears that Dave Crocker said: >Support for TLDs as FQDNs is standardized, albeit new. Hence it can -- >and should -- be within formal email standards specifications. I hope you're not referring to things like .BANANAREPUBLIC (clothes) or .DUCK (a toilet cleaner.) The address n@ai has been around for at least a decade, and I think if you can persuade your MUA to send it mail, it works, so it's not that new. But I still think it's a bad idea to expect undotted domains in addresses to work, since that is a fairly significant incompatible change. R's, John From nobody Fri Jul 23 17:24:50 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983043A230F for ; Fri, 23 Jul 2021 17:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=iPrDUDSV; dkim=pass (2048-bit key) header.d=taugh.com header.b=tKkhHtTd 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 MVHi3TblBre1 for ; Fri, 23 Jul 2021 17:24:42 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B1B3A230D for ; Fri, 23 Jul 2021 17:24:41 -0700 (PDT) Received: (qmail 96338 invoked from network); 24 Jul 2021 00:24:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=1784a.60fb5dc8.k2107; bh=+BrFtSzo4s4RSnBg07Jp+MSzhtgjjjDodP9blQPPaoE=; b=iPrDUDSVMm0K0vVvQLXUu3/YeGI03w6ZNlNfiovg37enHmZea645R2TU0+k4+F6uAmlRYmvIB8aPdD8A/SPeE5Z/IJy9R78fol+Yzm6dnIbogcZpKrYHqxW2aBRwAUyFu2CxhyOPZRAw6PfA4d/HK1iXKeihFkIj75C2VBhULU28RK12LqOgfkie0E0/+Iz49dze8oRmG8jAN46WebN6UDMNx1pCkm5vl8wqJUuVCxBG3dfA1DtBJL8KFV3oYR6/WaJ4lUScKLb9Mq9JFic00q3SRto1F3goHWFoW/dVZkELq+mQFQho0UgHK/EsXwhod5NuMAN3Och4BT33Q/HEZg== 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=1784a.60fb5dc8.k2107; bh=+BrFtSzo4s4RSnBg07Jp+MSzhtgjjjDodP9blQPPaoE=; b=tKkhHtTdngTPQfCH+Em+vkYClrg0DVs3Vb3hfk1CEl5XsOzDFzHLlFvwCedRlx1tieNJYiz2Fwv1ze9LzsCMNvbim2lSFx2ccUCoVu1pK1+mCgp5wls7HZhRlebJ7D0OpkLhxFnIVlT2Z66AR21FX2cUMg9Icgo6YyYddNoADfo9pABjEuNYoFgiOfcToKEBxm3W7ze7FXiyeBAHa3kYawTrJH+eC0y3TPOCH2Z/+zCzzLj7sNlFfq4E2DfY0ygG1LnvyIEawYmRJER9jsR/SUnRxAl5Qqd03VlRPaQGjxufLgBNk3HT1MdOWG1kKBNgbdn5lPM9c1d4Gx1sv12B/A== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 24 Jul 2021 00:24:39 -0000 Received: by ary.qy (Postfix, from userid 501) id 1ADD124EC6A3; Fri, 23 Jul 2021 20:24:37 -0400 (EDT) Date: 23 Jul 2021 20:24:37 -0400 Message-Id: <20210724002439.1ADD124EC6A3@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: johnl@taugh.com In-Reply-To: <20210723224409.3B19724EB73C@ary.qy> 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 #50: Use of top level domains in SMTP 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, 24 Jul 2021 00:24:48 -0000 It appears that John Levine said: >It appears that Dave Crocker said: >>Support for TLDs as FQDNs is standardized, albeit new. Hence it can -- >>and should -- be within formal email standards specifications. > >I hope you're not referring to things like .BANANAREPUBLIC (clothes) >or .DUCK (a toilet cleaner.) FYI, the DNS rules at ICANN for vanity domains are the same as the rules for any other gTLDs. You cannot put an A or MX record at at the apex of a vanity domain, same as you cannot put one at the apex of .COM or .WTF. The only TLDs with MX at the apex are a handful of ccTLDs, and as I said, most of those don't actually work. R's, John From nobody Sun Jul 25 03:37:13 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90113A2495 for ; Sun, 25 Jul 2021 03:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 DMQQVJ6bmiXG for ; Sun, 25 Jul 2021 03:37:06 -0700 (PDT) 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 00B793A2493 for ; Sun, 25 Jul 2021 03:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1627209418; bh=YpV5D0/Yv+WK/LyuMVhEZsog8+qRs1fMGFtxXs6b9jQ=; l=808; h=To:References:From:Date:In-Reply-To; b=DgoAFeokzdEkUneFe4YfxQGKv30ZeFShhz/o8y/eu/cXOZRMoG4TbBB4U79Vzo0on j1sWabmxHvtE9MKn37jzIq3Mp7LfegnAD/lWtUpiWlWqBGMuxAhlHZLW3xSrgz8Jgp oyy4T552ULYJEEycHPfNqW35JgYjhYRDmUPHW0L2WwEKeX6QlAaSQSxGxWJlN 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 00000000005DC0CD.0000000060FD3ECA.00002708; Sun, 25 Jul 2021 12:36:58 +0200 To: emailcore@ietf.org References: <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.com> From: Alessandro Vesely Message-ID: Date: Sun, 25 Jul 2021 12:36:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <13fcea10-e071-5707-a83d-38a2a92e1ac7@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 #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: Sun, 25 Jul 2021 10:37:11 -0000 On Fri 23/Jul/2021 14:21:51 +0200 Alexey Melnikov wrote: > > 4) Can be added by an MDA? Could we limit this, or split it into two parts? As MDAs can re-inject messages into the mail system, we should distinguish what headers can be added or modified during delivery proper (rMDA, in rfc5598 parlance) — such headers will never be transmitted via SMTP. An example could be Munged-From:, the copy of a From: header that had been munged by a MLM to mitigate DMARC damage. This field is created by the MDA before restoring the original value of From:.[*] Best Ale -- [*] That can be done after recognizing the original signature, and could work likewise with ARC. See the suggested operation in the MTA filter's man page: http://www.tana.it/sw/zdkimfilter/zdkimfilter.html#mlmtrans From nobody Sun Jul 25 11:28:27 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6F43A3493 for ; Sun, 25 Jul 2021 11:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y17Hq4sYwOkN for ; Sun, 25 Jul 2021 11:28:19 -0700 (PDT) Received: from dragonfly.birch.relay.mailchannels.net (dragonfly.birch.relay.mailchannels.net [23.83.209.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95CD03A3462 for ; Sun, 25 Jul 2021 11:28:19 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 4AAB7321DEF; Sun, 25 Jul 2021 18:28:18 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (100-105-161-168.trex.outbound.svc.cluster.local [100.105.161.168]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 32B413225E1; Sun, 25 Jul 2021 18:28:17 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (35.45.192.35.bc.googleusercontent.com [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.105.161.168 (trex/6.3.3); Sun, 25 Jul 2021 18:28:18 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Grain-Coil: 4d836f954186b7f3_1627237698046_3375811620 X-MC-Loop-Signature: 1627237698046:2301138285 X-MC-Ingress-Time: 1627237698046 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 57A0A30B5560; Sun, 25 Jul 2021 18:28:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1627237696; bh=tgAaVN7KY1uU1sjO/jMApklTkrb4rQVjIgQuxHb+Wik=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=Zd8xh/1SBiUy5exvC5pdlUXMjaizZOOK8MJgoT1+Q/xLN246oEt9uv73cPRC/3FBD 2UNEImD5upOQx+bHx9OnwXkT3+7KTcNE1m2+o37JPYE1wCqniv5YTLlusOzTbAeIWV 1eSFowW+zVRHvwvryGMmgt+jG5mwuDjdtW8AwlzOTVTMG3R97pt58DARC9u+bXolLM zFlReRcgaY829aVdGSpfTfgduuyUu89V2js/Y8AzzV668FVJP4Waj+GGVmnoDtxI7z Qhuhf5kNaMJe1i/o+pId1uIJwM9pfKMxuAbnCaZ/Ij2NFTO3OXYj9UuJVa0SvLfk/n dfjLOqn7vpn2Q== Reply-To: dcrocker@bbiw.net To: Alessandro Vesely , emailcore@ietf.org References: <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <5ba9d71a-ca8b-8739-cc99-4ea63a3a6c72@dcrocker.net> Date: Sun, 25 Jul 2021 11:28:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.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: Sun, 25 Jul 2021 18:28:25 -0000 On 7/25/2021 3:36 AM, Alessandro Vesely wrote: > On Fri 23/Jul/2021 14:21:51 +0200 Alexey Melnikov wrote: >> >> 4) Can be added by an MDA? > > > Could we limit this, or split it into two parts?  As MDAs can re-inject > messages into the mail system, we should distinguish what headers can be > added or modified during delivery proper (rMDA, in rfc5598 parlance) — > such headers will never be transmitted via SMTP. > > An example could be Munged-From:, the copy of a From: header that had > been munged by a MLM to mitigate DMARC damage.  This field is created by > the MDA before restoring the original value of From:.[*] If an MDA is 're-injecting' a message, it is acting as an MUA or, at the least, an MSA. As for limiting who can do what, there might be some benefit in such an exercise, but I'd expect it to be a long and painful effort... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jul 25 13:12:24 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9614B3A37DC for ; Sun, 25 Jul 2021 13:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=WPj2fipa; dkim=pass (2048-bit key) header.d=taugh.com header.b=bYz8Ihhk 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 TOtVvJeNJVlA for ; Sun, 25 Jul 2021 13:12:17 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E32A83A37DB for ; Sun, 25 Jul 2021 13:12:16 -0700 (PDT) Received: (qmail 8196 invoked from network); 25 Jul 2021 20:12:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=2001.60fdc59e.k2107; bh=YzYB0C+HVOPKBbGI9dAg23QAFZcVSyGE4Js4SSMCzWg=; b=WPj2fipasFpunOZES57DiNevgK/Gd9ivvBfcTJxOaHJJdonKT/ccnmWkhONvydgdqEONo+k4cSx5j2EOhWqPirjtjZ+5teLGXuY95lIn42NUUkOKDfV39GVs9Xh4o6RG/cvuQUZKYpLaIPi6moiYWAF7f4u3lNlurYoPjd3uVdhU9LNFo5ZytAEmJbmGu+kK041a9ulyzk9kdYgovimE/OyUTYO2GMk0moOLFEwe/aRcmMkstf2hqBFvSyt9XEr10A0zEjpr4RSTIhTSl25JhSPF6hI+HJdmnwPl+OFJhRk99FLOOjbLyFgvNUeaVsPgdbhakMyzMLn1DEeTIqVUcg== 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=2001.60fdc59e.k2107; bh=YzYB0C+HVOPKBbGI9dAg23QAFZcVSyGE4Js4SSMCzWg=; b=bYz8IhhkjjQnPNFHl7Gqzg+F6EbxwP9PzHCigb/v9tSnJoi8pAwXbAMG2Cki76Ozq/VdbmDk+2RkN9w1hbEVdcax3+bL0Kr7dCF+9t80xxlLICad598vvt6aXi7rQ66+vCzP1r7S8SH1U54EVaDKJRZAo5J1X0BVhD6bF8q2ZODxCSAqaWmycGnSysEih974glPP8HZAPQt3VGc8kragHlA68Oaj4JN4AvYf12/htephrxbTtJ0Rz/eEPkeISQOiDn7gEhunQ6W5lKKCc3rwW7xCfncOb/zbJfywhdVCmI58M9Yk9r02J3cgc6OOoydOashtftE/bUAFNypCaXUPhA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 25 Jul 2021 20:12:14 -0000 Received: by ary.qy (Postfix, from userid 501) id E193724F7B23; Sun, 25 Jul 2021 16:12:12 -0400 (EDT) Date: 25 Jul 2021 16:12:12 -0400 Message-Id: <20210725201213.E193724F7B23@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] 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: Sun, 25 Jul 2021 20:12:23 -0000 It appears that Dave Crocker said: >On 7/23/2021 5:21 AM, Alexey Melnikov wrote: >> 2) Can be added by an MSA? >> >> 3) Can be added by an MTA? >> >> 4) Can be added by an MDA? > >Shouldn't the list of choices include MUA (ie, either the author or >possibly even the recipient)? I'm not necessarily opposed to this, but what problem is it solving? I assume we agree that the lists would be descriptive rather than normative, since it's unlikely anyone's going to retroactively change what their MSAs or MTAs do just because we put headers in a list. R's, John From nobody Sun Jul 25 13:19:41 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7E43A3810 for ; Sun, 25 Jul 2021 13:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10iQPI67_tR4 for ; Sun, 25 Jul 2021 13:19:34 -0700 (PDT) Received: from dormouse.elm.relay.mailchannels.net (dormouse.elm.relay.mailchannels.net [23.83.212.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CFC53A3811 for ; Sun, 25 Jul 2021 13:19:33 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 899E6362AB1; Sun, 25 Jul 2021 20:19:32 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (100-96-11-33.trex.outbound.svc.cluster.local [100.96.11.33]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id D2D29362ACD; Sun, 25 Jul 2021 20:19:31 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.11.33 (trex/6.3.3); Sun, 25 Jul 2021 20:19:32 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Keen-Lettuce: 14ccd401268c27af_1627244372297_652335215 X-MC-Loop-Signature: 1627244372297:789422674 X-MC-Ingress-Time: 1627244372297 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id DFACB10E99E7; Sun, 25 Jul 2021 20:19:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1627244371; bh=X2xAur8FuBA8a46FBPWNg1u0Iza3pcmKemej1q58j6s=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=myNkLd4YOVQ8V6xYYmjp8LJnZEfr7mCppjU/x6dR8hm1DUf9mmnaORzqusKI2wTTQ xxg3Bietv92eOWx3CxkBedklAUvIIJrZ5+UflQjYqFFcNIplnssnz0Kp0N6zJ9JbMF QSI0OpAdR33ftYMfD54r3i56IG+DWhs9CYEQapGTxI2QkF5uRVv1DpEr0ZFcK+mng/ wfQ/KUDuk+Lx7wSVvCW7BynwsORXXi3QzVnX2Fj+d8U3107SoEtmQ+s2iksYVFXFTN +h/exxWhup6QX889J+LiemXHivrS1bH/dlScO7X03HMwJ7TnQVZ1ucwDWS8Y1g8HbR cmXTM9XFMZA6A== Reply-To: dcrocker@bbiw.net To: John Levine , emailcore@ietf.org Cc: dcrocker@bbiw.net References: <20210725201213.E193724F7B23@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <83ad1702-8123-a2f4-cb36-4a8e5e594568@dcrocker.net> Date: Sun, 25 Jul 2021 13:19:28 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <20210725201213.E193724F7B23@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Sun, 25 Jul 2021 20:19:40 -0000 On 7/25/2021 1:12 PM, John Levine wrote: > It appears that Dave Crocker said: >> On 7/23/2021 5:21 AM, Alexey Melnikov wrote: >>> 2) Can be added by an MSA? >>> >>> 3) Can be added by an MTA? >>> >>> 4) Can be added by an MDA? >> Shouldn't the list of choices include MUA (ie, either the author or >> possibly even the recipient)? > I'm not necessarily opposed to this, but what problem is it solving? Just to be clear, your question appears to be about Alexey's original posting, rather than my suggested addition. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jul 25 13:36:24 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734393A3886 for ; Sun, 25 Jul 2021 13:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.4 X-Spam-Level: X-Spam-Status: No, score=-4.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=Br+col05; dkim=pass (2048-bit key) header.d=taugh.com header.b=AerTHdJt 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 RAejLimaG1lb for ; Sun, 25 Jul 2021 13:36:16 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888333A3883 for ; Sun, 25 Jul 2021 13:36:16 -0700 (PDT) Received: (qmail 12021 invoked from network); 25 Jul 2021 20:36:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=2ef3.60fdcb3f.k2107; bh=+J3PtVNBg0LClT4TwIFj2KKzoPHwewxZrtvb0PUaTn8=; b=Br+col05/D39dXzd8XQImx6fzZ1wkTgiTTO/bgARKiiQ9TKHQcuAqwSDWE+gR0widhbH1kauaxiKnmX698E67RUnDIMrs40BtlhHz4kPtFGmdMoRpLC+YsHeD110UZBDmo4CZODfDoF+B7uKSZ+q4gkLUXzAoOIza+2HxVA37a8y2GhodWEOqzA6Qar79hLRtumB+y37j63HzZsfvAaB4tN18uSL8Zrxtbj9dKTafu6lYh8nW62aMioXay59O3en/UWoIZ4JUV9CDta5rydL2vMIhBDOvVFg1UdFwgs+O9NEqOLjn61FN1b5oucRwq1THc/U6jZn58VXOZEWYfvlkg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=2ef3.60fdcb3f.k2107; bh=+J3PtVNBg0LClT4TwIFj2KKzoPHwewxZrtvb0PUaTn8=; b=AerTHdJtYwlW2GKor3r0clViAEwSLVxJZfC+PDt8M7HqAn/LXL/rGfP9IEIh6TQT4T41TL9ui4pTSpQIC/ZxeQRxVy/xYBovig9USpvIsNn7vcyWsH3RNyVj7jjeXE7BXjbPfaJ5G5ol1tE/um++nxGer608LUrIsAt2Hqh9uGvU2/5C7z7uKaxJRs//Jx/JJOWb7XpLhgx7Y8XfnEbwgkYL8Q8IAlnQDJ2XUPwL8M7fxodpIKQnqeXwyeYTPhma39vCkVOSsCAF5Y3zqezf/+1SFzOPl/7dn2h8nCyQPxORQKiTY7eFNk4WbochBFfzDlvmE2uuA7CupWzHryew0A== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 25 Jul 2021 20:36:14 -0000 Received: by ary.qy (Postfix, from userid 501) id 96ED224F7D32; Sun, 25 Jul 2021 16:36:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 806BC24F7D14; Sun, 25 Jul 2021 16:36:13 -0400 (EDT) Date: 25 Jul 2021 16:36:13 -0400 Message-ID: <9f6b9aa5-61e7-3586-2272-aed0f63c9049@taugh.com> From: "John R Levine" To: "Dave Crocker" , emailcore@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: <83ad1702-8123-a2f4-cb36-4a8e5e594568@dcrocker.net> References: <20210725201213.E193724F7B23@ary.qy> <83ad1702-8123-a2f4-cb36-4a8e5e594568@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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: Sun, 25 Jul 2021 20:36:23 -0000 > On 7/25/2021 1:12 PM, John Levine wrote: >> It appears that Dave Crocker said: >>> On 7/23/2021 5:21 AM, Alexey Melnikov wrote: >>>> 2) Can be added by an MSA? >>>> >>>> 3) Can be added by an MTA? >>>> >>>> 4) Can be added by an MDA? >>> Shouldn't the list of choices include MUA (ie, either the author or >>> possibly even the recipient)? >> I'm not necessarily opposed to this, but what problem is it solving? > > Just to be clear, your question appears to be about Alexey's original > posting, rather than my suggested addition. Well, both, but yes. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Jul 25 16:32:34 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E377A3A0E24 for ; Sun, 25 Jul 2021 16:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 YX7iNqpFCmEw for ; Sun, 25 Jul 2021 16:32:28 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FBA83A0E23 for ; Sun, 25 Jul 2021 16:32:28 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m7naW-000IQY-3o; Sun, 25 Jul 2021 19:31:16 -0400 Date: Sun, 25 Jul 2021 19:30:55 -0400 From: John C Klensin To: Alexey Melnikov cc: emailcore@ietf.org Message-ID: In-Reply-To: <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.com> References: <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.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 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: Sun, 25 Jul 2021 23:32:33 -0000 --On Friday, 23 July, 2021 13:21 +0100 Alexey Melnikov wrote: > Dear WG participants, > > I would like to get closure on this ticket, which was briefly > discussed on the mailing list and also during IETF 109 & 110. > Below is a updated strawman text: > > =============== > > Add to the IANA Considerations of rfc5321bis: > > IANA is requested to create a new subregistry for email header > fields that can be added to a message header section by a > MSA/MTA/MDA. The new subregistry would show whether a header > field can be added by a "message submission", "relay", > "delivery" system or some combination of them. Headers > appearing in this subregistry SHOULD also be registered in > ers.xhtml > ers.xhtml>> (whether it is registered as a Permanent Message > Header Field Name or as a Provisional Message Header Field > Name). The registration template has the following fields: > > 1) Name of the header field name > > 2) Can be added by an MSA? > > 3) Can be added by an MTA? > > 4) Can be added by an MDA? > > 5) Optional reference field that points to one or more > document describing the header field. > > 6) Optional comment > > Registration policy for this new subregistry is "Expert > Review". Designated Experts should only check correctness of > the information in the registration template without passing > any judgement on usuability of a specific header field being > registered. > > Updates to existing entries undergo the same process as > registration of new header fields. > > =============== > > Let me know your thoughts. Personal opinion and opinion as co-author of RFC 6409: Much of the reason for creating a separate Message Submission specification was to make it clear that the MSA was allowed to do things that, in a more abstract world, we expected MUAs to do and discouraged MTAs from doing. In other words, the boundary between MUA and SMA is deliberately unclear; the MUA could incorporate MSA functions (or not) or could communicate with the MSA using just about whatever protocol or API the two agreed on, etc. So, if this proposal intends to classify MUAs and MSAs as separate, we'd better have a crisp definition of the boundary that does not contradict 6409. I predict that will be hard. More generally (and with Editor hat on): Over the year SMTP specifications have deliberately not distinguished between MUAs and MSAs or between MDAs assorted message store functions. All an SMTP server (receiver) knows is that it got a message from somewhere (could be an MSA, an MUA with SMA functionality, or a relay) and all an SMTP client (sender) knows is that it is delivering the message somewhere. Even the "final delivery server" language of Section 2.3.3 is a little fuzzy, still points to MTSs getting messages from MUAs, which should probably be fixed, and explicitly acknowledges that attempts to use those terms precisely often does not align with practice. While I do not object to the idea of a subregistry as proposed, it seems to me that, if it is going to be specified in 5321bis, either clear definitions need to be specified in that document and section 2.3.3 rewritten to stop the handwaving or there need to be normative references to a standards track document (preferably an Internet Standard) that contains those definitions. FWIW, I think that doing the work in some separate specification would incur the same problems, but it would not be my problem to sort out editorially. john From nobody Sun Jul 25 16:42:30 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386E43A0E7D for ; Sun, 25 Jul 2021 16:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.753 X-Spam-Level: X-Spam-Status: No, score=-0.753 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_BL_SPAMCOP_NET=1.347, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVUET0rQvA-b for ; Sun, 25 Jul 2021 16:42:23 -0700 (PDT) Received: from black.elm.relay.mailchannels.net (black.elm.relay.mailchannels.net [23.83.212.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A403A0E83 for ; Sun, 25 Jul 2021 16:42:23 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 231444020CB; Sun, 25 Jul 2021 23:42:22 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (100-96-17-89.trex.outbound.svc.cluster.local [100.96.17.89]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 64F97401F90; Sun, 25 Jul 2021 23:42:21 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (35.45.192.35.bc.googleusercontent.com [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.17.89 (trex/6.3.3); Sun, 25 Jul 2021 23:42:21 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Wipe-Decisive: 46916be86c543f97_1627256541852_3074901710 X-MC-Loop-Signature: 1627256541851:1598866931 X-MC-Ingress-Time: 1627256541851 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 89BF430B5560; Sun, 25 Jul 2021 23:42:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1627256540; bh=ftqaB9fBXOD5F+kZnCk6E1n4bXWWYX7oYOKmKXjoFUs=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=sPvmSsxUvvSYexldtGfpw+xefscKobH8H7UvS+BIHmS5ESFbzn9s9YX9Ih3QTF3NF G3eUNWNVwb+/KoBP1xrCtO2VRfc0/tbWgq092UYftCS1mnRq0Ux9VG+ZbrZ5lL6ZAc vUiAT95u18+IxPKf/mfpz97YzZgQC79TWS08pTW3R/Dyv9HTuuWLSfqyedGSMAaYpv VCC2tnEmAFf+Z9W20QpQnRFB7rrrJ8v5I6MqL9TW7sNsVgp2cWrM93gRdWza3qBtUq YcmD4pZMA2ELrT/l0AnzApqQmkT6+SAINU3SRjLjgnDAkt9phAocoJlMY0+ydZpxeL 65tnvxTwddCPw== Reply-To: dcrocker@bbiw.net To: John C Klensin Cc: emailcore@ietf.org References: <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Sun, 25 Jul 2021 16:42:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.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: 7bit 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: Sun, 25 Jul 2021 23:42:28 -0000 On 7/25/2021 4:30 PM, John C Klensin wrote: > Personal opinion and opinion as co-author of RFC 6409: Much of > the reason for creating a separate Message Submission > specification was to make it clear that the MSA was allowed to > do things that, in a more abstract world, we expected MUAs to do > and discouraged MTAs from doing. In other words, the boundary > between MUA and SMA is deliberately unclear; the MUA could > incorporate MSA functions (or not) or could communicate with the > MSA using just about whatever protocol or API the two agreed on, > etc. You appear to be saying that Sections 4.2.1 and 4.3.1 of RFC 5598 are not sufficiently clear or complete. Please elaborate with particulars. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jul 25 17:41:14 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B863A081F for ; Sun, 25 Jul 2021 17:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tozmaOZDWlrb for ; Sun, 25 Jul 2021 17:41:07 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D463A0812 for ; Sun, 25 Jul 2021 17:41:07 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m7ofR-000IU9-MT; Sun, 25 Jul 2021 20:40:25 -0400 Date: Sun, 25 Jul 2021 20:40:05 -0400 From: John C Klensin To: dcrocker@bbiw.net cc: emailcore@ietf.org Message-ID: In-Reply-To: References: <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.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 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, 26 Jul 2021 00:41:12 -0000 --On Sunday, 25 July, 2021 16:42 -0700 Dave Crocker wrote: > On 7/25/2021 4:30 PM, John C Klensin wrote: >> Personal opinion and opinion as co-author of RFC 6409: Much of >> the reason for creating a separate Message Submission >> specification was to make it clear that the MSA was allowed to >> do things that, in a more abstract world, we expected MUAs to >> do and discouraged MTAs from doing. In other words, the >> boundary between MUA and SMA is deliberately unclear; the MUA >> could incorporate MSA functions (or not) or could communicate >> with the MSA using just about whatever protocol or API the >> two agreed on, etc. > > > You appear to be saying that Sections 4.2.1 and 4.3.1 of RFC > 5598 are not sufficiently clear or complete. > > Please elaborate with particulars. I am saying that RFC 5598 is an Informational document, perhaps in part because some of its sections could not get consensus. If you want to propose to some appropriate AD that it be put out for Last Call to move it to Proposed Standard or BCP, or recommend chartering a WG for the purpose (or assigning it to an existing AD), by all means go for it. Or you could convince the WG to tell me to go ahead and create a normative reference to 5598 5598 to and use the exception procedure, but I imagine some of us would argue that would be tantamount to moving standards track and hence out of charter. john > > d/ From nobody Sun Jul 25 18:26:02 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336B13A12BB for ; Sun, 25 Jul 2021 18:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=PpUeEPw7; dkim=pass (2048-bit key) header.d=taugh.com header.b=Lf6yINqH 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 qa1M1KK1Ttzk for ; Sun, 25 Jul 2021 18:25:55 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A8633A12B2 for ; Sun, 25 Jul 2021 18:25:55 -0700 (PDT) Received: (qmail 50862 invoked from network); 26 Jul 2021 01:25:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=c6a9.60fe0f20.k2107; bh=oZVmgn/3chEFaLlrneVYPAqMuzQ1Nc2+Tc/NFon+6VA=; b=PpUeEPw7/U5i8hYi+rRKNjOHNNkDQv9eNfPDLxvKxVXl4Cwut+iHkJwJBJBZ1J4xLORacrOV+v386WxPNIdRJSr29pnb7w7yll1gHI0o5lFyCAAUTVB5XT+LRW4iysPx3LF41GLmCC+Kv06XmsLC5QnwZ0gfYaWrSAoOSha5Jwg4uqFR+ULLce2y5/y+Gx57gmXGbrAuSsVMfQTVY8mVWhcYSVE4uqQRcH4antvlRt5bv4MLcxZ30ayH1zOHBIM/bJjvzbWtoeuAGr9VgCDOc6EBcEUmLhygss5qxxh+XcgIT4RL7xPXVlzePPLaKMGt682lF6Ke+JPKS1T4Kq5eyg== 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=c6a9.60fe0f20.k2107; bh=oZVmgn/3chEFaLlrneVYPAqMuzQ1Nc2+Tc/NFon+6VA=; b=Lf6yINqHdJINVfgdHlsss5mVJ6V4TuCBlq0A4NkmNte0dJ9jzjEwk0SwnNtIaHPCB/hXivck2Ia/wqNeuwMuAuXyjjpKy47+r9gCxo4XdP/QD7NQcH0zfdPZo5pSWg95BHLPAhupzcI+nzfQ8QcLhOpcicxTOoCugTsVU9e/7qZ2m/Mf1JEGqRPmb+RZRF1YP4l4/G0M+cHEDCjyh4iwjTSMCzJ8gbPb4fjXV3Y4D3hQ+2lWFkJKDRt1RPp8LvQuJiCcDCcsXiPqKAcKoZAIFyC2JHAK2405seuXtX53f0nGkcchf2USaj24im9MBQgktcpD9jVXhfkX/H6N+Si//A== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 26 Jul 2021 01:25:52 -0000 Received: by ary.qy (Postfix, from userid 501) id 0D13C24FAA25; Sun, 25 Jul 2021 21:25:50 -0400 (EDT) Date: 25 Jul 2021 21:25:50 -0400 Message-Id: <20210726012552.0D13C24FAA25@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: john-ietf@jck.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] 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, 26 Jul 2021 01:26:01 -0000 It appears that John C Klensin said: >Or you could convince the WG to tell me to go ahead and create a >normative reference to 5598 5598 to and use the exception >procedure, but I imagine some of us would argue that would be >tantamount to moving standards track and hence out of charter. Yikes. If we make this list of headers, it's not going to be normative, since we can't retroacively clean up 40 years of practice, and while 5598 is a useful model of the way mail systems work, there's a lot of places where theory and practice don't exactly match. Many headers are ideally created by MUAs but in practice added by MSAs, so they get listed both places. There's also overlap between MTA and MDA depending on how a mail system is built. I still don't understand what problem this exercise would be solving. From nobody Sun Jul 25 19:06:10 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5123B3A1437 for ; Sun, 25 Jul 2021 19:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 EVUSioeRBhw5 for ; Sun, 25 Jul 2021 19:06:03 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3673A1435 for ; Sun, 25 Jul 2021 19:06:03 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m7pzm-000IY9-RN; Sun, 25 Jul 2021 22:05:30 -0400 Date: Sun, 25 Jul 2021 22:05:10 -0400 From: John C Klensin To: John Levine , emailcore@ietf.org Message-ID: <7B7704211E06466E4EDA7884@JcK-HP5> In-Reply-To: <20210726012552.0D13C24FAA25@ary.qy> References: <20210726012552.0D13C24FAA25@ary.qy> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline 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, 26 Jul 2021 02:06:09 -0000 --On Sunday, 25 July, 2021 21:25 -0400 John Levine wrote: > It appears that John C Klensin said: >> Or you could convince the WG to tell me to go ahead and >> create a normative reference to 5598 5598 to and use the >> exception procedure, but I imagine some of us would argue >> that would be tantamount to moving standards track and hence >> out of charter. > > Yikes. If we make this list of headers, it's not going to be > normative, since we can't retroacively clean up 40 years of > practice, and while 5598 is a useful model of the way mail > systems work, there's a lot of places where theory and > practice don't exactly match.\ Exactly. > Many headers are ideally created by MUAs but in practice added > by MSAs, so they get listed both places. There's also overlap > between MTA and MDA depending on how a mail system is built. > > I still don't understand what problem this exercise would be > solving. Speaking personally only, agreed. For me that created a situation in which IANA should insist on my precise definitions to run even a piece of a registry and getting to those definitions --with theory and practice matching-- is likely to be sufficient trouble that the benefits and problem being solved had best be _very_ clear. best, john From nobody Sun Jul 25 19:40:06 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AD73A157C for ; Sun, 25 Jul 2021 19:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7x6LHmChZONi for ; Sun, 25 Jul 2021 19:39:59 -0700 (PDT) Received: from eastern.birch.relay.mailchannels.net (eastern.birch.relay.mailchannels.net [23.83.209.55]) (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 C7EE33A157F for ; Sun, 25 Jul 2021 19:39:58 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 41974101DA3; Mon, 26 Jul 2021 02:39:57 +0000 (UTC) Received: from gcp-europe-west2-c-smtpout1.hostinger.io (100-105-161-168.trex.outbound.svc.cluster.local [100.105.161.168]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id C5FD9101BC6; Mon, 26 Jul 2021 02:39:55 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-europe-west2-c-smtpout1.hostinger.io (160.117.246.35.bc.googleusercontent.com [35.246.117.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.105.161.168 (trex/6.3.3); Mon, 26 Jul 2021 02:39:57 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Celery-Stretch: 731175f764f9357f_1627267196942_2502727467 X-MC-Loop-Signature: 1627267196942:1329541559 X-MC-Ingress-Time: 1627267196942 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id BC0CF409ADB9; Mon, 26 Jul 2021 02:39:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1627267194; bh=PAe8NvXsAEVj4VvuFsiGPG6S1hyltDmMcIS9w1evW/U=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=BdaKHehXps6OYVwQECPbrgKFOqnkgUjyH5A+PdYsZmr0tyKkvikIc3659+rGXBHY1 h1wfwqT6KbtrJbEHimNlsa0NiSnelU6PsUV532nFfAqZV1qUEY/UbT05FnSXxo9bTy rxJKotQSuDVWXrSmDMKvUC86llaJmVV/QYvothVHCgZus0TbiSS1T6TEVj0mLvgTYC m70DFSIdXeZf6s65I1Inl4q3inpH7OIqhoy69i5JSW0TYU5bPZJa7reIqLY5JIyRc8 fzAXV6jE9hQcviNusGX37GrutVr5FaA/3riOtjtwlvJGxbbauSudV78DR7AUtnzfp9 pw03Ns9V71vEg== Reply-To: dcrocker@bbiw.net To: John C Klensin Cc: emailcore@ietf.org References: <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Sun, 25 Jul 2021 19:39:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.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: 7bit 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, 26 Jul 2021 02:40:05 -0000 On 7/25/2021 5:40 PM, John C Klensin wrote: > I am saying that RFC 5598 is an Informational document, perhaps > in part because some of its sections could not get consensus. John, Since you were there, you know that's not the reason. You know that there was actually very strong rough consensus among email technical participants that it should be standards track. I think you were among the very few -- perhaps one other? -- who argued against it. Given that the document had 5 years of collaborative IETF work, a strong rough consensus isn't all that surprising. You know that what happened was that the IESG decided to go against that rough consensus. For some reason. In any event, my question to you was based on the substance of your original comment. For some reason, you have been unable to engage in the substance of RFC 5598. Again note that it is an IETF-approved document, which means there was IETF consensus to publish it. Your statement that I originally responded to was: > On 7/25/2021 4:30 PM, John C Klensin wrote: >> Personal opinion and opinion as co-author of RFC 6409: Much of >> the reason for creating a separate Message Submission >> specification was to make it clear that the MSA was allowed to >> do things that, in a more abstract world, we expected MUAs to do >> and discouraged MTAs from doing. In other words, the boundary >> between MUA and SMA is deliberately unclear; The sections of RFC 5598 provide a significant amount of text that includes dealing with just this sort of issue. So again I'll ask, what are the specific deficiencies of those bits of substantive text for this bit of presumably-substantive concern that you have expressed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jul 26 09:26:42 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786203A1C7E for ; Mon, 26 Jul 2021 09:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOWz5C7Mmwur for ; Mon, 26 Jul 2021 09:26:28 -0700 (PDT) Received: from dog.elm.relay.mailchannels.net (dog.elm.relay.mailchannels.net [23.83.212.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F613A1C5D for ; Mon, 26 Jul 2021 09:26:25 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id DED6E1E293D; Mon, 26 Jul 2021 16:18:09 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (100-105-161-168.trex.outbound.svc.cluster.local [100.105.161.168]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 1F5F21E27CD; Mon, 26 Jul 2021 16:18:09 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.105.161.168 (trex/6.3.3); Mon, 26 Jul 2021 16:18:09 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Fearful-Power: 0cf902d44ea6f184_1627316289545_3947754819 X-MC-Loop-Signature: 1627316289545:2464687613 X-MC-Ingress-Time: 1627316289544 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id C41B2110F422; Mon, 26 Jul 2021 16:18:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1627316287; bh=O4gDkuEDbBQLYKSzLH4+WavbCqgkGuAsukVsCoEPJiQ=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=K3P6ERJbL1es4QE1b6JaC8yxoXkd6nQM7WVec2hvbI2/IynpSur4e0jhH9MKhVfD8 3L+KrKOesN1CF5HBCDqIQ5xfWxceuwlVykk5PDDJiohTQtvRJ0tNmZ5pVswJbnGNJF 0gLLP4lDWWtvrnhcgEi1uQZ1ASbFfrZykh+IrWoxaB5rMcwh0TeBvE8HscmESUJEPA o1A/qSvvmn3Ry9UkRhcmWiA+LZaSCoC4FZBLZ6ylIM6ourovZMgXvzgPIwYIak6//h ToxaYpvU0pHdeMH/QXVkx6t2EHIHXozBtpKYOXaJHjGEym5ANDQPOyZeLUbD+vkN+M iGfBSIxsLQs8w== Reply-To: dcrocker@bbiw.net To: Alexey Melnikov , emailcore@ietf.org References: From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <0c7be232-a39c-480a-c194-1bd7168935d1@dcrocker.net> Date: Mon, 26 Jul 2021 09:18:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.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: 7bit 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, 26 Jul 2021 16:26:41 -0000 On 11/16/2020 9:10 AM, Alexey Melnikov wrote: > Based on an earlier discussion on the mailing it looks like there is > consensus to create (or possible ammend an existing) registry for header > fields with extra information about which types of SMTP agents are > allowed to add them in transit or before final delivery. Taking John Levine's pointed challenge on this issue, I went back to this start-of-thread message and now find myself also questioning what the benefit of this effort will be. Technical specifications or Applicability Statements, or the like, will contain the normative information about acceptable use of a header field. Providing such information in a registry will, therefore, be redundant. (Possibly adding the risk of divergence, over time.) If that redundancy were expected to be extremely helpful -- such as finding appropriate header fields for a given functional component -- then it might be useful. Given the work of maintaining a registry -- and that risk of it getting out of sync with the normative specifications -- I'd suggest that the expected utility needs to be /very/ high. Absent such a claim and support for it, this isn't likely to be a constructive change. Registries should be for coordinating against collisions, dealing with scarcity, and not much else, absent truly compelling justification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jul 26 09:50:29 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B9C3A1D05 for ; Mon, 26 Jul 2021 09:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 OOD5aOWLvZoY for ; Mon, 26 Jul 2021 09:50:23 -0700 (PDT) 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 E16303A1D01 for ; Mon, 26 Jul 2021 09:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1627318218; bh=Uc2xJbV/yJI1uNL6rl62egfHIXfVte2/sngdGgJ5I1o=; l=928; h=To:References:From:Date:In-Reply-To; b=AXGLNizP9Zr0UgIXd0qKoVvz1V+WhjV1XNiRhoWZu6DO5l2uDk1JaRGKIAAG+Iynp RwkTPPm4H+FQyPA7wEg4gZF9hZGtF7vbm3ewiYpzQbTTE6IlgDivfsisPy+io0G299 6WfNNgrBDpaEsqyHEQUAelgnMjLiHbWYyDkntQnVULc7/SL+y7ksBAz9Ig1cw 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 00000000005DC028.0000000060FEE7CA.000075A4; Mon, 26 Jul 2021 18:50:18 +0200 To: emailcore@ietf.org References: <13fcea10-e071-5707-a83d-38a2a92e1ac7@isode.com> <5ba9d71a-ca8b-8739-cc99-4ea63a3a6c72@dcrocker.net> From: Alessandro Vesely Message-ID: Date: Mon, 26 Jul 2021 18:50:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <5ba9d71a-ca8b-8739-cc99-4ea63a3a6c72@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #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, 26 Jul 2021 16:50:28 -0000 On Sun 25/Jul/2021 20:28:14 +0200 Dave Crocker wrote: > On 7/25/2021 3:36 AM, Alessandro Vesely wrote: >> On Fri 23/Jul/2021 14:21:51 +0200 Alexey Melnikov wrote: >>> >>> 4) Can be added by an MDA? >> >> Could we limit this, or split it into two parts?  As MDAs can re-inject >> messages into the mail system, we should distinguish what headers can be >> added or modified during delivery proper (rMDA, in rfc5598 parlance) — such >> headers will never be transmitted via SMTP. >> >> An example could be Munged-From:, the copy of a From: header that had been >> munged by a MLM to mitigate DMARC damage.  This field is created by the MDA >> before restoring the original value of From:.[*] > > If an MDA is 're-injecting' a message, it is acting as an MUA or, at the least, > an MSA. Right. Adding that clarification would effectively limit the meaning of "Can be added by an MDA". Best Ale -- From nobody Tue Jul 27 10:58:44 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DED3A0E95 for ; Tue, 27 Jul 2021 10:58:42 -0700 (PDT) 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 vsAQ3724tjsD for ; Tue, 27 Jul 2021 10:58:37 -0700 (PDT) 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 08D5E3A0E92 for ; Tue, 27 Jul 2021 10:58:36 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1W7I7AI7K00HWH8@mauve.mrochek.com> for emailcore@ietf.org; Tue, 27 Jul 2021 10:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1627408412; bh=PgOS/OYD2t4NoSHfIczwO2vGsj0iv84sNDIXRddXK2s=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=MG3549HZx633+RpCK7+8Ur1Uj1FUJNT956JOZsvAm4Oq4QwErOaADFBzz1qYQxEKj NkpEBVDzBv4ylNQPfKjaRyuGcMgj+MangE9wMSXvSvZjyZ7hacSY9aLZepOdlhazqF /uYpQrE2o4SMO36auZZJYSCv+cDAB9sqKounTCNE= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1LCO8JIDC005PTU@mauve.mrochek.com>; Tue, 27 Jul 2021 10:53:30 -0700 (PDT) Cc: Alexey Melnikov , emailcore@ietf.org Message-id: <01S1W7I5ISU4005PTU@mauve.mrochek.com> Date: Tue, 27 Jul 2021 10:39:02 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 26 Jul 2021 09:18:06 -0700" <0c7be232-a39c-480a-c194-1bd7168935d1@dcrocker.net> References: <0c7be232-a39c-480a-c194-1bd7168935d1@dcrocker.net> To: Dave Crocker 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, 27 Jul 2021 17:58:43 -0000 > On 11/16/2020 9:10 AM, Alexey Melnikov wrote: > > Based on an earlier discussion on the mailing it looks like there is > > consensus to create (or possible ammend an existing) registry for header > > fields with extra information about which types of SMTP agents are > > allowed to add them in transit or before final delivery. > Taking John Levine's pointed challenge on this issue, I went back to > this start-of-thread message and now find myself also questioning what > the benefit of this effort will be. I did so as well, and I see a lot of problems I didn't see before. For starters, I'm confused by the use of the term "subregistry". This seems to me to come down to an update to RFC 3864 to add a column where people can indicate where in email architecture they expect this field to be added. If that's the case, then I don't understand what this has to do with SMTP and thus why it has any business being in RFC 5321bis. Our architecture covers more than SMTP, and this is true even if you expand the scope to cover SUBMIT and LMTP. If anything this belongs in RFC 5322bis. If you think about things this way I think most of the issues about MSA/MDA/MUA/MfooA disappear. The columns is a means of indicating the point in the architecture where it makes sense for it to be added. Nothing more. How this corresponds to actual implementations, which we all know map the architectural elements to software components in complex and fairly arbitrary ways, is essentially irrelevant. > Technical specifications or Applicability Statements, or the like, will > contain the normative information about acceptable use of a header > field. Providing such information in a registry will, therefore, be > redundant. (Possibly adding the risk of divergence, over time.) > If that redundancy were expected to be extremely helpful -- such as > finding appropriate header fields for a given functional component -- > then it might be useful. The value of the information is essentially the same as the value of registering header fields - it's useful to know what people's intentions are/were, and why they did what they did. (It's actually even more useful when what they did doesn't actually make much sense.) The counter to this is that the header field registry has, regretfully, for the most part failed to capture this sort of information. Asking for more information isn't gong to change this, but I don't see how it hurts. > Given the work of maintaining a registry -- and that risk of it getting > out of sync with the normative specifications -- I'd suggest that the > expected utility needs to be /very/ high. This makes no sense to me. The registry exists and is being maintained, so that's a sunk cost. Adding a column to it seems to me to a minimal cost addtion. What am I missing here? > Absent such a claim and support for it, this isn't likely to be a > constructive change. > Registries should be for coordinating against collisions, dealing with > scarcity, and not much else, absent truly compelling justification. Coordinating use outside of standardize use-cases is also kind of important. Ned From nobody Wed Jul 28 07:16:45 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3623A1210 for ; Wed, 28 Jul 2021 07:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 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 ANZdg7VxPM6f for ; Wed, 28 Jul 2021 07:16:39 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 512C83A1217 for ; Wed, 28 Jul 2021 07:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1627481798; d=isode.com; s=june2016; i=@isode.com; bh=p/HBcEuIAY/USqYGnuqVD14kNrY+hg3jzKaHeXAN5ck=; 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=LDb9b/sxM0HddI5sAB//s3twFpCY3XqiGx9RQLqSW1hTXAdNBRNQ5U1Dej+amWitvIUJif nKfsXFyCJFoMpDUv6912u2QF3M+l9qNQCZot5d4+mdEgDI2UjFjaXbpi6EXeilxPjnOgPJ NbLQRa85v83uwwDCQa73HThVX/0A4SE=; Received: from [192.168.0.5] ((unknown) [94.3.228.58]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 28 Jul 2021 15:16:38 +0100 X-SMTP-Protocol-Errors: NORDNS To: dcrocker@bbiw.net, emailcore@ietf.org References: <0c7be232-a39c-480a-c194-1bd7168935d1@dcrocker.net> From: Alexey Melnikov Message-ID: Date: Wed, 28 Jul 2021 15:16:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 In-Reply-To: <0c7be232-a39c-480a-c194-1bd7168935d1@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Ticket #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, 28 Jul 2021 14:16:44 -0000 Hi Dave, On 26/07/2021 17:18, Dave Crocker wrote: > On 11/16/2020 9:10 AM, Alexey Melnikov wrote: >> Based on an earlier discussion on the mailing it looks like there is=20 >> consensus to create (or possible ammend an existing) registry for=20 >> header fields with extra information about which types of SMTP agents=20 >> are allowed to add them in transit or before final delivery. > > Taking John Levine's pointed challenge on this issue, I went back to=20 > this start-of-thread message and now find myself also questioning what=20 > the benefit of this effort will be. > > Technical specifications or Applicability Statements, or the like,=20 > will contain the normative information about acceptable use of a=20 > header field.=C2=A0 Providing such information in a registry will,=20 > therefore, be redundant.=C2=A0 (Possibly adding the risk of divergence,=20 > over time.) One of the main purposes of the proposed registry is to be able to find=20 a specific RFC that defines a particular header field. So the advice of=20 "just find the RFC" is not particularly helpful, considering how many=20 there are now. Also, the registry will contain header fields not necessarily defined in=20 an RFC (e.g. header fields already in use in the wild), which would=20 serve a useful purpose. I don't think I agree about the risk of divergence: we will populate the=20 registry once for known header fields and then future RFCs will just=20 update the registry. As our community will know about existence of this=20 new registry, I don't think it will be likely that RFC authors will=20 forget to update it. > If that redundancy were expected to be extremely helpful -- such as=20 > finding appropriate header fields for a given functional component --=20 > then it might be useful. IMHO, this would be useful as well. > > Given the work of maintaining a registry -- and that risk of it=20 > getting out of sync with the normative specifications -- I'd suggest=20 > that the expected utility needs to be /very/ high. > > Absent such a claim and support for it, this isn't likely to be a=20 > constructive change. > > Registries should be for coordinating against collisions, dealing with=20 > scarcity, and not much else, absent truly compelling justification. Best Regards, Alexey From nobody Wed Jul 28 07:36:04 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F86F3A12F4 for ; Wed, 28 Jul 2021 07:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 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 W65A0OF-GbmE for ; Wed, 28 Jul 2021 07:35:58 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id A669E3A12E1 for ; Wed, 28 Jul 2021 07:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1627482957; d=isode.com; s=june2016; i=@isode.com; bh=e1AY/Md4tmcGMRoQF1Bni0oxyXcvBSwqJSPybBSuycU=; 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=nDgM+7FKzDes713K+Qy4KH0hZ7ayvlO3DnQAcH/VmDGtkmcvV8q5gbAnmQQYUlbYzjRf72 E0fCHu0yWBN3OvfmPGTgHc2S13pE6s6tQK5u84zgn9Mm6DRBDO82Y94BkE2ATqCCrfllbv irAaeczzKaSK77ufpyUAyfL609epbyg=; Received: from [192.168.0.5] ((unknown) [94.3.228.58]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 28 Jul 2021 15:35:57 +0100 X-SMTP-Protocol-Errors: NORDNS To: Ned Freed Cc: emailcore@ietf.org, Dave Crocker References: <0c7be232-a39c-480a-c194-1bd7168935d1@dcrocker.net> <01S1W7I5ISU4005PTU@mauve.mrochek.com> From: Alexey Melnikov Message-ID: <5e9a9217-177c-987f-a506-41c4aeb80538@isode.com> Date: Wed, 28 Jul 2021 15:35:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 In-Reply-To: <01S1W7I5ISU4005PTU@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Ticket #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, 28 Jul 2021 14:36:03 -0000 Hi Ned, On 27/07/2021 18:39, Ned Freed wrote: >> On 11/16/2020 9:10 AM, Alexey Melnikov wrote: >> > Based on an earlier discussion on the mailing it looks like there is >> > consensus to create (or possible ammend an existing) registry for=20 >> header >> > fields with extra information about which types of SMTP agents are >> > allowed to add them in transit or before final delivery. > >> Taking John Levine's pointed challenge on this issue, I went back to >> this start-of-thread message and now find myself also questioning what >> the benefit of this effort will be. > > I did so as well, and I see a lot of problems I didn't see before. You were the original person who motivated creation of this ticket=C2=A0 10= =20 months ago :-): ---------------------- Ned Freed wrote: There are many fields that get added after submission and before final delivery. And not all of them really qualify as "trace" IMO. Moreover, making a list of these fields is a hopeless task, since all it takes is one more document to outdate the list. I see two possible solutions: (1) Craft some text saying something like, "Only add fields specified as OK to be added in other specifications." (2) Create a registry. I kind of like the idea of a registry, but it is a fair bit more work. ---------------------- > > For starters, I'm confused by the use of the term "subregistry". This=20 > seems to > me to come down to an update to RFC 3864 to add a column where people > can indicate where in email architecture they expect this field to be=20 > added. No, this is not what I meant. I meant it would be listed on the same=20 page as registered permanent/provisional header fields. But even that is=20 not required, if people don't think this is a good idea. And no, definitely not suggesting any changes to RFC 3864, as it is also=20 used by HTTP and Usenet, as having extra columns that only apply to=20 email would be very confusing to other users of the registry. Anyway, let's change "subregistry" to "registry". > > If that's the case, then I don't understand what this has to do with=20 > SMTP and > thus why it has any business being in RFC 5321bis. Our architecture=20 > covers more > than SMTP, and this is true even if you expand the scope to cover=20 > SUBMIT and > LMTP. > > If anything this belongs in RFC 5322bis. That would be Ok with me personally. > > If you think about things this way I think most of the issues about > MSA/MDA/MUA/MfooA disappear. The columns is a means of indicating the > point in the architecture where it makes sense for it to be added.=20 > Nothing > more. How this corresponds to actual implementations, which we all know > map the architectural elements to software components in complex and > fairly arbitrary ways, is essentially irrelevant. Ok, so are you suggesting some changes to how columns are named? Or=20 their removal altogether? Can you please clarify. Best Regards, Alexey From nobody Wed Jul 28 08:30:46 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC083A1538 for ; Wed, 28 Jul 2021 08:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsEBSXvfIN9L for ; Wed, 28 Jul 2021 08:30:40 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE063A1536 for ; Wed, 28 Jul 2021 08:30:40 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id b20so2592490qkj.3 for ; Wed, 28 Jul 2021 08:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=n9OIREt84WxBxtKDmdE3P0ypOYINzlAedS2cWbtrDxY=; b=S8UhVXNfaBLYPHz6Zjm+doQffv2YwOrhAsvwCQBq5NaE/+6ZlY7Vatsvp6vE+mOZeV K2xnu3UlDRPfkWzq2nJ+FwAH9H1bk0mI7mTq6pMhzgJK78E6DLe35u3+x6YxRNKyLbjY fJhwRnLQ4luRDsJ3FJ8stkXf0jvUxJK1wKuBHrOqiYTeyVC3kA16l1a1IqlSIapGNNEa ubkqzrh48LR4pe2Jx/6Y8tFhuGWEGUvOLecsxzXceJquQC2hthkRRY+3r077NgQ3RXJV TO9i4Sx9fNzaZo3i2IR3OhJmBvzSd9smlSE0Ub+SWqvJbwlsT66x1qmQBPOReBrCGP0v ErmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=n9OIREt84WxBxtKDmdE3P0ypOYINzlAedS2cWbtrDxY=; b=UtgElJOZ/UePppsaOjf8sksLrDLrcR65bFssWH9I5nG22PEvEVPPBdQK/ikYjgbn6n ZwkLb66QWX/s2w5y4Vhbae0/LxkIr4TrC9ETxeqPX2Xh2DZ5eEMrJLJODY15PxuVT97f BSEP9xXfjtXDwmw1S1PlqwqSNGmg8tycc1yZpNzVhWK4dzPNPJ1TahFDwF6ESoOTY+R4 xNvdA/zb7FOMtYqAr2C1X+btbSNzklSdKE58XxiFTaQceaPxemKfPTMSM9O/qZV/1kjD Hp6uiPspz6WA18Q3k3rjemQcan8aNvYSeUjd1crKyz1I3y/mzn+DViw2P0hK2HeJHanC 0Qqg== X-Gm-Message-State: AOAM531CJmGlJuaG4tGz+YmH1yLXf0+LlcJkNk1o2AgMgTQ2fRuvAF5C Qu4z3uJvx1c7D+JtCrhFOOMxjuGnm6uunPl1UcKDftWgud8QAQ== X-Google-Smtp-Source: ABdhPJxN+1gZVuVpQUwZp+AH0uFDdY924nmTODVPwkehfhJjzuXa76rRMO9YIx4PVti4bUOG298/cER3xczCbxMbca8= X-Received: by 2002:a05:620a:171e:: with SMTP id az30mr185698qkb.325.1627486238944; Wed, 28 Jul 2021 08:30:38 -0700 (PDT) MIME-Version: 1.0 From: Todd Herr Date: Wed, 28 Jul 2021 11:30:23 -0400 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="00000000000026426f05c830ab83" Archived-At: Subject: [Emailcore] Closing Ticket #14 (G.7.8 Review Different Size Limits) 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, 28 Jul 2021 15:30:45 -0000 --00000000000026426f05c830ab83 Content-Type: text/plain; charset="UTF-8" Greetings. I heard during the IETF 111 emailcore session on July 27 that consensus here was that there was no need to change the text that specifies various size limits in sections 4.5.3.1.[1-8]. Therefore, I will be closing the ticket on July 30 unless objections are raised. https://trac.ietf.org/trac/emailcore/ticket/14 https://codimd.ietf.org/notes-ietf-111-emailcore -- *Todd Herr* | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --00000000000026426f05c830ab83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings.

I heard during the IETF 111 emai= lcore session on July 27 that consensus here was that there was no need to = change the text that specifies various size limits in sections 4.5.3.1.[1-8= ].

Therefore, I will be closing the ticket on July 30 unless objections= =C2=A0are raised.

https://trac.ietf.org/trac/emailcore/ticket/14


--

<= div style=3D"text-align:left">Todd Herr | Technical Director, Standards and Ecosystem
m: 703= .220.4153

This email and all data transmitted with it contai= ns confidential and/or proprietary information intended solely for the use = of individual(s) authorized to receive it. If you are not an intended and a= uthorized recipient you are hereby notified of any use, disclosure, copying= or distribution of the information included in this transmission is prohib= ited and may be unlawful. Please immediately notify the sender by replying = to this email and then delete it from your system.

=
--00000000000026426f05c830ab83-- From nobody Wed Jul 28 08:39:12 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA483A157F for ; Wed, 28 Jul 2021 08:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvdwCKoZOizQ for ; Wed, 28 Jul 2021 08:39:05 -0700 (PDT) Received: from aye.elm.relay.mailchannels.net (aye.elm.relay.mailchannels.net [23.83.212.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30A43A157E for ; Wed, 28 Jul 2021 08:39:04 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id DD066481BBE; Wed, 28 Jul 2021 15:39:00 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (100-96-13-112.trex-nlb.outbound.svc.cluster.local [100.96.13.112]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id E6683481AF5; Wed, 28 Jul 2021 15:38:59 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.13.112 (trex/6.3.3); Wed, 28 Jul 2021 15:39:00 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Coil-Share: 53e37536255f40aa_1627486740557_2168379123 X-MC-Loop-Signature: 1627486740557:231773788 X-MC-Ingress-Time: 1627486740557 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id D786C110F421; Wed, 28 Jul 2021 15:38:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1627486739; bh=P5ccsxeN41Mi2AojLhX7lUqTKWmUj519q31zDQBAhpo=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=Wq37NEkbyAswQ83a1URXV8MQLALPGRmZNdcuuUIAtIpiSnOedUUTRr7FychGgu3Q1 2bilp8JzrtT0xQKMOZDEaZunaziyOetEfa2cFSSGHNnsloGni/E5v5MaNH6YSDL//I X+7O9oeZLuTtVKbC/iWUus7zrPmQjW6C1m7d1/C6fTfPqRRXm1vWoA1adX32xPV8o2 YXm/rYCaLm30yBc3TuVXA6c/Q0ift5KTFyOGVwcxQSKq/DAfgbmkduHx5FjFG4gyCz +Bg0dOVrs0ASidXXCZg27F4KBhED7XW9d8EbNXvXzhkhzpaNrHg7iBvVr36SsRgfxj Ij1oxnj8KDasw== Reply-To: dcrocker@bbiw.net To: Ned Freed Cc: Alexey Melnikov , emailcore@ietf.org References: <0c7be232-a39c-480a-c194-1bd7168935d1@dcrocker.net> <01S1W7I5ISU4005PTU@mauve.mrochek.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <97a70e4a-e821-5385-7cf7-971a38318fc6@dcrocker.net> Date: Wed, 28 Jul 2021 08:38:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <01S1W7I5ISU4005PTU@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 #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, 28 Jul 2021 15:39:10 -0000 On 7/27/2021 10:39 AM, Ned Freed wrote: > >> Given the work of maintaining a registry -- and that risk of it getting >> out of sync with the normative specifications -- I'd suggest that the >> expected utility needs to be /very/ high. > > This makes no sense to me. The registry exists and is being maintained, so > that's a sunk cost. Adding a column to it seems to me to a minimal > cost addtion. > > What am I missing here? It takes effort to get all of the actors who are involved in creating and maintaining those entries to get all of the information into the registry correctly. The core information, such as name, authority agent, and specification citation, is part of every registry and therefore part of everyone's understanding of what to do. The current topic is about information that isn't ingrained, even among subject matter experts. I suggest that that will make it more likely to be handled inconsistently. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jul 28 08:57:07 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E93C3A1599 for ; Wed, 28 Jul 2021 08:57:05 -0700 (PDT) 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuSrTHYJv4oS for ; Wed, 28 Jul 2021 08:57:00 -0700 (PDT) Received: from bumble.maple.relay.mailchannels.net (bumble.maple.relay.mailchannels.net [23.83.214.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E053A158F for ; Wed, 28 Jul 2021 08:56:59 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 21DBD481DCC; Wed, 28 Jul 2021 15:56:58 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (100-96-16-95.trex.outbound.svc.cluster.local [100.96.16.95]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 812DB4817F5; Wed, 28 Jul 2021 15:56:56 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (197.15.184.35.bc.googleusercontent.com [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.16.95 (trex/6.3.3); Wed, 28 Jul 2021 15:56:57 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Duck-Bubble: 4b263d0b65f7f445_1627487817866_1706658950 X-MC-Loop-Signature: 1627487817866:3409110265 X-MC-Ingress-Time: 1627487817866 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id A42A1110F423; Wed, 28 Jul 2021 15:56:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1627487815; bh=H90EoeyOUT1T/6f2j8XbOrBh/xzO+wlZs/nWCIT5FrE=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=XP5z37TSsR4Wdz7vz7G5I5zGFtPw1Jpb4riajP67Xo08JoKhyYTdsBN3Mo3YcLPWr 9LP84gYVriafmOdZxAuySuR3zkPVgr5EgwN14Cy/ESlnHcRS0pNTPIBaUUa55CuuYC M2BK49rn+ti7wRPmyEavZrfW3JEv1+NctiNFFzm9tDXLuxy+2POl9gcscs5Ef5oL2m UQUfmTur0xmoHYWHGfGy5l1H9R6AZNaYqljPmyoGsZMT/jlqlMMP3YIlTrvnWyYiuy pf/iv2j9m/VM2SpOqRgh68tgE4s/x+JdHKelXwTwU7gQA4FSlcMDU6kBNZChHGvQ01 WkSFdDoJaYRyg== Reply-To: dcrocker@bbiw.net To: Alexey Melnikov , emailcore@ietf.org References: <0c7be232-a39c-480a-c194-1bd7168935d1@dcrocker.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <4c8ce63e-c88a-0a18-582e-469ccbb37dcb@dcrocker.net> Date: Wed, 28 Jul 2021 08:56:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.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: Wed, 28 Jul 2021 15:57:05 -0000 On 7/28/2021 7:16 AM, Alexey Melnikov wrote: > On 26/07/2021 17:18, Dave Crocker wrote: ... >> Technical specifications or Applicability Statements, or the like, >> will contain the normative information about acceptable use of a >> header field.  Providing such information in a registry will, >> therefore, be redundant.  (Possibly adding the risk of divergence, >> over time.) > > One of the main purposes of the proposed registry is to be able to find > a specific RFC that defines a particular header field. So the advice of > "just find the RFC" is not particularly helpful, considering how many > there are now. Alexey, I don't recall hearing anyone say anything like 'just find the RFC', so I'm not sure what you are referencing. In the meeting discussion, I noted that I'd neglected to include the specification citation in the list of information that goes with the registry entry. The /specific/ specification citation. On reviewing my above "Technical specification or..." paragraph, above, I think I was not at all clear enough. Attempting to fix that: Technical specifications or Applicability statements, or the like contain the relevant technical detail, including normative language. A registry needs to point to such documents but should not replicate details from them. Replication of details invites divergence. > Also, the registry will contain header fields not necessarily defined in > an RFC (e.g. header fields already in use in the wild), which would > serve a useful purpose. The choice of whether to allow registration entries that do not have a citable specification is obviously a strategic choice. Since a main function of registration is to avoid collisions, there an argument for being permissive. But the absence of a specification means that it won't be possible for folk to easily find out what the registered entry is used for; that's an argument for being more demanding. For something like header-fields, the namespace is essentially infinite. So my own preference is to require /some/ specification, but not be very demanding about the process for producing it. > I don't think I agree about the risk of divergence: we will populate the > registry once for known header fields and then future RFCs will just > update the registry. Right. We don't have any issue with redundant details between RFC821 and RFC822, or their successors. My concern about divergence isn't really all that unusual. My own lesson from 821/822, and similar examples, is to specify normative information in one place and everywhere else to just cite it (albeit somethings offering a terse bit of prose to summarize, but in a way that can't be taken as normative.) > As our community will know about existence of this > new registry, I don't think it will be likely that RFC authors will > forget to update it. "Our community" is large and diverse and often doesn't know about details others consider important. Hanging around an industry email trade association is educational, for seeing what technical information people in the industry do and do not have. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jul 28 11:27:44 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EFC3A1B28 for ; Wed, 28 Jul 2021 11:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 C7PknoXAYvIR for ; Wed, 28 Jul 2021 11:27:37 -0700 (PDT) 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 F325F3A1B19 for ; Wed, 28 Jul 2021 11:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1627496850; bh=+3OLP8q4/RFfhzMx26TsZAF2SQM9O3PP/SaUcWXyBuU=; l=910; h=To:References:From:Date:In-Reply-To; b=CVeH/qFQQU5dg0ldVjJL5APOhx8mqOHusigByCBQ0+kkck8Zz/kelEfQQXAW+IJas AHDpyZ6ItZ7L8+/gnjU6kFWfoC2xY/c8UB65HVXF4dh6iH1muHRlDNr2yqqJx/IJJJ Rtp5vJ+ZWEoUEweh0wuC5fg3lJlnJPfCPN1VmZMxLtOyMCaOeiiaXVB6PjjBL 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 00000000005DC03D.000000006101A192.000003DB; Wed, 28 Jul 2021 20:27:30 +0200 To: emailcore@ietf.org References: From: Alessandro Vesely Message-ID: Date: Wed, 28 Jul 2021 20:27:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.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] Closing Ticket #14 (G.7.8 Review Different Size Limits) 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, 28 Jul 2021 18:27:42 -0000 On Wed 28/Jul/2021 17:30:23 +0200 Todd Herr wrote: > Greetings. > > I heard during the IETF 111 emailcore session on July 27 that consensus here > was that there was no need to change the text that specifies various size > limits in sections 4.5.3.1.[1-8]. > > Therefore, I will be closing the ticket on July 30 unless objections are raised. It is fine to close the ticket, AFAICU. Let me recall Ned's note about the preceding sentence To the maximum extent possible, implementation techniques that impose no limits on the length of these objects should be used. That text should be changed to read something like "To a reasonable extent", since striving to impose no limit would make the server vulnerable to resource exhaustion attacks. That's not part of the ticket, though. See https://mailarchive.ietf.org/arch/msg/emailcore/2C7XAnTCpBWdq22dTrGVP_m3j0A Best Ale -- From nobody Wed Jul 28 12:39:48 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBE23A1D84 for ; Wed, 28 Jul 2021 12:39:29 -0700 (PDT) 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 iWQJ4LPu3IyA for ; Wed, 28 Jul 2021 12:39:25 -0700 (PDT) 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 428FC3A1D4E for ; Wed, 28 Jul 2021 12:39:25 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1XPBIJ0W000JO2W@mauve.mrochek.com> for emailcore@ietf.org; Wed, 28 Jul 2021 12:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1627500860; bh=kMOq9MEN5WhHb96EdOUYFurpwr/Im1dc4ytWVtsAri4=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=dLYXFTMPxQeRFZ1N1lNs/5wAmRZmFdlecAgunYYUiLmNFCkHLWIQrOV6OvNkmrHxp VvasgPkRYIYA7cm+T9/LiXGjqfhrz18hMrbwWhAbjKO2r6WyV6dQcpU/tANOPneCkx blEUItB11IxYxSD9LpOToX2Vr290Z0HJUP6aTFMA= 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 <01S1LCO8JIDC005PTU@mauve.mrochek.com>; Wed, 28 Jul 2021 12:34:17 -0700 (PDT) Cc: Ned Freed , emailcore@ietf.org, Dave Crocker Message-id: <01S1XPBG14PS005PTU@mauve.mrochek.com> Date: Wed, 28 Jul 2021 12:16:49 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 28 Jul 2021 15:35:57 +0100" <5e9a9217-177c-987f-a506-41c4aeb80538@isode.com> References: <0c7be232-a39c-480a-c194-1bd7168935d1@dcrocker.net> <01S1W7I5ISU4005PTU@mauve.mrochek.com> <5e9a9217-177c-987f-a506-41c4aeb80538@isode.com> To: Alexey Melnikov 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, 28 Jul 2021 19:39:38 -0000 > Hi Ned, > On 27/07/2021 18:39, Ned Freed wrote: > >> On 11/16/2020 9:10 AM, Alexey Melnikov wrote: > >> > Based on an earlier discussion on the mailing it looks like there is > >> > consensus to create (or possible ammend an existing) registry for > >> header > >> > fields with extra information about which types of SMTP agents are > >> > allowed to add them in transit or before final delivery. > > > >> Taking John Levine's pointed challenge on this issue, I went back to > >> this start-of-thread message and now find myself also questioning what > >> the benefit of this effort will be. > > > > I did so as well, and I see a lot of problems I didn't see before. > You were the original person who motivated creation of this ticket  10 > months ago :-): That's ... amusing. > ---------------------- > Ned Freed wrote: > There are many fields that get added after submission and before final > delivery. And not all of them really qualify as "trace" IMO. > Moreover, making a list of these fields is a hopeless task, since all > it takes is one more document to outdate the list. > I see two possible solutions: > (1) Craft some text saying something like, "Only add fields specified as OK > to be added in other specifications." > (2) Create a registry. > I kind of like the idea of a registry, but it is a fair bit more work. > ---------------------- > > > > For starters, I'm confused by the use of the term "subregistry". This seems to > > me to come down to an update to RFC 3864 to add a column where people > > can indicate where in email architecture they expect this field to be > > added. > No, this is not what I meant. I meant it would be listed on the same > page as registered permanent/provisional header fields. But even that is > not required, if people don't think this is a good idea. OK, I now understand your proposal. But I still think having one list is much better than having a separate list. Why not simply annotate the existing list with the points at which it makes sense to introduce the header field? > And no, definitely not suggesting any changes to RFC 3864, as it is also > used by HTTP and Usenet, as having extra columns that only apply to > email would be very confusing to other users of the registry. I believe that's what "n/a" is for. But OK, if you really think that having mail-only field is too confusing to people viewing the page, then the way to address that is to have one central list behind it all and generate as many views of it as you like on the page. Having to submit to two registries grots up the process considerably for anyone wanting to register a header. And given the complaints we're getting about how hard it is to register stuff, I really think the focus needs to be on keeping that process as simple as possible. > Anyway, let's change "subregistry" to "registry". Except it *is* a sugregistry. Changing the name doesn't change that. > > If that's the case, then I don't understand what this has to do with > > SMTP and > > thus why it has any business being in RFC 5321bis. Our architecture > > covers more > > than SMTP, and this is true even if you expand the scope to cover > > SUBMIT and LMTP. > > If anything this belongs in RFC 5322bis. > That would be Ok with me personally. > > If you think about things this way I think most of the issues about > > MSA/MDA/MUA/MfooA disappear. The columns is a means of indicating the > > point in the architecture where it makes sense for it to be added. > > Nothing > > more. How this corresponds to actual implementations, which we all know > > map the architectural elements to software components in complex and > > fairly arbitrary ways, is essentially irrelevant. > Ok, so are you suggesting some changes to how columns are named? Or > their removal altogether? Can you please clarify. No, I am suggesting keeping them the same, and making it clear that we're referring to the point in the architecture the addition is supposed to be done, not where it happens to appear in any particular implementation. And while there may - or may not - be issues with the architecture document that are worth looking at, I don't think they rise to the level where citing the basic architectural components of email is problematic. Ned From nobody Wed Jul 28 20:14:03 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D5D3A125E for ; Wed, 28 Jul 2021 20:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Mr3idYti; dkim=pass (2048-bit key) header.d=taugh.com header.b=l6fRQUZs 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 SeM5-nNkn20I for ; Wed, 28 Jul 2021 20:13:56 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBEFA3A1256 for ; Wed, 28 Jul 2021 20:13:55 -0700 (PDT) Received: (qmail 33878 invoked from network); 29 Jul 2021 03:13:53 -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=8454.61021cf1.k2107; bh=SNo/FGj2AjdRDAuA0+jxT8dyUonTjL/JoXEKkAvWMgk=; b=Mr3idYtie65bwIVLTgLdPhQNOBfM1zPxzCjWvQgEcGViY0H2W8iCq4oO2iHiwRT6xa1DL7h3xrGpVBH4DD0RmSyaS5M47hZSjpNYvsgCCzs6OOr/NoCbLVlFO84yrYeqBQl9rkT1oJo5FH9+J0lQr0zwqgsaE2lwhb5i1vbg2FY4T3kT1L53VGOgRx69+vmnbYcNyV8VSyVi9+v0kD022C3WdOZSzpxx5HHVINMyLvIPqTsmI4ayqXDBkGQt/VQqEYnzunnWntZfMoDCqoDakqF+SlduDestonkoid97bX2VEpt2VXaDj5qZ/jan54uUf5Kx+YfhwJS6vyHaza/n4w== 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=8454.61021cf1.k2107; bh=SNo/FGj2AjdRDAuA0+jxT8dyUonTjL/JoXEKkAvWMgk=; b=l6fRQUZsHxYvFwScoOfjlc8UKc4srsQY/M9U6y4Kx3sDx+i9WAC0FO0EBT/vsoYbdham3qRFL80EsdGJjid8QJ/uN8NZ2ZQ+HS97HJLdpjzJU/frggL0z0ZqLR/jLboLdSbovVp+PzeF24uwhDDXc43ukXZf1bYBRfM9F3erzeP74Uh4p+/ScTGOggtT9pj0CluqefdquKc1ZreV1rNvQVIZ9+j2QNDBOhKaQGpR41iQNglJfKAMF/f4zxSQW71TiZ4TNOU+fKrs2BztsmN7Uivwy4ycmGcZ9akDeO8Fe5nRHf80L2is9Nl9ReGZuAzYLjRRAjUAzjxdRfe4dCuQ1A== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 29 Jul 2021 03:13:53 -0000 Received: by ary.qy (Postfix, from userid 501) id DE5F725480DE; Wed, 28 Jul 2021 23:13:52 -0400 (EDT) Date: 28 Jul 2021 23:13:52 -0400 Message-Id: <20210729031352.DE5F725480DE@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: alexey.melnikov@isode.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #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: Thu, 29 Jul 2021 03:14:01 -0000 It appears that Alexey Melnikov said: >One of the main purposes of the proposed registry is to be able to find >a specific RFC that defines a particular header field. So the advice of >"just find the RFC" is not particularly helpful, considering how many >there are now. When I look at this registry I see a list of header fields and the RFC or other reference that defines each one: https://www.iana.org/assignments/message-headers/message-headers.xhtml How would this be different? I can sort of see adding a column to the existing registry with a hint about where in the mail process it's typically added, but not a whole new registry. R's, John From nobody Wed Jul 28 21:09:09 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7800B3A091F for ; Wed, 28 Jul 2021 21:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U31B1zl95fk for ; Wed, 28 Jul 2021 21:09:02 -0700 (PDT) Received: from purple.birch.relay.mailchannels.net (purple.birch.relay.mailchannels.net [23.83.209.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712293A091C for ; Wed, 28 Jul 2021 21:09:02 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 34E325A07C3; Thu, 29 Jul 2021 04:09:01 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (100-101-162-69.trex.outbound.svc.cluster.local [100.101.162.69]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 4673F5A0C36; Thu, 29 Jul 2021 04:09:00 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (35.45.192.35.bc.googleusercontent.com [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.101.162.69 (trex/6.3.3); Thu, 29 Jul 2021 04:09:00 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Skirt-Whistle: 7e73aeaf4215deca_1627531740743_559502224 X-MC-Loop-Signature: 1627531740743:2801130478 X-MC-Ingress-Time: 1627531740742 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 5071E31364B4; Thu, 29 Jul 2021 04:08:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1627531739; bh=nq60guyMo57P+pfKZCYrAk0WtEx4pBwyGz5Zkk4/Bss=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=THrcP66BPFnbuo/ZfOKAscLWJ/bbVcYD9k6Ofk46E4CfrlGKGiz+xOgA2f9OSvBQx rAsaqph3lkqDcQ9t1E6FHaBm09O3EetgYsla4nmQ6RgSpN5Xh8p318L8vh6nthxC6T IFIYk5JgjjLWpeP9o+w1suOaNF4tLLVP8u2tNor0vwRgDQYCo2NzpjYkkPNqqDEWV1 9sBiRwip8xDrNpBC3ioW+ZFeTHb7/61redTpwP44OHu0LzxE55L0ydZXNbHf6jP5Xg z9P/JgGIbVC/174xq2ADkWN23KtqWGtcif5EKR95an6FoEcaKA27d/yGj0u9Xgt57s F5cl7SDgOJ/8g== Reply-To: dcrocker@bbiw.net To: John Levine , emailcore@ietf.org Cc: alexey.melnikov@isode.com References: <20210729031352.DE5F725480DE@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Wed, 28 Jul 2021 21:08:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <20210729031352.DE5F725480DE@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Thu, 29 Jul 2021 04:09:08 -0000 On 7/28/2021 8:13 PM, John Levine wrote: > I can sort of see adding a column to the existing registry with a hint > about where in the mail process it's typically added, but not a whole new registry. A 'hint'? 1. Chosen by whom and through what process? Note that that makes it additional work and potentially another source of controversy. 2. It will be taken as normative Because that's what people do when they see entries like this, in places like this. 3. It is an attempt to make a 'registry' be a kind of partial tutorial. To do a useful job takes surrounding text. Typically quite a bit. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jul 28 21:12:49 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412803A0962 for ; Wed, 28 Jul 2021 21:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=itaoyama.onmicrosoft.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 W13HNpy0Goky for ; Wed, 28 Jul 2021 21:12:43 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410107.outbound.protection.outlook.com [40.107.141.107]) (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 A066E3A095C for ; Wed, 28 Jul 2021 21:12:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NPF/SHgWYIROu68sD0MRuzQg4/uT1vLA4q0KCs1G9vQ1+S+VYtWoxhp1jv+OX3iv4Hvdcd0VXS8ztcakwOaYuaw7Wrp4duMcHO3r8IGeKe4+Y2h5inJh9MGWUBr1pV+2mjk5/tjJmHrr5xwYAnAV5ZrgLmWwty7STVgeKtLdXkQCvuxo7+XzGbzOanta9KqGYY7Wb1ZhViiByMWMKCgJ5rbKplsAW/xzslX7iS9cAPYWeC5nUeRKT93539u/okVw8rlGbDcjXRs6N8MhsY8QTYqd1rD5K5Lprp25FnbZatZ+frS47gS6Fcq6xyxBOLlxusLwBXoLZiaWI/E30zs7pA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LQhhnlUsN8M7Ylrm+s1IVSehcO3d/ah1mmVHSnLBZV8=; b=R+aoiiQGyWCF5C7V4/hLb1e45JXeFMQPC1nq5AvPG/y6rgfxgxfmnDO4wsZexf7/skFZ6benXYas7TfOulas4FAeaG/0cMRFiVhlF9lFC5nLhyx/zsnIa8aQJ65J3V89U2a5m8wgQxy/rFlodrnU1rGvaJcVVWkUXGrN1DwMRGqoRdYIG31Y7b8PcCeuj4t6QKq1GgVdt8/l8am8iHrMOVK8N+6xTHlbm9C0XJMWABG8AJ0ztGE9XqyHN8PE05FT2+ZyYOYv/u0SOwDMKtrfI54khutINiY+HXcSVnnY3HC4V6VnZTz2YsTF8mR8m/W9hxSyfc7xpe5VXtvLACrMQg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LQhhnlUsN8M7Ylrm+s1IVSehcO3d/ah1mmVHSnLBZV8=; b=Bcp5rR4QdldJq3Gj6iLT88bX9QriEh7RXDN2m5ONhqQ+CCqDTjp0wL9nlw7q7D+62RXGnyLlj45lSCEQCWeWD0aP93Vgqe3x4o4YK1PYQyAz83O2+wgjTmJs7PPObsvxwCzqskH4PCu0C2qTKJxb2l01bV8KAkqEPuuCzS50p4g= Authentication-Results: isode.com; dkim=none (message not signed) header.d=none;isode.com; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYCPR01MB6961.jpnprd01.prod.outlook.com (2603:1096:400:b8::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.28; Thu, 29 Jul 2021 04:12:40 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::11f6:52bc:8bf7:d82b]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::11f6:52bc:8bf7:d82b%6]) with mapi id 15.20.4352.032; Thu, 29 Jul 2021 04:12:40 +0000 To: John Levine , emailcore@ietf.org Cc: alexey.melnikov@isode.com References: <20210729031352.DE5F725480DE@ary.qy> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <32ffe1ec-f123-f37e-37ba-797617dcc31c@it.aoyama.ac.jp> Date: Thu, 29 Jul 2021 13:12:37 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 In-Reply-To: <20210729031352.DE5F725480DE@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TY2PR02CA0014.apcprd02.prod.outlook.com (2603:1096:404:56::26) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [133.2.210.39] (133.2.210.39) by TY2PR02CA0014.apcprd02.prod.outlook.com (2603:1096:404:56::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.17 via Frontend Transport; Thu, 29 Jul 2021 04:12:40 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f44080ae-435a-4cd5-ce27-08d952471b4b X-MS-TrafficTypeDiagnostic: TYCPR01MB6961: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: RZh8UpcQFeEeT6V130LvBzV3xQ+Z4PQhl3hzAhvjnZAKRzzr1z0NEYROCzfr9s9luiquHf3ATz6kv478xWZ0buPdF+ANUcoggDnBfVXawc/7+DHtQQXsPt9wXJ8PbmVKEkiEiXuMw51LeFu0c1dIDQfRxfQXigbhnwbH6bLc8SM2PTni8GDECFUCTEHRqJ8aZM+gjDG9goIHQXpKrRsAVva5vnNRWBhdFDc/ltRnjV0nps+pRGWSof4+WIvyU4BmA5wl3neuqyaw6EDaQGMZSNeDXQtV5uWFmZubg73/9gu4pdrkaKdWPYbT5OJ/q0jHqd2lHqDbmO8ZQSbYpvW3DQyObZcv7N0mdmRvrFHSdAjAvigz31KxNMN13274XOR3tjzEQKExr+XGDT1EPZVrRRhBTtpgl8QoYPcNyL17Mq86NBbUnixD9Deeka/KIEO5Ae+TarQBx7HMgBnWQfTVUCD1JNgeQySuZZ5rFQ3YD1gzOH1PPLXkgRNaU/ngdJJJ0Gr3Dk17Pta6aVsPe0Tz0ankJdoFLzlT09rZJw7Fz3o9eL97ADcaryR9ZEsSN8LuEpLU3MRTBE06L8WTPfT+YavbV7qRk9QhJBn9qqsXeBVuYu7T+TK2SYHdtJVkz29MZI2WgCEG0HL8QG2Nsv8QjFUCYzC3NAO2US9pcFN+tNh3Le7uV14A9BgiY/OIOkR41W2aSWGMkMnlAZJXlrUBwykbX5vc7mfNxkecJd+8ZiozHT2MIMjZshM2uqM++ayn759MwCrqq2xCJ+ykwBLgAeWAdVaDsz7Dfc0FzEqbdYk8LOrqCugSStzL5cEsImexK5igRcdEXBCCSlf855b6hlFVMO9YdC0Tah5fNA9dp08= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(136003)(39840400004)(376002)(396003)(31686004)(786003)(8936002)(16576012)(66946007)(6486002)(6666004)(66556008)(316002)(36916002)(38100700002)(2616005)(52116002)(38350700002)(8676002)(86362001)(31696002)(83380400001)(66476007)(956004)(6706004)(53546011)(186003)(5660300002)(966005)(508600001)(2906002)(26005)(4326008)(4744005)(3940600001)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?djQ1SWJTeFhidlI1SG1IMHNwUGpZelQ2RVppcWllaDZhZ05pVkErczRiQ05O?= =?utf-8?B?SmhUNnh6R1dFVXA4eENJZGw3ei85MitXMnVwSjNibVNDelhUYUVmOVVOcVRK?= =?utf-8?B?RnhRY1lHSkhrbFFFWWN6YzdjNDdza1NYa1ZBd3p6VGxIN2UwQVI2WElmTitp?= =?utf-8?B?VG5nNWhDZDZibHRiZC9FUlN1TkxxWlYweGpFUGtNWHVwV0IyN01wZ1VEdjZs?= =?utf-8?B?eTE0T1JjSzlUeG1yUWxUa0Q2QTE5YWx4RjZOUXI1WEVPWXpnN1o4Mm8xZDFn?= =?utf-8?B?aFpJYThtb0VvckRqZlJBcG13djZuNmxmWkZBcTF2bGpYYmRnNUhKTjRDMG0w?= =?utf-8?B?ZGlnaHFvbUZzUDFxMnJkTS91elhRaDZtKzN5ZDFPdUM5cWNubStCditnS3BG?= =?utf-8?B?UFlvek5yVVJEcXEvcjdoTHJTTjVVZzlIODFvblhtNHFGR3dQVFlNbkJBMXAr?= =?utf-8?B?eVBjcnVPbmtabWJLREtqOWFWYnZNYmdSc2x5azZxQmF6dHlLT0FGajU1anBh?= =?utf-8?B?MkJKZkI5dkVCODdtQkZNN2g0RUlHYTFDNFNxWm5qMG9TK3E4TXF0MmhPZ0E2?= =?utf-8?B?L2tFZDZBeGxsSTVSdnk4WEd0UUZFR1EwYmJJcGdaZWVQcjFpOFBVOVl3M2kw?= =?utf-8?B?OHl4Tld0UlZodndQM29MUUhDbmwydHJKbnZtWFZHWnMwYURUelY2WFV6UFNu?= =?utf-8?B?dVlDMTh4STlaZDl3VkcwcE53Qm9qdnhWUU1OQjlEbDQ1YVhkczRrR3prSzNu?= =?utf-8?B?TUhjY1hIS3RuRDdVeG5Nd0Jpa3h4a1RaLytQSjhKc0ZvVUc1bTBsN3RJNjB4?= =?utf-8?B?KzJSb012KzZUcjlWTjkwOW1nUjB5RFhlQ2N0bGtqaWd5d1EwbFJIZnRrRDlk?= =?utf-8?B?bTJFTGhQd2xmWUk4NlJsT0dTMDJtdnIxbVhUbWdZVFRMckRSaytsQW5yTHdz?= =?utf-8?B?dXJPU3Y0ZXdGY0JDVmg3cEg5RGtmcWpRbVlaRm1ob09hRkxDQUdsWERxNzFP?= =?utf-8?B?WFpzRU5rRFNrME1xek9iWGRNNWVTUlI5UE9WSFUrTU5Wdk96SlJCOU9mTExu?= =?utf-8?B?TEJlaTF2Qm1YNUx5S3NwYk9HME1NYnRSVmh2RjRpL1dHQjJ6VlozMzgxcVc2?= =?utf-8?B?ck1nNGFVWXkxeDd3RDBOUWNYR2k1SGsvTTdUNmdHY0l3MnhVcDN1YzdCWGh6?= =?utf-8?B?ZFpLQi9GcldBUE54WlIxU1F5QSt6ME5VaXNqd002S1NvUk5mNUcyQ0FRbE9s?= =?utf-8?B?VHBobEdhVnc5a1FGNlZRMGdMMFBBUm93M0F6RS92Uk0vemdNVnVLY3djTjA0?= =?utf-8?B?YWNyUUpTbDluWldIaDBnaDVDQy9GZk5sNnB1TlJEL1BZTnNxTzZ6dVpEQk9V?= =?utf-8?B?OTVJTGgvMHY5SGFUbjMxYlRjWCttNmFPdXFKcUs0Z2xxQ1JHb2pRT3lxTzNx?= =?utf-8?B?dE9mTWxzOXFhUUczcmN5VjJNL0dRYzFMWFoyK0xmU1RyUnVSeGo3SW11ZnFH?= =?utf-8?B?eDIzTVVjaUsrMVlGMnQxU3pKY1BjZDNEYmhoelliRks3WGlDUTlTMi9TTXo0?= =?utf-8?B?bTgrV29peUVadVZCbHRMOGRTeTZYdm9ma2NNa2h0djZodEhORlZhMVdKcGYv?= =?utf-8?B?bDFQMkwrSlZZMXo0ZjJjdHlvYjRBeHE0ZU1hNGcwTkFWdDI1eHlNYVQrZVlV?= =?utf-8?B?MTVIQm9jc2ZjL3R0ak9wWE9uZU9DWjI0WXR3UVpldHBrMFJQd3RiVFVhNXl6?= =?utf-8?Q?FcGbv2i/ViGKrqlcTkyrFGFtxLBhjrXE3EI8Nd8?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: f44080ae-435a-4cd5-ce27-08d952471b4b X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2021 04:12:40.5287 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Yz7f97NToN4W0YQNCQdX7MabD5nu66+Z6YoNyazqTspi3shzsEt9vxELBx3jjdWcOfo6epSd9B3fnHxZY15zgg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCPR01MB6961 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: Thu, 29 Jul 2021 04:12:48 -0000 On 2021-07-29 12:13, John Levine wrote: > When I look at this registry I see a list of header fields and the RFC or > other reference that defines each one: > > https://www.iana.org/assignments/message-headers/message-headers.xhtml > > How would this be different? > > I can sort of see adding a column to the existing registry with a hint > about where in the mail process it's typically added, but not a whole new registry. Same here. Another variant would be to allow a fixed range of additions to the protocol column. I.e. not just "mail", but e.g. "mail (gateways)" or whatever we may decide on. Regards,   Martin. > R's, > John > From nobody Thu Jul 29 07:27:30 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDC53A2481 for ; Thu, 29 Jul 2021 07:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 hd3_99JBPeQl for ; Thu, 29 Jul 2021 07:27:23 -0700 (PDT) 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 BF7BF3A247E for ; Thu, 29 Jul 2021 07:27:23 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1YSPYYT2800IX5C@mauve.mrochek.com> for emailcore@ietf.org; Thu, 29 Jul 2021 07:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1627568538; bh=twKvk4//+gTDOw4FSSIo5JML2ypKM5ouWk3ZXJOeN4c=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=GjiIm3m2zCppatnEhj8VelUK5MyOZZ2sbK3GXY9o6VXJrIuDaorYQT2BAe7YOh280 k0/kUwUiPktxrQubsa0NAmozUVVIkhE06nhI8/QUH34DVMuRMa9OEG4mdtt9IUvRuB 6vVrS4lvsGP2sTq1uISBI1NtK1+sWA6mU7334NiI= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S1LCO8JIDC005PTU@mauve.mrochek.com>; Thu, 29 Jul 2021 07:22:15 -0700 (PDT) Cc: John Levine , emailcore@ietf.org, alexey.melnikov@isode.com Message-id: <01S1YSPX83H2005PTU@mauve.mrochek.com> Date: Thu, 29 Jul 2021 07:10:26 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 28 Jul 2021 21:08:56 -0700" References: <20210729031352.DE5F725480DE@ary.qy> To: Dave Crocker 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: Thu, 29 Jul 2021 14:27:28 -0000 > On 7/28/2021 8:13 PM, John Levine wrote: > > I can sort of see adding a column to the existing registry with a hint > > about where in the mail process it's typically added, but not a whole new registry. > A 'hint'? The file extension in the media types registry is just a hint, but even so it's quite useful. > 1. Chosen by whom and through what process? The usual process of adding entries to the registry. This would simply be an optional item on the registation form. > Note that that makes it additional work and potentially another > source of controversy. Really? You actually believe that it's possible to write a clear and cogent specification for the syntax and semantics for a new email header and yet not know the places where it can be introduced into the mail system? And in the unlikely event this does happen, perhaps in this case it would be good for the specification to explain why it's unclear. > 2. It will be taken as normative > Because that's what people do when they see entries like this, in > places like this. Decades of experience with various registries says this is not the case. Like it or not, the "selective inattention" force mediated by the "doesn't apply to me" boson tends to overpower almost everything. And as far as I can tell we have yet to detect the "normative" force you meantion. > 3. It is an attempt to make a 'registry' be a kind of partial tutorial. > To do a useful job takes surrounding text. Typically quite a bit. Again, I don't see how you can properly specify a header field without talking about it's relationship to the email architecture. So yes, actual text is required to do this properly. But providing a indication of this in the registry doesn't change this one bit. Ned