From nobody Mon Mar 8 08:32: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 89D303A0EA4 for ; Mon, 8 Mar 2021 08:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 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_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 (2048-bit key) header.d=fastmail.fm header.b=L7dI3fjD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tZyxE00u Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0xbAwY1oZxM for ; Mon, 8 Mar 2021 08:32:18 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED5DD3A0E8E for ; Mon, 8 Mar 2021 08:32:18 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id DD61B23D3; Mon, 8 Mar 2021 11:32:17 -0500 (EST) Received: from imap37 ([10.202.2.87]) by compute1.internal (MEProxy); Mon, 08 Mar 2021 11:32:18 -0500 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:cc :subject:content-type:content-transfer-encoding; s=fm2; bh=cAZ8w e4jywmdu1A2LZ9uMGCnBsNar+3s3HikUNdH3YA=; b=L7dI3fjDQPU/ZnicSw2k+ /d6PN7bYr+FX+DRv63Y6MaNpIYILQNdwFyOi5HChpoqe017XRi1rerFT9zM5G/ff 7QJxmWO3Av0VQiCTOArTIw8XjkqeGVL2zC5gCFttwYNRGQbhBDiY7cS86KZsb7U/ h9P31KLrIRdxaABa4BUz6l8DS03DUSPN4Q8QY+Jwt3K+ovKswHJQjpQVg+QOZU5d cw/mJZ7fdxAE+8gq3Mj4PGbCt6myPUbY8SasjRP9TOvPzRm+oTJwtPNn14vgMC+7 VdFmBDumYxThIL8oILchojzqzEO/P1Xr0TwIPXdVOAM2cYw9friqllgRsakMcggM Q== 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=fm2; bh=cAZ8we4jywmdu1A2LZ9uMGCnBsNar+3s3HikUNdH3 YA=; b=tZyxE00u4knAfYAqFmzWLc1J+5ynwPHGAAGlUy0H0KGXG300fckjlw7No SAELNpDMWCIe/xf+URnb7hQvafFbbhXqnlqncnYinBP/61Ku/M36mFlwgRgBRkUX bNCq8NMORCAr09l9q+LeWd1UZi3sEKKQAoZfI7WdoEKkNy2WHQMHSOPhZT94DgcT VLZdTg2HPuZ+cQCNOHbc7bywOKEMk6QsJOuYLwf4DWsQ70pSel5PEMUY2o1hflMB MJdpdF9SDTxMJk/y/X0Cx25l3Z7sGwxTwCmgwdzaRPltnYa4uJmkmm55dTQIpUjr Ph2mvtRjqYnN0plIWPfOnZfpyHdQg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddugedgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedftehl vgigvgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhmqeenucggtffrrghtthgvrhhnpeelieffleeuueefkeeljeefieehgeejtddvtddu ffeufeevveeftdefkeeuudevffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C5AC16B4005F; Mon, 8 Mar 2021 11:32:16 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd Mime-Version: 1.0 Message-Id: <1680ae68-e4cd-41c8-a97d-33334eb8a821@www.fastmail.com> In-Reply-To: <01RW2JPR8LJK005PTU@mauve.mrochek.com> References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> <646E1956-600F-47D8-8F9D-4BAA423F9FF6@episteme.net> <47853c9a-fa32-ddf5-7347-4b1fd7af7638@tana.it> <01RW2JPR8LJK005PTU@mauve.mrochek.com> Date: Mon, 08 Mar 2021 16:31:33 +0000 From: "Alexey Melnikov" To: "Ned Freed" , "Pete Resnick" Cc: emailcore@ietf.org, "Alessandro Vesely" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 16:32:26 -0000 On Sat, Feb 27, 2021, at 4:48 PM, Ned Freed wrote: > > On 23 Feb 2021, at 12:58, Alessandro Vesely wrote: >=20 > > > On Tue 23/Feb/2021 18:34:39 +0100 Pete Resnick wrote: > > > > > >> On 23 Feb 2021, at 5:39, Alessandro Vesely wrote: > > >> > > >>> That ABNF seems to imply there must be at least one Received:.=C2= =A0 Why > > >>> then does the table in Section 3.6 show a Min number of 0 trace?= > > >> > > >> Because the entire trace block is optional according to the ABNF > > >> right above that table in 3.6. > > > > > > Ugh, that way you cannot have a lone Return-Path:? >=20 > > No. Is there a reason to ever have one? >=20 > I can think of at least two: >=20 > (1) IMAP APPEND of a (possibly draft) message (thus no Received: field= s) where > you want to say what the MAIL FROM was/is/should be. >=20 > (2) Message has had all Received: fields removed for security reasons.= (And > please don't bother telling me this is a bad idea, because you'd b= e > barking up the wrong tree. A large number of security reviewers sa= y > otherwise, and when the choice is between no Received: fields and > no deployment, guess what wins.) Right, this needs fixing in the ABNF. Does this affect proposed ABNF in = 3.6.7 or ABNF in 3.5? =20 > > >> But optional-field is permitted at the bottom of the ABNF of fiel= ds > > >> in 3.6, which would allow it to be used for something that is not= a > > >> trace field. (That is, optional-field appears twice in the 3.6 > > >> syntax.) > > > > > > optional-field is a poor choice, as it is restricted to header fie= lds > > > not specified in the I-D. That includes fields specified in other= > > > RFCs as well as unspecified fields. > > > > > > Consider RFC 5293, where the *addheader* Sieve action is described= > > > like so: > > > > > > By default, the header field is inserted at the beginning of th= e > > > existing message header. If the optional flag ":last" is > > > specified, > > > it is appended at the end. >=20 > > So you're saying that you want it to be syntactically OK (that is, i= n > > the ABNF) to add one of the non-trace fields at the top of the messa= ge? > > There's already a discussion of this at the beginning of 3.6 saying,= "It > > is important to note that the header fields are not guaranteed to be= in > > a particular order." I'd really rather not change the syntax any mor= e > > that strictly necessary. >=20 > > >>> The practice to collect trace fields at the top comes from the f= act > > >>> that it is convenient to write down one's 2 cents and then copy = the > > >>> rest without even parsing it. >=20 > > Indeed, not just convenient, but that it's often been damaging to go= > > mucking around in the contents of the message. 5321 talks about this= . >=20 > True, but let's keep in mind that RFC 5321 is about message transport,= and > RFC 5322 applies more broadly. User agents muck around with the conten= t > of messages all the time. It's kind of what they are for... Agreed. Best Regards, Alexey From nobody Mon Mar 8 08:37:01 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 BA6BF3A0F02 for ; Mon, 8 Mar 2021 08:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTYFCnogJ2p6 for ; Mon, 8 Mar 2021 08:36:53 -0800 (PST) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 761473A0E8D for ; Mon, 8 Mar 2021 08:36:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 5D28DD9F5A49; Mon, 8 Mar 2021 10:36:50 -0600 (CST) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71-s7-oWWdqR; Mon, 8 Mar 2021 10:36:47 -0600 (CST) Received: from [172.16.1.16] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 464ABD9F5A3B; Mon, 8 Mar 2021 10:36:47 -0600 (CST) From: Pete Resnick To: Alexey Melnikov Cc: Ned Freed , emailcore@ietf.org, Alessandro Vesely Date: Mon, 08 Mar 2021 10:36:46 -0600 X-Mailer: MailMate (1.14r5769) Message-ID: In-Reply-To: <1680ae68-e4cd-41c8-a97d-33334eb8a821@www.fastmail.com> References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> <646E1956-600F-47D8-8F9D-4BAA423F9FF6@episteme.net> <47853c9a-fa32-ddf5-7347-4b1fd7af7638@tana.it> <01RW2JPR8LJK005PTU@mauve.mrochek.com> <1680ae68-e4cd-41c8-a97d-33334eb8a821@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 16:37:00 -0000 On 8 Mar 2021, at 10:31, Alexey Melnikov wrote: > On Sat, Feb 27, 2021, at 4:48 PM, Ned Freed wrote: >>> On 23 Feb 2021, at 12:58, Alessandro Vesely wrote: >> >>>> Ugh, that way you cannot have a lone Return-Path:? >> >>> No. Is there a reason to ever have one? >> >> I can think of at least two: >> >> (1) IMAP APPEND of a (possibly draft) message (thus no Received: >> fields) where >> you want to say what the MAIL FROM was/is/should be. >> >> (2) Message has had all Received: fields removed for security >> reasons. (And >> please don't bother telling me this is a bad idea, because you'd >> be >> barking up the wrong tree. A large number of security reviewers >> say >> otherwise, and when the choice is between no Received: fields and >> no deployment, guess what wins.) > > Right, this needs fixing in the ABNF. Does this affect proposed ABNF > in 3.6.7 or ABNF in 3.5? It affects both, but it's changing the ABNF in 3.5 that is making me a bit nervous. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Mon Mar 8 08:39: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 D268D3A0E9B for ; Mon, 8 Mar 2021 08:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 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_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 (2048-bit key) header.d=fastmail.fm header.b=RkwY4+5s; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FGBtjxR7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcLZO1j8MZdM for ; Mon, 8 Mar 2021 08:39:48 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975D13A0E8E for ; Mon, 8 Mar 2021 08:39:48 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id B6E212724; Mon, 8 Mar 2021 11:39:47 -0500 (EST) Received: from imap37 ([10.202.2.87]) by compute1.internal (MEProxy); Mon, 08 Mar 2021 11:39:48 -0500 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:cc :subject:content-type; s=fm2; bh=pkOJUEA4QvVydb9gHKOxnLH26dtZpAz DCt4MMNltWjE=; b=RkwY4+5sohW+BUHLKjYypJlc1lF1KK3D/ETAZEswFCCwROa b8tt+nQljBCed5SwM3nj4CMKEnDxLJIEuMSb+JM/YMIg8sWUWfQRMTTD67BUHD51 CxSynMmg3HQ5QHxfJZXpXJYFI5NUG67TseECXi4KVx/I1UvMUKPMI/RrZ2QJjLPH CDOj2y1O5L5bHop4xdD++ul8/cGhH2V0otpjn9OuwkW0jwVxbo7q12lgci1hMaCT 9lHblC3a5382EHpYNAjW1xneB0cdzM5bbsCwCsznFicOqEWc/obQojT1rJ7gLH84 Ie3IByWIKiBmr8kDkLHGroNqKTglNCOm7wB5eXQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=pkOJUE A4QvVydb9gHKOxnLH26dtZpAzDCt4MMNltWjE=; b=FGBtjxR7YUhCPcKYQq1nwn KiOWZbYIGLCZ3gaFp1HJI+1I0fQh4Dsg8OaOgtxOdktiYBFAneUvpRT9Be66Ulv7 rAH/5mns124+sR60YhcISKD2dPhfX8Aobe4FpA7SUZnxMKrAV/+dQZHKDuoHPg/4 gSj2VYbPU41wm3d7Ifs4PmLEikjGWpXrM6ZCeD1tRI3jGVoHtbetzt/5itv3tgvu 2LVn9oVC6WD0KPH+Qs4ciE2ZaKn+Rx78KSe3kh4wJgycV+EMnjb5Vp7DdZOtkfsL Mv7eAzfMfHpPI/2ud7XQdkSH0B/R2uj/UzfHRvfO40xSAPFUsbuNZzcl8jbdTCtA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddugedgvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuggftrfgrthhtvghrnhepfeevteekfeefteetgedtgefhieegieetgefhkeei gfduhffgjedvuddukeejfeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 722546B4005F; Mon, 8 Mar 2021 11:39:46 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd Mime-Version: 1.0 Message-Id: <92272040-fd9d-4d24-a726-a97416c9aea0@www.fastmail.com> In-Reply-To: References: <20210222194226.890486E7C605@ary.qy> <4C73D7F9-ABDB-4288-8312-73A72E1EE608@episteme.net> <646E1956-600F-47D8-8F9D-4BAA423F9FF6@episteme.net> <47853c9a-fa32-ddf5-7347-4b1fd7af7638@tana.it> <01RW2JPR8LJK005PTU@mauve.mrochek.com> <1680ae68-e4cd-41c8-a97d-33334eb8a821@www.fastmail.com> Date: Mon, 08 Mar 2021 16:39:01 +0000 From: "Alexey Melnikov" To: "Pete Resnick" Cc: "Ned Freed" , emailcore@ietf.org, "Alessandro Vesely" Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition for trace header fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 16:39:50 -0000 On Mon, Mar 8, 2021, at 4:36 PM, Pete Resnick wrote: > On 8 Mar 2021, at 10:31, Alexey Melnikov wrote: > > > On Sat, Feb 27, 2021, at 4:48 PM, Ned Freed wrote: > >>> On 23 Feb 2021, at 12:58, Alessandro Vesely wrote: > >> > >>>> Ugh, that way you cannot have a lone Return-Path:? > >> > >>> No. Is there a reason to ever have one? > >> > >> I can think of at least two: > >> > >> (1) IMAP APPEND of a (possibly draft) message (thus no Received: > >> fields) where > >> you want to say what the MAIL FROM was/is/should be. > >> > >> (2) Message has had all Received: fields removed for security > >> reasons. (And > >> please don't bother telling me this is a bad idea, because you'd > >> be > >> barking up the wrong tree. A large number of security reviewers > >> say > >> otherwise, and when the choice is between no Received: fields and > >> no deployment, guess what wins.) > > > > Right, this needs fixing in the ABNF. Does this affect proposed ABNF > > in 3.6.7 or ABNF in 3.5? > > It affects both, but it's changing the ABNF in 3.5 that is making me a > bit nervous. Ok, thanks. (Should have been 3.6 above). From nobody Mon Mar 8 13:40: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 D9D6B3A17D9 for ; Mon, 8 Mar 2021 13:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 Eprhb42CBTyb for ; Mon, 8 Mar 2021 13:40:36 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 C59E03A1792 for ; Mon, 8 Mar 2021 13:40:36 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id h26so4370405qtm.5 for ; Mon, 08 Mar 2021 13:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=gn9W+y0GCSjeZid9qfkYN4fUTGed72fIsIdJ/QjYj5w=; b=c4CHId5aCdhCb/cl1Ej/cP8hh6Fgg9rogGZwti36/4jp8HW5dvNxKjavsYRxZU3zkX uYBC13KP9iH5ox0GdwAuzyJUK+/ONXqG05D3PkSxMgOJpa/3ZHOBG59QKew9SSQ66XDi JiMk/cS56mvgzkgMQW5tkmJrXDsU4ARwOwO/lRPFSxz0bXhnIDAN7KHOi7X8dVr4IJut Psp/0IUqBqfyXX4EGeVhUgI+8PJzDSi4evt2Z1OSX7aWHyRpSfmHemwplLT7hKwGThPT VBrxm0i2BxaX31zH6V8YIgG6FXcjYNtBdwH0u5BZ7dcQfpuRB/Ago0rUowkf1yiNRHBf L4DA== 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; bh=gn9W+y0GCSjeZid9qfkYN4fUTGed72fIsIdJ/QjYj5w=; b=TWMTjF7jv3CpjF9NcHV4jAU3vvCMmZJ/qeIUSTkpSpv4UALItbw6ybO+MimUjCCfON XcavSPBiz42dl59vmL2HXc8568mneNqqZNydNykayXTEIxdPr51AoebMzCKtpiZnvVMc PFyxPpeLkixvjkT5IgVKYj3Tga1mqY6b/H46VeJgz8018YkiJAJ5yh1s2Pu11s7Yf8Ll 7TGK8lPAuBku1fXUs/u/3MTREYbR64tvUysBpta45HTbXb8AE5kCgVZaJ8U9dNBe8uhe XoTpOtHMvn0iUFsgla/G3c009LF0P1SD6fB0waFoLQ9y1RyfvunwSFsRFZ2oHMyyH1mi v4UQ== X-Gm-Message-State: AOAM531AmqgzHZ/qaf/PtiE3bInBM1JroB+5f3yHje+w1Csf3UZ6khaT hDaqx5H9jTTLuA6BpXNpUvjPlvcK0V+U0PFXo9rzcTHNkms= X-Google-Smtp-Source: ABdhPJzaJ6maJ6xgHfafu45nI7JNn9tdJ79IoTjQM5sUcqsjrW5ItyPeOCW3cP80u1g5J6WZyivzcWbTLgds2Ovn1+8= X-Received: by 2002:ac8:4b7b:: with SMTP id g27mr3647249qts.220.1615239635116; Mon, 08 Mar 2021 13:40:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Todd Herr Date: Mon, 8 Mar 2021 16:40:19 -0500 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000adba0b05bd0d4859" Archived-At: Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 08 Mar 2021 21:40:39 -0000 --000000000000adba0b05bd0d4859 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 16, 2021 at 8:19 AM Todd Herr wrote: > On Mon, Feb 15, 2021 at 8:42 AM Alexey Melnikov > wrote: > >> Hi, >> >> On Tue, Jan 19, 2021, at 4:24 PM, Alexey Melnikov wrote: >> > Hi all, >> > >> > The first pagaraph of Section 4.5.3.1.10 (Too Many Recipients Code) >> > currently says: >> > >> > RFC 821 [3] incorrectly listed the error where an SMTP server >> > exhausts its implementation limit on the number of RCPT commands >> > ("too many recipients") as having reply code 552. The correct reply >> > code for this condition is 452. Clients SHOULD treat a 552 code in >> > this case as a temporary, rather than permanent, failure so the >> logic >> > below works. >> > >> > John noted that this suggestion may have outlived its usefulness >> > and/or be inconsistent with current practice. Should it be removed >> > and/or explicitly deprecated? >> >> I did a bit of digging and it doesn't look like Sendmail emits 552 or >> treats it as 442 if received from other MTA. >> Postfix code has this commented out with a note that this workaround >> creates more problems than it solves, due to other meaning of 552. >> >> Do people have information about other MTAs (not necessarily open source) >> on this topic? >> >> > I've reached out to a few large mailbox providers and a couple of > commercial MTA vendors on this question. Still collecting answers, but hope > to post results here by the end of the week. > Long delayed and incomplete results from an informal survey of a few providers and commercial MTA vendors (all of whom I've suggested should make their presence known here..) Google: Emits 452, treats 552 as permanent failure Microsoft: Emits 550, treats 552 as permanent failure (probably) Proofpoint MTA: No default configuration for too many recipients, so emits whatever admin wants; treats 552 as permanent failure. If I receive any more information, I'll post it. -- *Todd Herr* | Sr. Technical Program Manager *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. --000000000000adba0b05bd0d4859 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 16, 2021 at 8:19 AM Todd Herr <todd.herr@valimail.com> wrote:
=
On Mon, = Feb 15, 2021 at 8:42 AM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
Hi,

On Tue, Jan 19, 2021, at 4:24 PM, Alexey Melnikov wrote:
> Hi all,
>
> The first pagaraph of Section 4.5.3.1.10 (Too Many Recipients Code) > currently says:
>
>=C2=A0 =C2=A0=C2=A0 RFC 821 [3] incorrectly listed the error where an S= MTP server
>=C2=A0 =C2=A0=C2=A0 exhausts its implementation limit on the number of = RCPT commands
>=C2=A0 =C2=A0=C2=A0 ("too many recipients") as having reply c= ode 552.=C2=A0 The correct reply
>=C2=A0 =C2=A0=C2=A0 code for this condition is 452.=C2=A0 Clients SHOUL= D treat a 552 code in
>=C2=A0 =C2=A0=C2=A0 this case as a temporary, rather than permanent, fa= ilure so the logic
>=C2=A0 =C2=A0=C2=A0 below works.
>
> John noted that this suggestion may have outlived its usefulness
> and/or be inconsistent with current practice. Should it be removed
> and/or explicitly deprecated?

I did a bit of digging and it doesn't look like Sendmail emits 552 or t= reats it as 442 if received from other MTA.
Postfix code has this commented out with a note that this workaround create= s more problems than it solves, due to other meaning of 552.

Do people have information about other MTAs (not necessarily open source) o= n this topic?


I've reached out to a few large mailbox providers and a couple of com= mercial MTA vendors on this question. Still collecting answers, but hope to= post results here by the end of the week.

Long delayed and incomplete results from an informal survey of a few= providers and commercial MTA vendors (all of whom I've suggested shoul= d make their presence known here..)

Google: Emits 452, treats 552 as per= manent failure
Microsoft: Emits 550, treats 552 as permanent failure (probab= ly)
Proofpoint MTA: No default configuration for too many recipients, so emi= ts whatever admin wants; treats 552 as permanent failure.

If I receive= any more information, I'll post it.

--
<= div dir=3D"ltr" class=3D"gmail_signature">

Todd Herr | = Sr. Technical Program Manager
e:<= span style=3D"vertical-align:baseline"> 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 recip= ient you are hereby notified of any use, disclosure, copying or distributio= n of the information included in this transmission is prohibited and may be= unlawful. Please immediately notify the sender by replying to this email a= nd then delete it from your system.

--000000000000adba0b05bd0d4859-- From nobody Tue Mar 9 13:34: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 8927B3A0DD4 for ; Tue, 9 Mar 2021 13:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmRU7z8xCWM6 for ; Tue, 9 Mar 2021 13:34:48 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3973A0DAC for ; Tue, 9 Mar 2021 13:34:48 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lJk07-000IBk-6F for emailcore@ietf.org; Tue, 09 Mar 2021 16:34:47 -0500 Date: Tue, 09 Mar 2021 16:34:40 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: <86B11D00B74F9DA068CB3724@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] Ticket #5, rfc5321bis Section 4.5.3.1.10, and G.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, 09 Mar 2021 21:34:50 -0000 Hi. This is about the "Too Many Recipients Code" transition described in earlier versions of SMTP and the question of whether the transition text should be removed from 5321bis. The more I think about this, the more I wonder about whether 821 was right in the first place. Assuming the current spec, including that minimum of 100 recipients, was actually followed (see below) and the sender comes in with its 101st RCPT command. If the server comes back with 452, which is shown in the list in Section 4.2.2 as "insufficient storage" and with the implication of all 4yz codes of "try again". If the sender tries again with the same recipient list and gets the same response -- especially if the server uses the "insufficient system storage" message in the spec without a supplemental code -- we are getting close to Einstein's definition of insanity. The presumably correct response from the sender would be to cut the number of recipients and try again, but the 452 response gives no hint of that, nor any way to distinguish what should have been "45x Requested action not taken: too many recipients, will not accept more than NN" from "452 Requested action not taken: insufficient system storage". And, before someone else points it out, telling the sender the maximum both violates the general principle of 5321 and its predecessors that the response text does not carry substantive information except for a small number of specific exceptions -- a principle that is violated by documenting both "too many recipients" and "insufficient storage" for 452 -- and may make things more efficient for an attacker. This is further complicated if we consider lowering the requirement for the minimum number of recipients a server is expected to accept (now 100) as suggested on list and (vaguely) covered in Ticket #14, Section G.7.8. I'm not sure if this is a serious suggestion but, if we retain the 452 code, do we need should we have an new code (borrowing an analogy from interpretations of "666"), e.g., 566 You tried that more times, with the same parameters and address list, than I will tolerate, please go straight to an appropriate hot place and stay there Probably not a serious suggestion, at least in that form, but you get the point. And, of course, if we made any change at all in this area, would anyone pay any attention to it? john From nobody Wed Mar 10 00:06: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 2DE473A1D49 for ; Wed, 10 Mar 2021 00:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCcMn3ZIBWme for ; Wed, 10 Mar 2021 00:06:49 -0800 (PST) Received: from rorschach.hjp.at (mail.hjp.at [212.17.106.138]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058323A1D4A for ; Wed, 10 Mar 2021 00:06:48 -0800 (PST) Received: by rorschach.hjp.at (Postfix, from userid 1000) id E0F904670; Wed, 10 Mar 2021 09:06:45 +0100 (CET) Date: Wed, 10 Mar 2021 09:06:45 +0100 From: "Peter J. Holzer" To: emailcore@ietf.org Message-ID: <20210310080645.GA2318@hjp.at> References: <86B11D00B74F9DA068CB3724@PSB> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <86B11D00B74F9DA068CB3724@PSB> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Emailcore] Ticket #5, rfc5321bis Section 4.5.3.1.10, and G.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: Wed, 10 Mar 2021 08:06:52 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-03-09 16:34:40 -0500, John C Klensin wrote: > This is about the "Too Many Recipients Code" transition > described in earlier versions of SMTP and the question of > whether the transition text should be removed from 5321bis. >=20 > The more I think about this, the more I wonder about whether 821 > was right in the first place. Assuming the current spec, > including that minimum of 100 recipients, was actually followed > (see below) and the sender comes in with its 101st RCPT command. > If the server comes back with 452, which is shown in the list in > Section 4.2.2 as "insufficient storage" and with the implication > of all 4yz codes of "try again". If the sender tries again with > the same recipient list and gets the same response -- especially > if the server uses the "insufficient system storage" message in > the spec without a supplemental code -- we are getting close to > Einstein's definition of insanity. That's not how senders handle this case in my (admittedly limited) experience. > The presumably correct response from the sender would be to cut the > number of recipients and try again, I'm not sure that 'cut' is the right word to describe current (and I think correct) behaviour. For illustrative purposes I'll assume that the receiving MTA has a limit of 3 instead of 100. The sender tries to send a message to 8 recipients. [EHLO, etc.] MAIL FROM: 250 OK RCPT TO: 250 OK RCPT TO: 250 OK RCPT TO: 250 OK RCPT TO: 452 OK # The limit is now exceeded, the # receiver starts sending 452 replies RCPT TO: 452 OK RCPT TO: 452 OK RCPT TO: 452 OK RCPT TO: 452 OK DATA # The sender knows that the message will # be delivered to 3 recpipients, so it # sends the content 354 Start mail input; end with . Blah blah blah... =2E 250 OK QUIT 221 At this point, the message has been delivered to 3 recipients, but not yet to the remaining 5. The sender doesn't really know why those got temporary errors, nor does it care. It just requeues the message with those 5 recpients and retries some time later: [EHLO, etc.] MAIL FROM: 250 OK RCPT TO: 250 OK RCPT TO: 250 OK RCPT TO: 250 OK RCPT TO: 452 OK RCPT TO: 452 OK DATA 354 Start mail input; end with . Blah blah blah... =2E 250 OK QUIT 221 Two recpients still left, requeue, wait and try again: [EHLO, etc.] MAIL FROM: 250 OK RCPT TO: 250 OK RCPT TO: 250 OK DATA 354 Start mail input; end with . Blah blah blah... =2E 250 OK QUIT 221 Done. > I'm not sure if this is a serious suggestion but, if we retain > the 452 code, do we need should we have an new code (borrowing > an analogy from interpretations of "666"), e.g., >=20 > 566 You tried that more times, with the same parameters > and address list, than I will tolerate, please go > straight to an appropriate hot place and stay there As I understand the RFC (and obviously implementors of SMTP clients as well), each response to a RCPT command pertains only to that recipient. So after getting a mixture of 2xx and 4xx responses a sender would not retry with the same address list. Some addresses have already been successful, so they aren't tried again. (Similary, if there were also some 5xx responses, those addresses won't be tried again, either.) Maybe that should be stated explicitely somewhere (if it isn't already), but that's how I always understood the RFC. hp --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --/04w6evG8XlLl3ft Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmBIfhAACgkQ8g5IURL+ KF1dHw/9EZTWT+hXxEk20p1W8o7arcDCfclQdVgx9hGXjnV32bciNRwaD18wvNrZ JwPff3WJlXIfxlhAEjzf0Lpfza3lE/Hc2n9u3oGgCEkOem/CcVG9afuO2jLT0g6I JKBzqfdDWwqkvcE+hhqG873WzPhWCt+m5NLUf3a4J68nwlZSOQRMI1R5tLec1mUA 88IkSPcA60KPmweCq7p8SC08Gl+QT/ceDZ2vW6iw17HfpfLPAlnb2pvxxifXAJAa udQGYwg6aqduKRM6gwQV4sbTKcwclxlkiML1WYRfAidge23SXuPpLlSyJ+yoa6CP X3V6dBBCguf+jE0A5bgmE7ejjmMthla6j5/jqws3DOAJ1cBSzcsrZgjiXoTa622Z kHVbjsIRCPLQpUPO2MstAhITKkSL8SMZYRarazUbkZwJTdmDbJiNCl8cDJTMd8wX TvqHtLlMQDNHWn3W6J4VS33QLq6DjJSNKXFzeKtptLDUfd+//dxuMK3oCePKd9B9 2q015GzM0q0DleM9xf2LIIAR/wh2SETeYoMbfSoNSYxdQG949wDrLPSe2fr8r5Wh eVyyYoadnhgzCefRu/y+CXUF/bR5ZmzCKWpNTnYjTCj74UbRJUvumbizZyFVs0c5 D+FN6zDXGBpt7qkMwtPYizeZvqJj/7ET+F4OqfT+7k6xN9sQhZo= =vMl+ -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From nobody Wed Mar 10 00:46: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 1B0BC3A1F5D for ; Wed, 10 Mar 2021 00:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnn8YbwdUGiI for ; Wed, 10 Mar 2021 00:46:31 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA513A1F5B for ; Wed, 10 Mar 2021 00:46:31 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RWHFREK1JK00F7TF@mauve.mrochek.com> for emailcore@ietf.org; Wed, 10 Mar 2021 00:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1615365933; bh=CoByZhja+2H6yJorifh2PFPthbyYxzWdzYfplvFBOEM=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=bzsV2+yMdFjwRAp2L9LTowLnbUaF9GK+2NcTiHNN9NQVgHZpwmYNfgvOTu3hRSRvD EoSPNmqz5qx8ME4n0XsDrWEhoRFslPz7sqCfGptnT+MX12OF2sueu2lenVd6p0yVTP MwJaqme2TRcvmr5pGaPfGits3mkGfgOh00B0ZhwM= 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 <01RWDMX50OQ8005PTU@mauve.mrochek.com>; Wed, 10 Mar 2021 00:45:31 -0800 (PST) Cc: emailcore@ietf.org Message-id: <01RWHFRDA4MG005PTU@mauve.mrochek.com> Date: Wed, 10 Mar 2021 00:17:05 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 10 Mar 2021 09:06:45 +0100" <20210310080645.GA2318@hjp.at> References: <86B11D00B74F9DA068CB3724@PSB> <20210310080645.GA2318@hjp.at> To: "Peter J. Holzer" Archived-At: Subject: Re: [Emailcore] Ticket #5, rfc5321bis Section 4.5.3.1.10, and G.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: Wed, 10 Mar 2021 08:46:33 -0000 > On 2021-03-09 16:34:40 -0500, John C Klensin wrote: > > This is about the "Too Many Recipients Code" transition > > described in earlier versions of SMTP and the question of > > whether the transition text should be removed from 5321bis. > > The more I think about this, the more I wonder about whether 821 > > was right in the first place. Assuming the current spec, > > including that minimum of 100 recipients, was actually followed > > (see below) and the sender comes in with its 101st RCPT command. > > If the server comes back with 452, which is shown in the list in > > Section 4.2.2 as "insufficient storage" Yes, but there is no other code in that list that seems appropriate for "Too many recipients". > > and with the implication of all 4yz codes of "try again". The meaning of a 4YZ repsonse to RCPT TO is more subtle. (I don't put much stock in interpreting the second and third digits.) It could be any of: (1) A problem resolving this specific recipient, (2) An administrative limit has been reached, or (3) An actual storage limit has been hit. > > If the sender tries again with > > the same recipient list and gets the same response -- especially > > if the server uses the "insufficient system storage" message in > > the spec without a supplemental code -- we are getting close to > > Einstein's definition of insanity. Not necessarily. Transient problems do go away. LDAP servers come back up. > That's not how senders handle this case in my (admittedly limited) > experience. > > The presumably correct response from the sender would be to cut the > > number of recipients and try again, > I'm not sure that 'cut' is the right word to describe current (and I > think correct) behaviour. > For illustrative purposes I'll assume that the receiving MTA has a limit > of 3 instead of 100. The sender tries to send a message to 8 recipients. > [EHLO, etc.] > MAIL FROM: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 452 OK # The limit is now exceeded, the > # receiver starts sending 452 replies > RCPT TO: > 452 OK > RCPT TO: > 452 OK > RCPT TO: > 452 OK > RCPT TO: > 452 OK > DATA # The sender knows that the message will > # be delivered to 3 recpipients, so it > # sends the content > 354 Start mail input; end with . > Blah blah blah... > . > 250 OK > QUIT > 221 > At this point, the message has been delivered to 3 recipients, but not > yet to the remaining 5. The sender doesn't really know why those got > temporary errors, nor does it care. It just requeues the message with > those 5 recpients and retries some time later: > [EHLO, etc.] > MAIL FROM: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 452 OK > RCPT TO: > 452 OK > DATA > 354 Start mail input; end with . > Blah blah blah... > . > 250 OK > QUIT > 221 > Two recpients still left, requeue, wait and try again: > [EHLO, etc.] > MAIL FROM: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 250 OK > DATA > 354 Start mail input; end with . > Blah blah blah... > . > 250 OK > QUIT > 221 > Done. My experience agrees with yours - this is how things work almost all of the time. There is, however, another possibility: [EHLO, etc.] MAIL FROM: 250 OK RCPT TO: 250 OK RCPT TO: 250 OK RCPT TO: 250 OK RCPT TO: 452 Too many recipients # The limit is now exceeded, the # receiver starts sending 452 replies RCPT TO: 452 Too many recipients RCPT TO: 452 Too many recipients RCPT TO: 452 Too many recipients RCPT TO: 452 Too many recipients DATA # The sender assumes the 3 good recipients # will work, but... 452 Recipient limit exceeded, try again with fewer recipients True storage limit errors are rare given the capacity of modern systems; the more likely cause here is a badly implemented administrative limit. And in such a case repeating the same transaction is unlikely to ever work. So what we do in this case is requeue as multiple messages so that we won't get to the point of receiving 452s responses to RCPT TO the next time. Now, I freely admit we're going to a lot of trouble to deal with what is arguably a broken server, but (a) It turned out to be easy to implement and (b) There was a point were a fairly popular server was doing this often enough to make it worthwhile. I also note that the message "Too many recipients" is ambiguous as to cause. > > I'm not sure if this is a serious suggestion but, if we retain > > the 452 code, do we need should we have an new code (borrowing > > an analogy from interpretations of "666"), e.g., > > > > 566 You tried that more times, with the same parameters > > and address list, than I will tolerate, please go > > straight to an appropriate hot place and stay there > As I understand the RFC (and obviously implementors of SMTP clients as > well), each response to a RCPT command pertains only to that recipient. Exactly. > So after getting a mixture of 2xx and 4xx responses a sender would not > retry with the same address list. Some addresses have already been > successful, so they aren't tried again. (Similary, if there were also > some 5xx responses, those addresses won't be tried again, either.) > Maybe that should be stated explicitely somewhere (if it isn't already), > but that's how I always understood the RFC. Me too. I also think that removing permitted code/response pairs is a really bad idea. Of course it's wrong for clients to be overly restrictive in the code combinations they allow, but given that there are widely used implementations that do this (I'm looking at you, JavaMail) removing things is IMO a really bad idea. Ned From nobody Wed Mar 10 04:35:37 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 F347F3A0890 for ; Wed, 10 Mar 2021 04:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.253 X-Spam-Level: X-Spam-Status: No, score=-6.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTrvR-fgPcWa for ; Wed, 10 Mar 2021 04:35:33 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3D93A0884 for ; Wed, 10 Mar 2021 04:35:32 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 08A745C00DE for ; Wed, 10 Mar 2021 07:35:31 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 10 Mar 2021 07:35:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:reply-to:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=6JoIn+gTj+I9BufmX aX48pCUSbsK6d2NAIoAoQAzr+M=; b=qYnQN5E3fmDy6qN1zdInV0bqFZfYUMT7g q/xWwIRDbD/M97uKWCyspN6h90NMs+RR5aMH61YewLg9kPdUwUWMAUPd/2yxrszH Uxtub1IHqezoAN5wbBqh9byquFTLwebt2byU+PA95QANB5is/89n/NxI5IzyQi2b 5PSHHddq7jvBCiHoYMzOwX10H7EMVJLA9Vtfh8Ejl/QX02NO8nyP4dnJo6drL/c/ OqvqHPbSLYnGi9hN9Boag8+I51Y7fDPS6dR3TG5j4DAxM+OpF3HTC+joVFcUX5rf rFux4GxC23FXZApQFuNxvEZ8z/1RhERt7hPP1ITTs9PfxGSL0vsDw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddukedggedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefvrhfhufhokffffgggtgesrgdtre ertdefjeenucfhrhhomhepffgrvhgvucevrhhotghkvghruceoughhtgesuggtrhhotghk vghrrdhnvghtqeenucggtffrrghtthgvrhhnpeeuleeiveefkeduvdffjeduveeghfejve etffeifedtgedvhfegheehudeifffgleenucffohhmrghinhepsggsihifrdhnvghtnecu kfhppedutdekrddvvdeirdduiedvrdeifeenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpeguhhgtsegutghrohgtkhgvrhdrnhgvth X-ME-Proxy: Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 6AE3F1080066 for ; Wed, 10 Mar 2021 07:35:29 -0500 (EST) To: emailcore@ietf.org Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Wed, 10 Mar 2021 04:35:27 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8595343756F05D51808512C0" Content-Language: en-US Archived-At: Subject: [Emailcore] Document dependencies X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 10 Mar 2021 12:35:35 -0000 This is a multi-part message in MIME format. --------------8595343756F05D51808512C0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit To get what I posted to the session chat, into the wg list archive: Stray thought:  SMTP cannot be used without 5322. However the 5322 object /has/ been used without SMTP. Making 5322bis depend on SMTP changes this. When 5322bis makes a reference to 5321bis, the message object has been made to depend on SMTP, although there is plenty of history of having the object carried by other protocols. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------8595343756F05D51808512C0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

To get what I posted to the session chat, into the wg list archive:

Stray thought:  SMTP cannot be used without 5322. However the 5322 object /has/ been used without SMTP. Making 5322bis depend on SMTP changes this.

When 5322bis makes a reference to 5321bis, the message object has been made to depend on SMTP, although there is plenty of history of having the object carried by other protocols.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------8595343756F05D51808512C0-- From nobody Wed Mar 10 05:14: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 DDBE93A0BDA for ; Wed, 10 Mar 2021 05:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JoMew7zSiHz for ; Wed, 10 Mar 2021 05:14:18 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9353A0BD5 for ; Wed, 10 Mar 2021 05:14:18 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 692525C0129 for ; Wed, 10 Mar 2021 08:14:17 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 10 Mar 2021 08:14:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:reply-to:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=nsio8hswfro+wbFuKnGtxcXUIOAcfbOIzE4rn8gow+M=; b=hYTxpZei fjZMfRRpJ8DyhXd3G0YyadPuZkm1lmO4AwflRBIEU+JXe0GdJexWYYuY3FIwN6yf SJaDEAoTT1HSh96ohSAYv1mbKzW7xoeECJRhbzNS/5dgU2t1QrMYHAGPpazn5PT4 gMvUoNIwGm3JA7I799vNg+V+88L7S/W14w5ihzSyPtW5aV+N4OaZuzc5uSmTbsXr WaJ/bxzUPhdAVrMFC73ls7WMbMU8WnV2ZO1NCKKIJ5W+7Xv5J7KS4zjt+j2YsHvL 1nwfT39xL8OhyFzu+3aygepx6muIl2ezgc4066k+W1KwUGRD0M7wPopribisl8hG OlkaoSGpkxeS/A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddukedghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefvrhfhufhokffffgggtgfgsehtke ertddtfeejnecuhfhrohhmpeffrghvvgcuvehrohgtkhgvrhcuoeguhhgtsegutghrohgt khgvrhdrnhgvtheqnecuggftrfgrthhtvghrnhepfeeijeegveelffffueehudeftdeuvd ffffffjeekgeekgffghfdvledtfffghfeinecuffhomhgrihhnpegssghifidrnhgvthen ucfkphepuddtkedrvddviedrudeivddrieefnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepughhtgesuggtrhhotghkvghrrdhnvght X-ME-Proxy: Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 71CD91080054 for ; Wed, 10 Mar 2021 08:14:15 -0500 (EST) To: emailcore@ietf.org Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <3e7f0fb6-1bf7-1687-1b74-0af75cb6df78@dcrocker.net> Date: Wed, 10 Mar 2021 05:14:13 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Emailcore] Default yes / Default no X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 10 Mar 2021 13:14:20 -0000 If I understood Bron's question to me, during the session, it was of the general form "Are there problems that would be caused by doing this?" That is a Default Yes model of wg effort.  It's entirely appropriate, sometimes. But this wg has an intentionally /very/ narrow charter which I believe is thoughtfully designed to impose a Default No view towards changes. Changes ought to be restricted to compelling deficiencies in the protocol specification, where there are known operational effects. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Mar 10 05:27: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 8BC9A3A0C3B for ; Wed, 10 Mar 2021 05:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r_iIIl0nkT9 for ; Wed, 10 Mar 2021 05:27:13 -0800 (PST) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC923A0C38 for ; Wed, 10 Mar 2021 05:27:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id E2A25DA4ED75; Wed, 10 Mar 2021 07:27:09 -0600 (CST) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vl3MIXY81qlR; Wed, 10 Mar 2021 07:27:06 -0600 (CST) Received: from [172.16.1.16] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id B7552DA4ED6A; Wed, 10 Mar 2021 07:27:06 -0600 (CST) From: Pete Resnick To: dcrocker@bbiw.net Cc: emailcore@ietf.org Date: Wed, 10 Mar 2021 07:27:05 -0600 X-Mailer: MailMate (1.14r5769) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Document dependencies X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 10 Mar 2021 13:27:15 -0000 On 10 Mar 2021, at 6:35, Dave Crocker wrote: > To get what I posted to the session chat, into the wg list archive: > > Stray thought:  SMTP cannot be used without 5322. However the 5322 > object /has/ been used without SMTP. Making 5322bis depend on SMTP > changes this. > > When 5322bis makes a reference to 5321bis, the message object has been > made to depend on SMTP, although there is plenty of history of having > the object carried by other protocols. As far as I know, all of the references in 5322bis to 5321bis are non-normative, along the lines of "this document defines this very broadly, but other documents like 5321bis defines this much more narrowly, so you should probably go look at that." pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Wed Mar 10 10:29: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 6536A3A1534 for ; Wed, 10 Mar 2021 10:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRAHj8nPHI_l for ; Wed, 10 Mar 2021 10:29:22 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8A03A1532 for ; Wed, 10 Mar 2021 10:29:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1615400955; bh=tkfU8lwotaBaO+BZnzS6P6JvNElbaaTwCifdy++LxCw=; l=8088; h=To:References:From:Date:In-Reply-To; b=AsQHB35UtcLfJS/ZBx3tFo5ebxXv9KNQGM+CyC7iiz48LrSr2j4vryn41L4nJFEmZ vt7uUka5U+r+CN2WnksRQ+XrUfLOa6xtWKNEiwwisuQE9UMHe0r9VQFv8Wo+wJl9hd nq5xYdYPU5w7C/hhuaNHJ9efLvQafApXWMkRdTsII5Cc0KZIlEGKLHpAGpdEr 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 00000000005DC050.0000000060490FFA.00000574; Wed, 10 Mar 2021 19:29:14 +0100 To: Ned Freed , "Peter J. Holzer" , emailcore@ietf.org References: <86B11D00B74F9DA068CB3724@PSB> <20210310080645.GA2318@hjp.at> <01RWHFRDA4MG005PTU@mauve.mrochek.com> From: Alessandro Vesely Message-ID: Date: Wed, 10 Mar 2021 19:29:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <01RWHFRDA4MG005PTU@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #5, rfc5321bis Section 4.5.3.1.10, and G.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: Wed, 10 Mar 2021 18:29:24 -0000 On Wed 10/Mar/2021 09:17:05 +0100 Ned Freed wrote: >> On 2021-03-09 16:34:40 -0500, John C Klensin wrote: >>> This is about the "Too Many Recipients Code" transition >>> described in earlier versions of SMTP and the question of >>> whether the transition text should be removed from 5321bis. >>> >>> The more I think about this, the more I wonder about whether 821 >>> was right in the first place. Assuming the current spec, >>> including that minimum of 100 recipients, was actually followed >>> (see below) and the sender comes in with its 101st RCPT command. >>> If the server comes back with 452, which is shown in the list in >>> Section 4.2.2 as "insufficient storage" > > Yes, but there is no other code in that list that seems appropriate > for "Too many recipients". > >>> and with the implication of all 4yz codes of "try again". > > The meaning of a 4YZ repsonse to RCPT TO is more subtle. (I don't > put much stock in interpreting the second and third digits.) It could > be any of: > > (1) A problem resolving this specific recipient, > (2) An administrative limit has been reached, or > (3) An actual storage limit has been hit. 4yz can also be used to split the recipient list into a set that has DATA filtering enabled and one that has it disabled. A DATA filter can either accept or reject a message based on its content. In case it rejects, recipients who have disabled such filtering have to receive the message in a separate transaction. I'm not sure this case is part of (1) above. Let me also note that by checking the first digit only, 552 and 550 are treated in the same way. >>> If the sender tries again with >>> the same recipient list and gets the same response -- especially >>> if the server uses the "insufficient system storage" message in >>> the spec without a supplemental code -- we are getting close to >>> Einstein's definition of insanity. > > Not necessarily. Transient problems do go away. LDAP servers come back up. > >> That's not how senders handle this case in my (admittedly limited) >> experience. > >>> The presumably correct response from the sender would be to cut the >>> number of recipients and try again, > >> I'm not sure that 'cut' is the right word to describe current (and I >> think correct) behaviour. 'Split'? >> For illustrative purposes I'll assume that the receiving MTA has a limit >> of 3 instead of 100. The sender tries to send a message to 8 recipients. > >> [EHLO, etc.] >> MAIL FROM: >> 250 OK >> RCPT TO: >> 250 OK >> RCPT TO: >> 250 OK >> RCPT TO: >> 250 OK >> RCPT TO: >> 452 OK # The limit is now exceeded, the >> # receiver starts sending 452 replies >> RCPT TO: >> 452 OK >> RCPT TO: >> 452 OK >> RCPT TO: >> 452 OK >> RCPT TO: >> 452 OK >> DATA # The sender knows that the message will >> # be delivered to 3 recpipients, so it >> # sends the content >> 354 Start mail input; end with . >> Blah blah blah... >> . >> 250 OK >> QUIT >> 221 > >> At this point, the message has been delivered to 3 recipients, but not >> yet to the remaining 5. The sender doesn't really know why those got >> temporary errors, nor does it care. It just requeues the message with >> those 5 recpients and retries some time later: > >> [EHLO, etc.] >> MAIL FROM: >> 250 OK >> RCPT TO: >> 250 OK >> RCPT TO: >> 250 OK >> RCPT TO: >> 250 OK >> RCPT TO: >> 452 OK >> RCPT TO: >> 452 OK >> DATA >> 354 Start mail input; end with . >> Blah blah blah... >> . >> 250 OK >> QUIT >> 221 > >> Two recpients still left, requeue, wait and try again: > >> [EHLO, etc.] >> MAIL FROM: >> 250 OK >> RCPT TO: >> 250 OK >> RCPT TO: >> 250 OK >> DATA >> 354 Start mail input; end with . >> Blah blah blah... >> . >> 250 OK >> QUIT >> 221 > >> Done. > > My experience agrees with yours - this is how things work almost all of the > time. There is, however, another possibility: > > [EHLO, etc.] > MAIL FROM: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 452 Too many recipients # The limit is now exceeded, the > # receiver starts sending 452 replies > RCPT TO: > 452 Too many recipients > RCPT TO: > 452 Too many recipients > RCPT TO: > 452 Too many recipients > RCPT TO: > 452 Too many recipients > DATA # The sender assumes the 3 good recipients > # will work, but... > 452 Recipient limit exceeded, try again with fewer recipients > > True storage limit errors are rare given the capacity of modern systems; the > more likely cause here is a badly implemented administrative limit. And in such > a case repeating the same transaction is unlikely to ever work. So what we do > in this case is requeue as multiple messages so that we won't get to the point > of receiving 452s responses to RCPT TO the next time. Here the last digit matters. It's obviously different from: 451 Requested action aborted: DATA filter had a hiccup. > Now, I freely admit we're going to a lot of trouble to deal with what is > arguably a broken server, but (a) It turned out to be easy to implement and (b) > There was a point were a fairly popular server was doing this often enough to > make it worthwhile. > > I also note that the message "Too many recipients" is ambiguous as to cause. > >>> I'm not sure if this is a serious suggestion but, if we retain >>> the 452 code, do we need should we have an new code (borrowing >>> an analogy from interpretations of "666"), e.g., >>> >>> 566 You tried that more times, with the same parameters >>> and address list, than I will tolerate, please go >>> straight to an appropriate hot place and stay there > >> As I understand the RFC (and obviously implementors of SMTP clients as >> well), each response to a RCPT command pertains only to that recipient. > > Exactly. Perhaps, that can be made explicit in Section 3.3 Mail Transactions. >> So after getting a mixture of 2xx and 4xx responses a sender would not >> retry with the same address list. Some addresses have already been >> successful, so they aren't tried again. (Similary, if there were also >> some 5xx responses, those addresses won't be tried again, either.) > >> Maybe that should be stated explicitely somewhere (if it isn't already), >> but that's how I always understood the RFC. > > Me too. +1 > I also think that removing permitted code/response pairs is a really bad > idea. Of course it's wrong for clients to be overly restrictive in the code > combinations they allow, but given that there are widely used > implementations that do this (I'm looking at you, JavaMail) removing things > is IMO a really bad idea. If not removed, RCPT/552 deserves at least being discouraged. For example, by noting that a 552 reply code to RCPT likely has the same effect as a 550. Frankly, I don't understand the discussion in Section 4.5.3.1.10. In particular (i) the two intents: A prohibit messages with more than a site-specified number of recipients and B merely limit the number of recipients in a given mail transaction seem to only differ by the fact that A applies systematically to all transactions while B might look transient, which hardly sounds like the correct meaning. Then, (ii) Ned's implementation of storing separate queue entries may overcome what he calls "a badly implemented administrative limit", but is based on 4xy negative replies. Therefore, the option to: simply return the 503 after DATA without returning any previous negative response won't work in any case. jm2c Ale -- From nobody Wed Mar 10 11:46: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 0C9063A169B for ; Wed, 10 Mar 2021 11:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYm3nZAw-kiH for ; Wed, 10 Mar 2021 11:46:42 -0800 (PST) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09BA93A1678 for ; Wed, 10 Mar 2021 11:46:42 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RWI2ORE0F400CPQY@mauve.mrochek.com> for emailcore@ietf.org; Wed, 10 Mar 2021 11:41:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1615405296; bh=nWbsjb6tsvwiavdPzL0TamPWBayf4mp9vkwVJlACXW8=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=jjYIzhMhx7BH9krSpKD0/D9oHsOX9BQphVq1ZvMde3R5etutRdZ4ggQNOCC2rOhWG WeWupsmM+ubZpFyDwcg6AYGAPQCquzKilkDuxDU9aHf40tHVu5stboxifZgG/KRfAF zxcH/uRMg7UhsK36ELmRQlKDR45/xE3l6M+LNChM= 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 <01RWDMX50OQ8005PTU@mauve.mrochek.com>; Wed, 10 Mar 2021 11:41:33 -0800 (PST) Cc: Ned Freed , "Peter J. Holzer" , emailcore@ietf.org Message-id: <01RWI2OOX4ZM005PTU@mauve.mrochek.com> Date: Wed, 10 Mar 2021 11:08:09 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 10 Mar 2021 19:29:13 +0100" References: <86B11D00B74F9DA068CB3724@PSB> <20210310080645.GA2318@hjp.at> <01RWHFRDA4MG005PTU@mauve.mrochek.com> To: Alessandro Vesely Archived-At: Subject: Re: [Emailcore] Ticket #5, rfc5321bis Section 4.5.3.1.10, and G.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: Wed, 10 Mar 2021 19:46:44 -0000 > On Wed 10/Mar/2021 09:17:05 +0100 Ned Freed wrote: > >> On 2021-03-09 16:34:40 -0500, John C Klensin wrote: > >>> This is about the "Too Many Recipients Code" transition > >>> described in earlier versions of SMTP and the question of > >>> whether the transition text should be removed from 5321bis. > >>> > >>> The more I think about this, the more I wonder about whether 821 > >>> was right in the first place. Assuming the current spec, > >>> including that minimum of 100 recipients, was actually followed > >>> (see below) and the sender comes in with its 101st RCPT command. > >>> If the server comes back with 452, which is shown in the list in > >>> Section 4.2.2 as "insufficient storage" > > > > Yes, but there is no other code in that list that seems appropriate > > for "Too many recipients". > > > >>> and with the implication of all 4yz codes of "try again". > > > > The meaning of a 4YZ repsonse to RCPT TO is more subtle. (I don't > > put much stock in interpreting the second and third digits.) It could > > be any of: > > > > (1) A problem resolving this specific recipient, > > (2) An administrative limit has been reached, or > > (3) An actual storage limit has been hit. > 4yz can also be used to split the recipient list into a set that has DATA > filtering enabled and one that has it disabled. A DATA filter can either > accept or reject a message based on its content. In case it rejects, > recipients who have disabled such filtering have to receive the message in a > separate transaction. I'm not sure this case is part of (1) above. It isn't from the server's point of view, but it's the same as far as the client is concerned. However, in the case you raised, AFAICT there's no ambiguity to how to handle it: A 5YZ response return the message for the recipients you accepted, and retry the other set later. > Let me also note that by checking the first digit only, 552 and 550 are > treated in the same way. If you're referring to the workaround for the RFC 821 bug, aren't we close to consensus that it is no longer necessary? > >>> If the sender tries again with > >>> the same recipient list and gets the same response -- especially > >>> if the server uses the "insufficient system storage" message in > >>> the spec without a supplemental code -- we are getting close to > >>> Einstein's definition of insanity. > > > > Not necessarily. Transient problems do go away. LDAP servers come back up. > > > >> That's not how senders handle this case in my (admittedly limited) > >> experience. > > > >>> The presumably correct response from the sender would be to cut the > >>> number of recipients and try again, > > > >> I'm not sure that 'cut' is the right word to describe current (and I > >> think correct) behaviour. > 'Split'? > >> For illustrative purposes I'll assume that the receiving MTA has a limit > >> of 3 instead of 100. The sender tries to send a message to 8 recipients. > > > >> [EHLO, etc.] > >> MAIL FROM: > >> 250 OK > >> RCPT TO: > >> 250 OK > >> RCPT TO: > >> 250 OK > >> RCPT TO: > >> 250 OK > >> RCPT TO: > >> 452 OK # The limit is now exceeded, the > >> # receiver starts sending 452 replies > >> RCPT TO: > >> 452 OK > >> RCPT TO: > >> 452 OK > >> RCPT TO: > >> 452 OK > >> RCPT TO: > >> 452 OK > >> DATA # The sender knows that the message will > >> # be delivered to 3 recpipients, so it > >> # sends the content > >> 354 Start mail input; end with . > >> Blah blah blah... > >> . > >> 250 OK > >> QUIT > >> 221 > > > >> At this point, the message has been delivered to 3 recipients, but not > >> yet to the remaining 5. The sender doesn't really know why those got > >> temporary errors, nor does it care. It just requeues the message with > >> those 5 recpients and retries some time later: > > > >> [EHLO, etc.] > >> MAIL FROM: > >> 250 OK > >> RCPT TO: > >> 250 OK > >> RCPT TO: > >> 250 OK > >> RCPT TO: > >> 250 OK > >> RCPT TO: > >> 452 OK > >> RCPT TO: > >> 452 OK > >> DATA > >> 354 Start mail input; end with . > >> Blah blah blah... > >> . > >> 250 OK > >> QUIT > >> 221 > > > >> Two recpients still left, requeue, wait and try again: > > > >> [EHLO, etc.] > >> MAIL FROM: > >> 250 OK > >> RCPT TO: > >> 250 OK > >> RCPT TO: > >> 250 OK > >> DATA > >> 354 Start mail input; end with . > >> Blah blah blah... > >> . > >> 250 OK > >> QUIT > >> 221 > > > >> Done. > > > > My experience agrees with yours - this is how things work almost all of the > > time. There is, however, another possibility: > > > > [EHLO, etc.] > > MAIL FROM: > > 250 OK > > RCPT TO: > > 250 OK > > RCPT TO: > > 250 OK > > RCPT TO: > > 250 OK > > RCPT TO: > > 452 Too many recipients # The limit is now exceeded, the > > # receiver starts sending 452 replies > > RCPT TO: > > 452 Too many recipients > > RCPT TO: > > 452 Too many recipients > > RCPT TO: > > 452 Too many recipients > > RCPT TO: > > 452 Too many recipients > > DATA # The sender assumes the 3 good recipients > > # will work, but... > > 452 Recipient limit exceeded, try again with fewer recipients > > > > True storage limit errors are rare given the capacity of modern systems; the > > more likely cause here is a badly implemented administrative limit. And in such > > a case repeating the same transaction is unlikely to ever work. So what we do > > in this case is requeue as multiple messages so that we won't get to the point > > of receiving 452s responses to RCPT TO the next time. > Here the last digit matters. It's obviously different from: > 451 Requested action aborted: DATA filter had a hiccup. Obviously different to the server, but not, I think, in terms of what the client should do. Given a situation where some of the recipients were tempfailed and the DATA command also tempfailed, it does no harm to limit the number of recipients the next time around no matter what the cause. Arguably an even better approach would be to split into two groups based on the specific responses, but that's asking quite a lot of the client. > If not removed, RCPT/552 deserves at least being discouraged. For example, by > noting that a 552 reply code to RCPT likely has the same effect as a 550. Aside from avoiding 552 because of the bug in RFC 821, I'm afraid I don't see rationale for this. We can and do check for persistent over quota conditions at RCPT TO time, and if that's the case return a 5YZ error. If the RFC 821 bug is no longer a concern, the only reason for not returning 552 now is to avoid the workaround. > Frankly, I don't understand the discussion in Section 4.5.3.1.10. In > particular (i) the two intents: > A prohibit messages with more than a site-specified number of recipients > and > B merely limit the number of recipients in a given mail transaction > seem to only differ by the fact that A applies systematically to all > transactions while B might look transient, which hardly sounds like the correct > meaning. Then, (ii) Ned's implementation of storing separate queue entries may > overcome what he calls "a badly implemented administrative limit", but is based > on 4xy negative replies. Therefore, the option to: > simply return the 503 after DATA > without returning any previous negative response > won't work in any case. It will work, for some value of the word "work", because we treat 5YZs as the permanent failures they are and don't attempt to second-guess the server. We only engage in recipient list limiting when given a subsequent 4YZ. That said, given the number of clients that use a separate transaction for each recipient, the idea that you can limit the number of reicpients of a message in this way is sufficiently dumb that I see no reason to mention it as useful thing to do. Ned From nobody Wed Mar 10 13:11: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 D66A73A1839 for ; Wed, 10 Mar 2021 13:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WESkY3riGE2d for ; Wed, 10 Mar 2021 13:11:47 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4793E3A1838 for ; Wed, 10 Mar 2021 13:11:47 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lK67N-000NGU-Or; Wed, 10 Mar 2021 16:11:45 -0500 Date: Wed, 10 Mar 2021 16:11:40 -0500 From: John C Klensin To: "Peter J. Holzer" , emailcore@ietf.org Message-ID: <94042877D6466A6B6021D801@PSB> In-Reply-To: <20210310080645.GA2318@hjp.at> References: <86B11D00B74F9DA068CB3724@PSB> <20210310080645.GA2318@hjp.at> 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 #5, rfc5321bis Section 4.5.3.1.10, and G.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: Wed, 10 Mar 2021 21:11:49 -0000 --On Wednesday, March 10, 2021 09:06 +0100 "Peter J. Holzer" wrote: > On 2021-03-09 16:34:40 -0500, John C Klensin wrote: >> This is about the "Too Many Recipients Code" transition >> described in earlier versions of SMTP and the question of >> whether the transition text should be removed from 5321bis. >> >> The more I think about this, the more I wonder about whether >> 821 was right in the first place. Assuming the current spec, >> including that minimum of 100 recipients, was actually >> followed (see below) and the sender comes in with its 101st >> RCPT command. If the server comes back with 452, which is >> shown in the list in Section 4.2.2 as "insufficient storage" >> and with the implication of all 4yz codes of "try again". If >> the sender tries again with the same recipient list and gets >> the same response -- especially if the server uses the >> "insufficient system storage" message in the spec without a >> supplemental code -- we are getting close to Einstein's >> definition of insanity. > > That's not how senders handle this case in my (admittedly > limited) experience. > >> The presumably correct response from the sender would be to >> cut the number of recipients and try again, > > I'm not sure that 'cut' is the right word to describe current > (and I think correct) behaviour. > > For illustrative purposes I'll assume that the receiving MTA > has a limit of 3 instead of 100. The sender tries to send a > message to 8 recipients. > > [EHLO, etc.] > MAIL FROM: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 452 OK # The limit is now exceeded, > the # receiver starts sending > 452 replies RCPT TO: > 452 OK > RCPT TO: > 452 OK > RCPT TO: > 452 OK > RCPT TO: > 452 OK > DATA # The sender knows that the > message will # be delivered to > 3 recpipients, so it # sends > the content > 354 Start mail input; end with . > Blah blah blah... > . > 250 OK > QUIT > 221 > > At this point, the message has been delivered to 3 recipients, > but not yet to the remaining 5. The sender doesn't really know > why those got temporary errors, nor does it care. It just > requeues the message with those 5 recpients and retries some > time later: > > [EHLO, etc.] > MAIL FROM: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 452 OK > RCPT TO: > 452 OK > DATA > 354 Start mail input; end with . > Blah blah blah... > . > 250 OK > QUIT > 221 > > Two recpients still left, requeue, wait and try again: > > [EHLO, etc.] > MAIL FROM: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 250 OK > DATA > 354 Start mail input; end with . > Blah blah blah... > . > 250 OK > QUIT > 221 > > Done. This makes much more sense than the scenario I was thinking of, but runs into another issue or two. Your scenario probably explains why we wanted to make the change from 552 to 452 for this case [1]. Although neither is precisely aligned with what the spec says about the difference between 4yz and 5yz codes, the former seems much more likely to be interpreted by an unwary implementation in the way your scenario suggests -- discard the additional recipients, handle the other recipients and message as normal, and then resend with the recipients that got the 452 code, rather than interpreting a 5yz code as "just stop right now and send QUIT". Based on the discussion during the meeting a few hours ago (I only saw your note just now) that indicated that almost no one is following the 5321 advice and transitioning to 452, it looks as if probably the advice about switching should be removed, the more general advice about the code should be switched to SHOULD or MAY, and, especially if the latter, the whole paragraph removed and any comments on the subject moved to the A/S. It is probably time for me to take another nap before I have an additional attack of stupid. thanks, john [1] I have normally made notes in the source files to remind me of why we made a particular change but didn't in this case. Murphy's Law, I suppose. From nobody Wed Mar 10 13:47: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 F2D7F3A18EB for ; Wed, 10 Mar 2021 13:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIyW1MfsnUEl for ; Wed, 10 Mar 2021 13:47:37 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A78B3A18EA for ; Wed, 10 Mar 2021 13:47:36 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lK6fz-000NOd-CF; Wed, 10 Mar 2021 16:47:31 -0500 Date: Wed, 10 Mar 2021 16:47:25 -0500 From: John C Klensin To: Ned Freed , "Peter J. Holzer" cc: emailcore@ietf.org Message-ID: <8FA3FFF3827FE28A6DA9F196@PSB> In-Reply-To: <01RWHFRDA4MG005PTU@mauve.mrochek.com> References: <86B11D00B74F9DA068CB3724@PSB> <20210310080645.GA2318@hjp.at> <01RWHFRDA4MG005PTU@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 #5, rfc5321bis Section 4.5.3.1.10, and G.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: Wed, 10 Mar 2021 21:47:39 -0000 --On Wednesday, March 10, 2021 00:17 -0800 Ned Freed wrote: >> On 2021-03-09 16:34:40 -0500, John C Klensin wrote: >> > This is about the "Too Many Recipients Code" transition >> > described in earlier versions of SMTP and the question of >> > whether the transition text should be removed from 5321bis. > >> > The more I think about this, the more I wonder about >> > whether 821 was right in the first place. Assuming the >> > current spec, including that minimum of 100 recipients, was >> > actually followed (see below) and the sender comes in with >> > its 101st RCPT command. If the server comes back with 452, >> > which is shown in the list in Section 4.2.2 as >> > "insufficient storage" > > Yes, but there is no other code in that list that seems > appropriate for "Too many recipients". > >> > and with the implication of all 4yz codes of "try again". > > The meaning of a 4YZ repsonse to RCPT TO is more subtle. (I > don't put much stock in interpreting the second and third > digits.) It could be any of: > > (1) A problem resolving this specific recipient, > (2) An administrative limit has been reached, or > (3) An actual storage limit has been hit. > >> > If the sender tries again with >> > the same recipient list and gets the same response -- >> > especially if the server uses the "insufficient system >> > storage" message in the spec without a supplemental code -- >> > we are getting close to Einstein's definition of insanity. > > Not necessarily. Transient problems do go away. LDAP servers > come back up. > >> That's not how senders handle this case in my (admittedly >> limited) experience. > >> > The presumably correct response from the sender would be to >> > cut the number of recipients and try again, > >> I'm not sure that 'cut' is the right word to describe current >> (and I think correct) behaviour. > >> For illustrative purposes I'll assume that the receiving MTA >> has a limit of 3 instead of 100. The sender tries to send a >> message to 8 recipients. > >> [EHLO, etc.] >> MAIL FROM: >> 250 OK >> RCPT TO: >> 250 OK >> RCPT TO: >> 250 OK >> RCPT TO: >> 250 OK >> RCPT TO: >> 452 OK # The limit is now exceeded, >> the >> # receiver starts sending 452 >> # replies >> RCPT TO: >> 452 OK >> RCPT TO: >> 452 OK >> RCPT TO: >> 452 OK >> RCPT TO: >> 452 OK >> DATA # The sender knows that the >> message will >> # be delivered to 3 >> # recpipients, so it sends >> # the content >> 354 Start mail input; end with . >> Blah blah blah... >> . >> 250 OK >> QUIT >> 221 > >> At this point, the message has been delivered to 3 >> recipients, but not yet to the remaining 5. The sender >> doesn't really know why those got temporary errors, nor does >> it care. It just requeues the message with those 5 recpients >> and retries some time later: > >> [EHLO, etc.] >> MAIL FROM: >> 250 OK >> RCPT TO: >> 250 OK >> RCPT TO: >> 250 OK >> RCPT TO: >> 250 OK >> RCPT TO: >> 452 OK >> RCPT TO: >> 452 OK >> DATA >> 354 Start mail input; end with . >> Blah blah blah... >> . >> 250 OK >> QUIT >> 221 > >> Two recpients still left, requeue, wait and try again: > >> [EHLO, etc.] >> MAIL FROM: >> 250 OK >> RCPT TO: >> 250 OK >> RCPT TO: >> 250 OK >> DATA >> 354 Start mail input; end with . >> Blah blah blah... >> . >> 250 OK >> QUIT >> 221 > >> Done. > > My experience agrees with yours - this is how things work > almost all of the time. There is, however, another possibility: > > [EHLO, etc.] > MAIL FROM: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 250 OK > RCPT TO: > 452 Too many recipients # The limit is now exceeded, > the # receiver starts sending > 452 replies RCPT TO: > 452 Too many recipients > RCPT TO: > 452 Too many recipients > RCPT TO: > 452 Too many recipients > RCPT TO: > 452 Too many recipients > DATA # The sender assumes the 3 > good recipients # will work, > but... > 452 Recipient limit exceeded, try again with fewer recipients > > True storage limit errors are rare given the capacity of > modern systems; the more likely cause here is a badly > implemented administrative limit. And in such a case repeating > the same transaction is unlikely to ever work. So what we do > in this case is requeue as multiple messages so that we won't > get to the point of receiving 452s responses to RCPT TO the > next time. > > Now, I freely admit we're going to a lot of trouble to deal > with what is arguably a broken server, but (a) It turned out > to be easy to implement and (b) There was a point were a > fairly popular server was doing this often enough to make it > worthwhile. > > I also note that the message "Too many recipients" is > ambiguous as to cause. > >> > I'm not sure if this is a serious suggestion but, if we >> > retain the 452 code, do we need should we have an new code >> > (borrowing an analogy from interpretations of "666"), e.g., >> > >> > 566 You tried that more times, with the same parameters >> > and address list, than I will tolerate, please go >> > straight to an appropriate hot place and stay there > >> As I understand the RFC (and obviously implementors of SMTP >> clients as well), each response to a RCPT command pertains >> only to that recipient. > > Exactly. > >> So after getting a mixture of 2xx and 4xx responses a sender >> would not retry with the same address list. Some addresses >> have already been successful, so they aren't tried again. >> (Similary, if there were also some 5xx responses, those >> addresses won't be tried again, either.) > >> Maybe that should be stated explicitely somewhere (if it >> isn't already), but that's how I always understood the RFC. > > Me too. I also think that removing permitted code/response > pairs is a really bad idea. Of course it's wrong for clients > to be overly restrictive in the code combinations they allow, > but given that there are widely used implementations that do > this (I'm looking at you, JavaMail) removing things is IMO a > really bad idea. That suggests to me that: (1) We don't remove either code (easy, because they can be used for other purposes, such as running out of of storage, although I agree that is unlikely with today's systems. (2) We note for both the 552 and 452 codes that they can be used for the "too many addresses" case as well as the more general storage-related one. (3) Probably (but subject to further discussion) we leave the first paragraph of 4.5.3.1.10 alone because all it really says is that a 552 code in response to RCTP is reasonably treated as temporary rather that the "just stop and send QUIT or RSET" behavior normally expected in response to a 5yz code. (4) We reconsider the MUST in the third paragraph of 4.5.3.1.10. because it is being widely ignored and figure out if that paragraph needs to be rewritten. (5) We put text in the A/S exploring this issue and other issues where an implementation exceeds either the 5321 minimum limits or smaller limits imposed by the implementation or configuration as "operationally necessary. --and-- we consider whether there should be a separate code or codes for "implementation limit exceeded" and what they should be. Then I think that we drop the idea because it is too late and because the observation that, in the 20 years since 2821 was published, very few systems have adopted the instructions of 2821 and 5321 to send 452 rather than 552 suggests that such instructions are hopeless Does that seem like a way forward? john From nobody Wed Mar 10 18:25: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 82DDF3A0CCF for ; Wed, 10 Mar 2021 18:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=DgRvkVaz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vzUggg31 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXjRYysj_JPV for ; Wed, 10 Mar 2021 18:25:20 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477F33A0CC7 for ; Wed, 10 Mar 2021 18:25:20 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 7AA3D5C00EC for ; Wed, 10 Mar 2021 21:25:18 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Wed, 10 Mar 2021 21:25:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=kJABcYz 5XmHFxPGWuHG0a+5m0d4C8gWortGrwPnuLOw=; b=DgRvkVazptVybCWwY936d1P u+OPmh1WWJG0F0mXww+tgPt0a/7Bb6x4w/NQBgjR1DNLaMIzEt0PC4oPV2mCnNlh bIRSk/ofMORl5FfLDD6ZffCC2rZPmLgCehhrUZomKy1OHowr8RQTc2u5IglAbgrA fHZAEiMef0z6hJDu6IYskkWYG30hg+BMw1h0u3owmEnkAMeNvJE+08Z87GAhAv49 aWFwZdue1muSGSJr+6KS91B+Mh4cLqqK2RDhnzI+U8nfMlxO8A+xnfH3+c8LoQcn TeW4if2oyFqWwIRIhSvzGZkNCe91hcY3kHrfpVXnYWzk08ldmZd+VCys+KBxaEw= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=kJABcY z5XmHFxPGWuHG0a+5m0d4C8gWortGrwPnuLOw=; b=vzUggg31/WeQnfr8dy2haZ Kzextt2aktPJXJ7Oni3Yr6xOXwwkOp3vk3MJ9hN3UEVyJSlVNM7oEqVVsevKIH0N S8RNQ51/wWXykvp2zOaJmv6tiakIC5KwaPXDAwGZ0tSXof4/KUBSJk8igkJnz3JC MxJtWw0IXiII+SQFj4ti7SeX8pnW3gL0swu68IHwJ1nHbqbRkEjBF+v6J5KwciZx mMXjh3Pj70PdJPeA8Bmo5W0/I1TRangnQp0G+cZ4yHVR1N4Pi+zrGWsl1nIAH+rr 2nks3QM6ZvyjrN62Vj+Fyl0IKWRIZIwmenNucyYhmaeQ1C31nkVFMSLlckTckZsQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudduledggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeekudefgefhke etheegveelueefudelgeeuhfegveejueehtefhfedtveehteefvdenucffohhmrghinhep sggsihifrdhnvghtpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgodhmvghsmhhtphhouhhtghhoihhnghdq sghrohhngheppehfrghsthhmrghilhhtvggrmhdrtghomhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B091B260005D; Wed, 10 Mar 2021 21:25:17 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd Mime-Version: 1.0 Message-Id: <76c03d98-5b4e-49f1-924b-37a7568b6907@dogfood.fastmail.com> In-Reply-To: <3e7f0fb6-1bf7-1687-1b74-0af75cb6df78@dcrocker.net> References: <3e7f0fb6-1bf7-1687-1b74-0af75cb6df78@dcrocker.net> Date: Thu, 11 Mar 2021 13:24:56 +1100 From: "Bron Gondwana" To: emailcore@ietf.org Content-Type: multipart/alternative; boundary=44c8c0a0624342aca6604d544b271636 Archived-At: Subject: Re: [Emailcore] Default yes / Default no X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 11 Mar 2021 02:25:23 -0000 --44c8c0a0624342aca6604d544b271636 Content-Type: text/plain Yep, that's a fair complaint - and I agree with the sentiment. What I was looking for was whether there was a middle ground here where there's a "balance of harms" for both options. I.e. if the "Default No" was the right thing in that case. It was the middle of the night and I don't even recall what the point was... Oh yeah - trace fields. I don't have a strong opinion about the answer, but it did sound like there were at least "future compatibility" issues that were worth considering rather than entirely dismissing the discussion because there's no current operational emergency. Anyway - I appreciate you pushing forward on it Dave, and thanks Barry for breaking that up - it's the most contention I've had in anything this IETF which is saying something :) It's been pretty chill so far, even GENDISPATCH amazingly enough. Cheers, Bron. On Thu, Mar 11, 2021, at 00:14, Dave Crocker wrote: > If I understood Bron's question to me, during the session, it was of the > general form "Are there problems that would be caused by doing this?" > > That is a Default Yes model of wg effort. It's entirely appropriate, > sometimes. > > But this wg has an intentionally /very/ narrow charter which I believe > is thoughtfully designed to impose a Default No view towards changes. > > Changes ought to be restricted to compelling deficiencies in the > protocol specification, where there are known operational effects. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > -- > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --44c8c0a0624342aca6604d544b271636 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Yep, that's a fair complaint - and I agree with the sentim= ent.

What I was looking for was whether there was a middl= e ground here where there's a "balance of harms" for both options. = I.e. if the "Default No" was the right thing in that case.  It was= the middle of the night and I don't even recall what the point was...

Oh yeah - trace fields.  I don't have a strong opinio= n about the answer, but it did sound like there were at least "future co= mpatibility" issues that were worth considering rather than entirely dis= missing the discussion because there's no current operational emergency.=

Anyway - I appreciate you pushing forward on it Dave, an= d thanks Barry for breaking that up - it's the most contention I've had = in anything this IETF which is saying something :)  It's been prett= y chill so far, even GENDISPATCH amazingly enough.

Cheers,=

Bron.

On Thu, Mar 11, 2021, at 00:14, Dave Crocker wrote:
If I understood Bron's question to me, during the session, it was = of the 
general form "Ar= e there problems that would be caused by doing this?"

Tha= t is a Default Yes model of wg effort.  It's entirely appropriate,&= nbsp;
sometimes.

But this wg has an intentionally /very/ narrow charter which I believ= e 
is thoughtfully desig= ned to impose a Default No view towards changes.

Changes = ought to be restricted to compelling deficiencies in the 
=
protocol specification, where there ar= e known operational effects.
=
d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Emailcore mailing list


--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--44c8c0a0624342aca6604d544b271636-- From nobody Wed Mar 10 19:49: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 08F163A0BB2 for ; Wed, 10 Mar 2021 19:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, T_SPF_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=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syF88fYBdR4I for ; Wed, 10 Mar 2021 19:49:38 -0800 (PST) Received: from wforward3-smtp.messagingengine.com (wforward3-smtp.messagingengine.com [64.147.123.22]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD71B3A0BB1 for ; Wed, 10 Mar 2021 19:49:38 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailforward.west.internal (Postfix) with ESMTP id C305530B1 for ; Wed, 10 Mar 2021 22:49:33 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 10 Mar 2021 22:49:33 -0500 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 :reply-to:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=P7tSdkWqt+t9VrsdycHV5EIiQeyK2 AQsEvpSmAZgItc=; b=XBBxSkB7n0tP+nP62yKxrUkJpPgK36la2L7Hr+orlWB10 FrpZESr4Enp8qWaCrxa+5Qeo51oV6IMvaMR3qxCCj/jePpb6qDglistZc05VP8Wa oErDVBjTA89R5LL6ND6X5t1+0VNy39NT8JwkgMU/WYmtaMr+Ncee5kJGgyRy/aE0 ZTf7LzD4eRIlYRXpe/CYjVkB+MLmKdGAnAvKgUGWvh7bENlng4d+PZqA2iZeJRSh JgDVprm+ZlIa4sTJ7ehcF4BpMfEoVOXHwem9YNc0315zIY5u3DLr8/HpwOAtnObQ 6/Gv/Gm+j/cabBo694cw9j3q8QOIqZ/MOvRUzDDbg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudduledgiedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpehruffvfhfhohfkffgfgggjtgfgse htjeertddtfeejnecuhfhrohhmpeffrghvvgcuvehrohgtkhgvrhcuoeguhhgtsegutghr ohgtkhgvrhdrnhgvtheqnecuggftrfgrthhtvghrnhepkedtleffgfdvieduhfdvhefhje dvvdduieekvdeufeeigfetheefgeefvefftedunecuffhomhgrihhnpegssghifidrnhgv thenucfkphepuddtkedrvddviedrudeivddrieefnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepughhtgesuggtrhhotghkvghrrdhnvght X-ME-Proxy: Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 0BB231080054 for ; Wed, 10 Mar 2021 22:49:31 -0500 (EST) Reply-To: dcrocker@bbiw.net To: emailcore@ietf.org References: <3e7f0fb6-1bf7-1687-1b74-0af75cb6df78@dcrocker.net> <76c03d98-5b4e-49f1-924b-37a7568b6907@dogfood.fastmail.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <933dd10a-c803-435b-1c1d-259b9b3d48a7@dcrocker.net> Date: Wed, 10 Mar 2021 19:49:31 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <76c03d98-5b4e-49f1-924b-37a7568b6907@dogfood.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Default yes / Default no X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 11 Mar 2021 03:49:43 -0000 On 3/10/2021 6:24 PM, Bron Gondwana wrote: > it's the most contention I've had in anything this IETF which is saying > something :) whereas to me it almost felt like a love fest... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Mar 10 20:22: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 D50473A0DA5 for ; Wed, 10 Mar 2021 20:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 HiOObyZlNuzZ for ; Wed, 10 Mar 2021 20:22:16 -0800 (PST) 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 6133F3A0DAC for ; Wed, 10 Mar 2021 20:22:16 -0800 (PST) Received: from [192.168.1.177] (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 21C5FCB3E2 for ; Wed, 10 Mar 2021 23:22:15 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 11 Mar 2021 02:22:14 -0200 Content-Transfer-Encoding: 7bit Reply-To: emailcore@ietf.org Message-Id: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> References: To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 11 Mar 2021 04:22:18 -0000 > On Mar 8, 2021, at 7:40 PM, Todd Herr wrote: > > Google: Emits 452, treats 552 as permanent failure > Microsoft: Emits 550, treats 552 as permanent failure (probably) Are you sure that Microsoft emits "5XX" for the N+1st recipient after accepting N == max configured recipients? For what value of "N" are you observing this? Is pipelining a factor and how far ahead of the server is the client willing to get before the 5XX responses set in? Hard rejecting recipients when <= 100 (the smallest required rcpt count servers are expected to support per 5321) would be rather badly broken. There's a good reason why the "too many recipients" code is expected to be 452, if one wants to force envelopes to be 99 recipients or fewer. At more than 100 recipients, it is still a good idea to reject with 452, but the client is on shakier ground for wanting to go there, it should split the envelope barring prior knowledge that the server is willing to accept more. > Proofpoint MTA: No default configuration for too many recipients, > so emits whatever admin wants; treats 552 as permanent failure. Again, 5XX before the 101st recipient just because the envelope has too many in one go would be wrong. The way to encourage the sender to split envelopes is to reject the excess ones with 452. All that said, the RFC text in question is bogus, no client I know of honours it. -- Viktor. From nobody Wed Mar 10 20:44: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 EA0563A0E61 for ; Wed, 10 Mar 2021 20:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 D9EGietzLYWO for ; Wed, 10 Mar 2021 20:44:41 -0800 (PST) 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 6C9433A0E5F for ; Wed, 10 Mar 2021 20:44:41 -0800 (PST) Received: from [192.168.1.177] (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 AF212CB1D7 for ; Wed, 10 Mar 2021 23:44:40 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Viktor Dukhovni In-Reply-To: <8FA3FFF3827FE28A6DA9F196@PSB> Date: Thu, 11 Mar 2021 02:44:40 -0200 Content-Transfer-Encoding: 7bit Reply-To: emailcore@ietf.org Message-Id: <1C2CC229-9EFE-4552-B518-C0C80ECD8274@dukhovni.org> References: <86B11D00B74F9DA068CB3724@PSB> <20210310080645.GA2318@hjp.at> <01RWHFRDA4MG005PTU@mauve.mrochek.com> <8FA3FFF3827FE28A6DA9F196@PSB> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Emailcore] Ticket #5, rfc5321bis Section 4.5.3.1.10, and G.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: Thu, 11 Mar 2021 04:44:43 -0000 > On Mar 10, 2021, at 7:47 PM, John C Klensin wrote: > > (1) We don't remove either code (easy, because they can be used > for other purposes, such as running out of of storage, although > I agree that is unlikely with today's systems. Correct. > (2) We note for both the 552 and 452 codes that they can be used > for the "too many addresses" case as well as the more general > storage-related one. Perhaps so, but 552 is very unwise if the only reason for rejecting the recipient is a ceiling on the number of recipients per envelope that is short of 100, or a desire to force different "classes" of recipients into separate envelopes, by selectively rejecting (that is tempfailing) some. > (3) Probably (but subject to further discussion) we leave the > first paragraph of 4.5.3.1.10 alone because all it really says > is that a 552 code in response to RCTP is reasonably treated as > temporary rather that the "just stop and send QUIT or RSET" > behavior normally expected in response to a 5yz code. Absolutely, 100%, unconditionally, ... NO WAY. The text about treating 5XX as though it were a 4XX reply MUST go. There is no mechanism for the client to divine the exact reason why the server choice 552 and not some other 5XX code. The bottom line is that a recipient that got a 5XX code WILL be bounced, and a recipient got a 4XX code will be deferred. When at least one recipient is accepted, but some are deferred (4XX) an MTA doing SMTP relaying (unlike an MUA doing SUBMIT) MUST NOT immediately defer the accepted recipients. MTAs are expected to be able to deliver a portion of the message envelope in one transaction and the remainder in one or more additional transactions. Indeed when a destination has more than one MX host, and the first transaction defers some recipients, Postfix will by default immediately open a connection to a second MX (by default tries at most two per envelope, before deferring for later) and try the remaining 4XX recipients there. > (4) We reconsider the MUST in the third paragraph of 4.5.3.1.10. > because it is being widely ignored and figure out if that > paragraph needs to be rewritten. There's not much to reconsider, no clients treat a 5XX as 4XX, and none are likely to start now. -- Viktor. From nobody Wed Mar 10 21:02:37 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 62AAF3A0EFF for ; Wed, 10 Mar 2021 21:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KRrRjsIWmLoQ for ; Wed, 10 Mar 2021 21:02:33 -0800 (PST) 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 25A5C3A0EFC for ; Wed, 10 Mar 2021 21:02:33 -0800 (PST) Received: from [192.168.1.177] (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 55152CB891 for ; Thu, 11 Mar 2021 00:02:32 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 11 Mar 2021 03:02:32 -0200 Content-Transfer-Encoding: quoted-printable Reply-To: emailcore@ietf.org Message-Id: <90193904-97EF-475A-B130-8C1E240C4696@dukhovni.org> References: To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Emailcore] Ticket #16: G.7.12. Review Timeout Specifications X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 11 Mar 2021 05:02:34 -0000 > On Feb 23, 2021, at 6:10 PM, Todd Herr wrote: >=20 > RFC 5321 (and its predecessors going back to 821) specify minimum = periods > for client and server to wait before timing out. Are those intervals = still > appropriate in a world of faster processors and faster networks? = Should they > be updated and revised? Or should more qualifying language be added? Sadly, the more CPU horsepower we add, the more new work we expect them to do. Nothing gets faster, we just raise the complexity. What this means in the present context is that clients waiting for a response to DATA must still wait the full 600s, because the various virus scanning engines and callouts to remote services that return URL reputation information, ... all take time. Servers expect to be able to still use the original timeout, and just squeeze more out of the available time budget. > On a related note (maybe another issue?), only a few mailers sit after > an DATA transaction holding the socket until something else comes in > to start a new transaction. Here, I'm quite sympathetic to a less generous limit. Postfix will hog an idle connection for at most 2 seconds, and will only keep it alive in the first place when there is a backlog for the destination domain at the time the delivery starts, and so some likelihood that the connection will be reused. Wietse considered it rude to hog the resources of remote servers for more than a brief time to piggy-back an immediately ready message. So, yes, even 5s would be more than sufficient, 300s is much too = generous. Again (the space I know), Postfix will generally wait the 300s, but is somewhat adaptive and as the server's connection limit is saturated that time drops to 10s. --=20 Viktor. From nobody Wed Mar 10 21:24: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 DA1F03A1039 for ; Wed, 10 Mar 2021 21:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7NWP9fH8Oup for ; Wed, 10 Mar 2021 21:24:41 -0800 (PST) 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 37C173A1034 for ; Wed, 10 Mar 2021 21:24:41 -0800 (PST) Received: from [192.168.1.177] (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 F0870CB7A9 for ; Thu, 11 Mar 2021 00:24:39 -0500 (EST) From: Viktor Dukhovni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Reply-To: emailcore@ietf.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: Date: Thu, 11 Mar 2021 03:24:39 -0200 To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: [Emailcore] Long threads and "References" header (5322 section 3.6.4) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 05:24:43 -0000 As email threads extend into deep chains on lists such as this one, the list of message-ids appearing in "References:" headers can get rather long. Some MUAs (used to last time I checked, but not admittedly recently, are they all good citizens now???) flatten the list into a single physical line, forcing the MSA to attempt to fold the list in order to stay under the 998 + CRLF byte count limit for physical lines in = SMTP. Such folding is not always particularly cleverly implemented, there is not always a fancy parser for this embedded in the MTA. The result is that the "References" header is not infrequently mangled, with fragments of various message-ids padding out the list. I'd like to suggest a recommendation that MUAs keep only a short list of the most recent message-ids when appending a new one, keeping the overall length of the list below the 998 limit, allowing it to fit on a single line without folding. Below is an example of a "starting to get noticeably long" References list from the TLS WG. It is nicely folded over multiple lines, so not mangled, but it risks damage if handled by an MUA that unfolds the lines, and in any case, it is not clear that quite so many references are needed to reconstruct the thread. Just a few should be enough, unless the recipient is missing many messages in the middle of the thread: References: <6241F0B6-C722-449E-AC3A-183DE330E7B5@deployingradius.com> <9ddd1593-3131-f5cc-d0db-74bf3db697bf@ericsson.com> <3CB58153-8CCA-4B1E-B530-BA67A6035310@deployingradius.com> <770e6a49-52fc-4e8b-91af-48f85e581fbb@www.fastmail.com> <3409F71E-4CE4-46BB-8079-BFBE9BE83C9A@deployingradius.com> <66157321-55DC-4831-8EF2-D75934D9024C@deployingradius.com> <20210129183220.GI21@kduck.mit.edu> <1A830492-3404-4BCC-844B-D7D950458BD9@deployingradius.com> <9E25ADFC-16F2-4719-B223-E34598633D2B@deployingradius.com> <34757A81-4918-4B48-9ECC-533DB861992A@deployingradius.com> In-Reply-To: From: Joseph Salowey Date: Mon, 1 Feb 2021 13:52:04 -0800 Message-ID: = --=20 Viktor. From nobody Wed Mar 10 21:39: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 754C93A10B1 for ; Wed, 10 Mar 2021 21:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ecgx3RUtwr5 for ; Wed, 10 Mar 2021 21:39:57 -0800 (PST) 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 AABBB3A10B8 for ; Wed, 10 Mar 2021 21:39:56 -0800 (PST) Received: from [192.168.1.177] (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 C80DCCBA18 for ; Thu, 11 Mar 2021 00:39:55 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 11 Mar 2021 03:39:55 -0200 Content-Transfer-Encoding: 7bit Reply-To: emailcore@ietf.org Message-Id: References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of 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: Thu, 11 Mar 2021 05:39:59 -0000 > On Oct 20, 2020, at 3:02 AM, John C Klensin wrote: > > I can think of cases in which they might change and the change > might be significant, but they are far-fetched enough that, if a > rule were adopted that if as second EHLO is sent it must contain > the same information would probably be harmless. One can imagine cases for the HELO name to change for an MTA behind a trusted proxy that serialises a sequence of incoming connections from clients over a single connection to a backend MTA. It might then reissue EHLO to match the data sent by the external client. (Of course such a proxy would have to be careful to not give clients unfiltered access to the downstream SMTP channel). In Postfix signal of the upstream client identity would typically be done via XCLIENT or XFORWARD, but there could be other legitimate reasons for a client or proxy to change the HELO name. There does not seem to be much point to prohibit this, if anything, the client is giving the server more information that can help distinguish friend from foe. The client could always reconnect and switch identities, which would be more expensive. Let it send a new EHLO if it wants. -- Viktor. From nobody Thu Mar 11 05:12:37 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 0A9DE3A0A65 for ; Thu, 11 Mar 2021 05:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJfkgO42XtAq for ; Thu, 11 Mar 2021 05:12:33 -0800 (PST) Received: from rorschach.hjp.at (mail.hjp.at [212.17.106.138]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC133A0A5E for ; Thu, 11 Mar 2021 05:12:32 -0800 (PST) Received: by rorschach.hjp.at (Postfix, from userid 1000) id 880E44686; Thu, 11 Mar 2021 14:12:29 +0100 (CET) Date: Thu, 11 Mar 2021 14:12:29 +0100 From: "Peter J. Holzer" To: emailcore@ietf.org Message-ID: <20210311131229.GA4576@hjp.at> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Emailcore] Long threads and "References" header (5322 section 3.6.4) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 13:12:36 -0000 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-03-11 03:24:39 -0200, Viktor Dukhovni wrote: > As email threads extend into deep chains on lists such as this one, > the list of message-ids appearing in "References:" headers can get > rather long. >=20 > Some MUAs (used to last time I checked, but not admittedly recently, > are they all good citizens now???) flatten the list into a single > physical line, forcing the MSA to attempt to fold the list in order > to stay under the 998 + CRLF byte count limit for physical lines in SMTP. >=20 > Such folding is not always particularly cleverly implemented, there > is not always a fancy parser for this embedded in the MTA. >=20 > The result is that the "References" header is not infrequently mangled, > with fragments of various message-ids padding out the list. >=20 > I'd like to suggest a recommendation that MUAs keep only a short > list of the most recent message-ids when appending a new one, keeping > the overall length of the list below the 998 limit, allowing it to fit > on a single line without folding. RFC 5537 contains such a rule (it's even a MUST, not just a recommendation): If the resulting References header field would, after unfolding, exceed 998 characters in length (including its field name but not the final CRLF), it MUST be trimmed (and otherwise MAY be trimmed). Trimming means removing any number of message identifiers from its content, except that the first message identifier and the last two MUST NOT be removed. The References header was originally borrowed from Usenet (IIRC there was a References header in RFC 822, but with different semantics), so it would make sense to adopt the trimming rule, too (some MUAs may actually already do this). hp --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmBKFzgACgkQ8g5IURL+ KF3Isg/+K3hwDAB6kXvph2fQunGmyK12zdWnBruUbrJQM5IMLB7u+N7yPAfIA+ww XAg63CDRzndhNIfW5lfGWFZqn+FPWx75L95CjpNwpkXdM5k6jFOaxxzNxzSUNWB8 1F6jPmdF6Q7m0K0iHGUxs+EGy0Xo8zC8SRtoVpwvry2to+UAJNd0O1A6wrFToC5Z tQZyCNOmSk7nHGGUTPvTL3UVxOiJgb42PflyxYGFjn4xTaViLSPxOV13pTnL5/iZ fFeYDlHD6qo4Yyd61FKWr85t11HUlQFviR+0ps+4Yiiev92BaZiIDItm7hFJUx09 lgovTYiBhi8hI+HV1YU8TUBgQTknb88DvJtCL3MXHrmVFYMat9dmdjRTypNR24mv pv2XPOghBGY3y0xGFc+I0wrdMelCWOj+26vBrF2KM2lYK+GfZUl5b783Z87xU02O x7uh/p5zDLhRo7BO8t/tTU661EuEcEvYsSFpCFKPqMLLLu+i1WsOtpSJJ2/o/s5Z ohk7p0l9jdYOF2OYo8BEFS41lbDJF9rZyjvwezEdNW9eygeOam0JeZntpHRO69KL uyCTWRKfcb0g5wT7Jxo0SiTlfzakGKTlBo/lsHLpwSXAQAT5VnprJ4HGsyICzp4w SEgDA1ahtlFQ66/QGNdcsH3/C3f8sqMz2zsIidEEUm/YB/2yVzs= =tmW0 -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- From nobody Thu Mar 11 05:29: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 E4F163A0BCC for ; Thu, 11 Mar 2021 05:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QCnPNCl1REB for ; Thu, 11 Mar 2021 05:29:04 -0800 (PST) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558873A0BC5 for ; Thu, 11 Mar 2021 05:29:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 17880DA7F074; Thu, 11 Mar 2021 07:29:03 -0600 (CST) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ki7lY-Zcz_Kd; Thu, 11 Mar 2021 07:28:54 -0600 (CST) Received: from [172.16.1.16] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id E5400DA7F04A; Thu, 11 Mar 2021 07:28:53 -0600 (CST) From: Pete Resnick To: "Peter J. Holzer" Cc: emailcore@ietf.org Date: Thu, 11 Mar 2021 07:28:52 -0600 X-Mailer: MailMate (1.14r5769) Message-ID: <03169C87-E3AB-44B9-A8B7-C77285ABC3AC@episteme.net> In-Reply-To: <20210311131229.GA4576@hjp.at> References: <20210311131229.GA4576@hjp.at> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [Emailcore] Long threads and "References" header (5322 section 3.6.4) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 13:29:06 -0000 On 11 Mar 2021, at 7:12, Peter J. Holzer wrote: > On 2021-03-11 03:24:39 -0200, Viktor Dukhovni wrote: >> I'd like to suggest a recommendation that MUAs keep only a short >> list of the most recent message-ids when appending a new one, keeping >> the overall length of the list below the 998 limit, allowing it to >> fit >> on a single line without folding. > > The References header was originally borrowed from Usenet (IIRC there > was a References header in RFC 822, but with different semantics), so > it > would make sense to adopt the trimming rule, too (some MUAs may > actually > already do this). Trimming was suggested during the DRUMS WG work on 2822 and was rejected at the time. Part of the discussion was that Usenet clients were known to screw it up, but email clients did not. Unless we have current examples of clients that mess this up, I'd be inclined not to re-open the issue. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Thu Mar 11 08:52: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 3B3F13A1394 for ; Thu, 11 Mar 2021 08:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mePFWM_up8kb for ; Thu, 11 Mar 2021 08:52:18 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 2C38B3A132E for ; Thu, 11 Mar 2021 08:52:18 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id d20so21313136qkc.2 for ; Thu, 11 Mar 2021 08:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=FCfAK2ORujj8CnOWcUYDb7V3H2DbCdWRA/MvH/YD9ug=; b=aenonbWBekMNHzQKZxcbxlAdbSxnc6P1HGx/VhFkpOTxaROVNVdk7kp6OTdzZj4iWH m6I82jatNg9gRqqMio7qSVcoHks1/zWAESUQkreLLpMGUiBe7UczFr18f0uFWCqPL7oH UMvm2cWYYDMZFhU5UNqcv3XuMyC8PC98rJfHpImn+TfemUIFxAywAOlp2A82aMzh1bw1 7SeBwDDA4oeqOb+yXxtgkYXuH8xxC8WSlRDnzywpPzAJCXE4VU1WNTK7OhrR/hxw9gXz nIm7sEx6RWRoDC/UZCeOMxhp3j+lU1W1h7cc6ox+db+TgwrOeRsQfQiCHcx2QbTp5S0A dzUg== 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; bh=FCfAK2ORujj8CnOWcUYDb7V3H2DbCdWRA/MvH/YD9ug=; b=GNgqe0RToa00twN7j/FDLSCqyOys2yJD3GCAEWJC3dhp8IT0Tn4AaXbSecveVwjEOd GsBQscVDzjJespytWON+vK+hAV+ep1Z18+SWV9WheT6nZTiqztnM4y00CLIGcyvU36rV dZb04ijEmyXdzchw1dlR2IZhQD4Y2yNIlTLPWm0M7NQNDLI7Y1Bw19HmXX+xUiqkWfz3 bGVcco9sw/nSGsEmdnZODPyv0dj6VNSzXLpkZznHDwFm1ot525Z7IVd2nJ1cad29SOai cRyp2jGGXkM94UQR5P9vTYcSLjtBoguQ2RqykQuytVchGYTMT/2x/6jGchJzG+naMtMh Vxew== X-Gm-Message-State: AOAM531o0hn+fX6UUZTqouNF5odvM+hBMZs9u43C6Ed+0jQBOvzy+b6J p7wgW6FDuYt112HKlV3eRSNoPjMEYkYa68yC+39VnKFEz6GxsA== X-Google-Smtp-Source: ABdhPJyNdYTM4IhqHUfmphbTFk2G2JfoLCFHDS0CHwrV3Rlz9VGa4DmVGjXhbEFWSJdAFeDeO7zNMNrOZJiIqa1H1s8= X-Received: by 2002:a05:620a:954:: with SMTP id w20mr8512286qkw.208.1615481535855; Thu, 11 Mar 2021 08:52:15 -0800 (PST) MIME-Version: 1.0 References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> In-Reply-To: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> From: Todd Herr Date: Thu, 11 Mar 2021 11:52:00 -0500 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="00000000000016105b05bd459b08" Archived-At: Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 11 Mar 2021 16:52:20 -0000 --00000000000016105b05bd459b08 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 10, 2021 at 11:22 PM Viktor Dukhovni wrote: > > On Mar 8, 2021, at 7:40 PM, Todd Herr wrote: > > > > Google: Emits 452, treats 552 as permanent failure > > Microsoft: Emits 550, treats 552 as permanent failure (probably) > > Are you sure that Microsoft emits "5XX" for the N+1st recipient > after accepting N == max configured recipients? > > For what value of "N" are you observing this? Is pipelining a > factor and how far ahead of the server is the client willing to > get before the 5XX responses set in? > I'm sure of nothing. In the context of this working group's work on this ticket, I asked folks who work at various mailbox providers and commercial MTA vendors the following questions: 1. Does your MTA emit status code 552 in response to RCPT TO when there are too many recipients for the current message? 2. If your MTA encounters 552 in response to issuing a RCPT TO command as a client, does it treat it like a 452 code (TEMPFAIL) or 552 (PERMFAIL)? (I also made a point of recommending that they subscribe to this mailing list and participate in the working group's activities.) The answers I received to my questions were reported in my previous post to this thread. > Hard rejecting recipients when <= 100 (the smallest required rcpt > count servers are expected to support per 5321) would be rather > badly broken. There's a good reason why the "too many recipients" > code is expected to be 452, if one wants to force envelopes to be > 99 recipients or fewer. > > At more than 100 recipients, it is still a good idea to reject with > 452, but the client is on shakier ground for wanting to go there, > it should split the envelope barring prior knowledge that the server > is willing to accept more. > > > Proofpoint MTA: No default configuration for too many recipients, > > so emits whatever admin wants; treats 552 as permanent failure. > > Again, 5XX before the 101st recipient just because the envelope > has too many in one go would be wrong. The way to encourage > the sender to split envelopes is to reject the excess ones with > 452. > I'm just the messenger... > > All that said, the RFC text in question is bogus, no client I > know of honours it. > > I believe that's where we landed during the discussion on Wednesday. -- *Todd Herr* | Sr. Technical Program Manager *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. --00000000000016105b05bd459b08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 10, 2021 at 11:22 PM Viktor Dukhovni <ietf-dane@dukhovni.org>= ; wrote:
> On Mar 8, 2021, at 7:40 PM, Todd Herr= <todd.herr@= valimail.com> wrote:
>
> Google: Emits 452, treats 552 as permanent failure
> Microsoft: Emits 550, treats 552 as permanent failure (probably)

Are you sure that Microsoft emits "5XX" for the N+1st recipient after accepting N =3D=3D max configured recipients?

For what value of "N" are you observing this?=C2=A0 Is pipelining= a
factor and how far ahead of the server is the client willing to
get before the 5XX responses set in?

I'm sure = of nothing. In the context of this working group's work on this ticket,= I asked folks who work at various mailbox providers and commercial MTA ven= dors the following questions:
  1. Does your MTA emit status code 552 in= response to RCPT TO when there are too many recipients for the current mes= sage?
  2. If your MTA encounters 552 in resp= onse to issuing a RCPT TO command as a client, does it treat it like a 452 = code (TEMPFAIL) or 552 (PERMFAIL)?
(I also made a point of recomme= nding that they subscribe to this mailing list and participate in the worki= ng group's activities.)

The answers I received to my questions were = reported in my previous post to this thread.


Hard rejecting recipients when <=3D 100 (the smallest required rcpt
count servers are expected to support per 5321) would be rather
badly broken.=C2=A0 There's a good reason why the "too many recipi= ents"
code is expected to be 452, if one wants to force envelopes to be
99 recipients or fewer.

At more than 100 recipients, it is still a good idea to reject with
452, but the client is on shakier ground for wanting to go there,
it should split the envelope barring prior knowledge that the server
is willing to accept more.

> Proofpoint MTA: No default configuration for too many recipients,
> so emits whatever admin wants; treats 552 as permanent failure.

Again, 5XX before the 101st recipient just because the envelope
has too many in one go would be wrong.=C2=A0 The way to encourage
the sender to split envelopes is to reject the excess ones with
452.

I'm just the messenger...

All that said, the RFC text in question is bogus, no client I
know of honours it.


I believe that's where we landed during = the discussion on Wednesday.

--
<= span>

Todd Herr | Sr. Technical Program Manager
<= span style=3D"vertical-align:baseline;white-space:pre-wrap;font-size:small;= font-family:Arial">
m: 703.22= 0.4153

`

This email and all data transmitte= d with it contains confidential and/or proprietary information intended sol= ely for the use of individual(s) authorized to receive it. If you are not a= n intended and authorized recipient you are hereby notified of any use, dis= closure, copying or distribution of the information included in this transm= ission is prohibited and may be unlawful. Please immediately notify the sen= der by replying to this email and then delete it from your system.

--00000000000016105b05bd459b08-- From nobody Thu Mar 11 09:11: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 5907B3A1067 for ; Thu, 11 Mar 2021 09:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aojSTT-EAqNh for ; Thu, 11 Mar 2021 09:11:26 -0800 (PST) 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 30A4B3A0FC2 for ; Thu, 11 Mar 2021 09:11:19 -0800 (PST) Received: from [192.168.1.177] (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 06CC6CBF59 for ; Thu, 11 Mar 2021 12:11:18 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Viktor Dukhovni In-Reply-To: <03169C87-E3AB-44B9-A8B7-C77285ABC3AC@episteme.net> Date: Thu, 11 Mar 2021 15:11:17 -0200 Content-Transfer-Encoding: quoted-printable Reply-To: emailcore@ietf.org Message-Id: References: <20210311131229.GA4576@hjp.at> <03169C87-E3AB-44B9-A8B7-C77285ABC3AC@episteme.net> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Emailcore] Long threads and "References" header (5322 section 3.6.4) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 17:11:28 -0000 > On Mar 11, 2021, at 11:28 AM, Pete Resnick = wrote: >=20 > Trimming was suggested during the DRUMS WG work on 2822 and was = rejected at the time. > Part of the discussion was that Usenet clients were known to screw it = up, but email > clients did not. Unless we have current examples of clients that mess = this up, I'd be > inclined not to re-open the issue. I found a recent example, see below. Folded in the middle of the id = starting with " To: Eric Rescorla , "\" , opsawg In-reply-to: = References: <21BA8D05-DD83-44DE-81B9-457692484CAD@cisco.com> <053b286e-4780-1818-a79d-71b9c967bbd2@sandelman.ca> <20200911114054.184988dc@totoro.tlrmx.org> <7207C73E-FB80-4BD3-AE68-627355B10708@cisco.com> <5F503ED8-38B0-414A-906A-FE8DCF94AC92@cisco.com> = Comments: In-reply-to Eric Rescorla message dated "Wed, 16 Sep 2020 14:02:29 -0700." X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3 MIME-Version: 1.0 Date: Fri, 18 Sep 2020 18:12:51 -0400 Message-ID: <107735.1600467171@dooku> Archived-At: = Subject: Re: [TLS] [OPSAWG] CALL FOR ADOPTION: = draft-reddy-opsawg-mud-tls From nobody Thu Mar 11 09:13: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 907413A14B2 for ; Thu, 11 Mar 2021 09:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmlXApu1RB8I for ; Thu, 11 Mar 2021 09:13:56 -0800 (PST) Received: from wforward3-smtp.messagingengine.com (wforward3-smtp.messagingengine.com [64.147.123.22]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A003A14AF for ; Thu, 11 Mar 2021 09:13:56 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailforward.west.internal (Postfix) with ESMTP id 0BE4E1AF8; Thu, 11 Mar 2021 12:13:54 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 11 Mar 2021 12:13:55 -0500 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 :reply-to:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=RjYuC3y4ropJ/5FP37kBciLM0XK2m uOSDCpUJnNLkJ4=; b=dEGD7lbhmYiciQzEa3y7esJR6RzWv+EOcaXSmMdABcBmx GQckmvE/GXzHYDSGpGvRzsHR1P2qj11a4h4/+nJvQUoDwt2YN8FHBEVd3kaRl09j mF6HKm4S+cvPmuxMkHv7lIor5xHSBjGs5FiDPn1QpaVl4PmAk3oVftTm4hCe2r6J wZeHel0PHHDVNwpOGs1LaLSP2p/+l8nX4HZxpOrE5JDxRw7W1qkaSiGSapZb84K3 0CKLnMXAln0fPvTxBjxb5TSSey6JoTQeg9qKvMLscbNOSBrRE6EYUQTwz6ZeRcls YDvjdwYHWsfjdAzQbmDamgW8lENQVleX0Jj070ndA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvtddgleekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpehruffvfhfhohfkffgfgggjtgfgse htjeertddtfeejnecuhfhrohhmpeffrghvvgcuvehrohgtkhgvrhcuoeguhhgtsegutghr ohgtkhgvrhdrnhgvtheqnecuggftrfgrthhtvghrnhepkedtleffgfdvieduhfdvhefhje dvvdduieekvdeufeeigfetheefgeefvefftedunecuffhomhgrihhnpegssghifidrnhgv thenucfkphepuddtkedrvddviedrudeivddrieefnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepughhtgesuggtrhhotghkvghrrdhnvght X-ME-Proxy: Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) by mail.messagingengine.com (Postfix) with ESMTPA id F3645108006A; Thu, 11 Mar 2021 12:13:52 -0500 (EST) Reply-To: dcrocker@bbiw.net To: emailcore@ietf.org, Viktor Dukhovni References: From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <8da42927-164c-54f6-2b56-f6666ede9d37@dcrocker.net> Date: Thu, 11 Mar 2021 09:13:51 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; 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 Archived-At: Subject: Re: [Emailcore] Long threads and "References" header (5322 section 3.6.4) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 17:13:59 -0000 On 3/10/2021 9:24 PM, Viktor Dukhovni wrote: > As email threads extend into deep chains on lists such as this one, > the list of message-ids appearing in "References:" headers can get > rather long. Indeed. But this is an implementation and/or operations issue, not a protocol one. Some people write overly-long emails. Shall we specify an RFC5322bis trimming rule on the messages? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Mar 11 09:35: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 5302A3A15FD for ; Thu, 11 Mar 2021 09:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bK_4cG-wbAoF for ; Thu, 11 Mar 2021 09:35:06 -0800 (PST) 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 F04103A15FA for ; Thu, 11 Mar 2021 09:35:05 -0800 (PST) Received: from [192.168.1.177] (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 245BFCC068 for ; Thu, 11 Mar 2021 12:35:04 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Viktor Dukhovni In-Reply-To: <8da42927-164c-54f6-2b56-f6666ede9d37@dcrocker.net> Date: Thu, 11 Mar 2021 15:35:03 -0200 Content-Transfer-Encoding: quoted-printable Reply-To: emailcore@ietf.org Message-Id: <7C7C3769-74DB-4705-B106-8AF445D04456@dukhovni.org> References: <8da42927-164c-54f6-2b56-f6666ede9d37@dcrocker.net> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Emailcore] Long threads and "References" header (5322 section 3.6.4) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 17:35:07 -0000 > On Mar 11, 2021, at 3:13 PM, Dave Crocker wrote: >=20 >> As email threads extend into deep chains on lists such as this one, >> the list of message-ids appearing in "References:" headers can get >> rather long. >=20 >=20 > Indeed. But this is an implementation and/or operations issue, not a = protocol one. I very much disagree. The protocol specifies length limits on physical lines of headers, and yet it encourages an ever growing "References" header as messages bounce back and forth in a thread. With message ids of roughly ~64 bytes each, it takes just 16 to cross the physical line limit, and some fraction of clients don't fold (and even unfold) the references list. It makes sense to guard against damage. > Some people write overly-long emails. That's a bit flippant. The SMTP protocol has a "SIZE" parameter that takes care of excessively large message bodies. (Basically never a result of "writing" overly long emails, rather overly large or too many attachments). In normal threaded conversations message sizes do not grow nearly so large, and corruption of the message structure does not result from size limits. > Shall we specify an RFC5322bis trimming rule on the messages? No, the strawman fails common sense. On the other hand, trimming some references, while leaving the oldest = and one or two most recent, preserves all the essential information without bloating the message headers with an ever-growing fragile payload. It is basic robustness. --=20 Viktor. From nobody Thu Mar 11 09:39: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 7C0F73A160A for ; Thu, 11 Mar 2021 09:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a__0_wusAvyx for ; Thu, 11 Mar 2021 09:39:14 -0800 (PST) Received: from wforward3-smtp.messagingengine.com (wforward3-smtp.messagingengine.com [64.147.123.22]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161663A161D for ; Thu, 11 Mar 2021 09:39:13 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailforward.west.internal (Postfix) with ESMTP id A7E851A78; Thu, 11 Mar 2021 12:39:12 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 11 Mar 2021 12:39:12 -0500 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 :reply-to:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=QiipBC8lmsKPK5tGk8/Q4jiIDNdtR nYCVueZgAVKTNM=; b=iyGD843w8bKbW9q5qxLQRvNiWacvLCC0gYEozN87Ib4WV R186CcB99s2pkHg6LfAFmZG2do0//v1hNpbcwt50j3JIf4LlJgxCblWw3lLrT+6H I9AD1nefpyKYMB3tdgB8aQP+09srxAq5GHO9rmHFuI4lpibZDGmRtU5/OsGMtcu4 XfVQWlcuQUzRKCFEdsfmtBuf7vig5OGGr6joTXmqkF+bPlzm2sMEoE8Ec1gc6cCS wRGDb0enbDWu1OzBfASvhKP1Rwh8UU+2FqsOYPIVqHHIAazZaWqhw+pX6OpnfOrw vi2WTA2VHbDq/fSPZZrM2/rOYRrk+aUglbMmiHgIg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvtddguddtfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheprhfuvfhfhfhokffffgggjggtgf esthejredttdefjeenucfhrhhomhepffgrvhgvucevrhhotghkvghruceoughhtgesuggt rhhotghkvghrrdhnvghtqeenucggtffrrghtthgvrhhnpeektdelfffgvdeiudfhvdehhf ejvddvudeikedvueefiefgteehfeegfeevffetudenucffohhmrghinhepsggsihifrdhn vghtnecukfhppedutdekrddvvdeirdduiedvrdeifeenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguhhgtsegutghrohgtkhgvrhdrnhgvth X-ME-Proxy: Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) by mail.messagingengine.com (Postfix) with ESMTPA id DDB151080054; Thu, 11 Mar 2021 12:39:09 -0500 (EST) Reply-To: dcrocker@bbiw.net To: emailcore@ietf.org, Viktor Dukhovni References: <8da42927-164c-54f6-2b56-f6666ede9d37@dcrocker.net> <7C7C3769-74DB-4705-B106-8AF445D04456@dukhovni.org> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Thu, 11 Mar 2021 09:39:08 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <7C7C3769-74DB-4705-B106-8AF445D04456@dukhovni.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Long threads and "References" header (5322 section 3.6.4) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 17:39:16 -0000 On 3/11/2021 9:35 AM, Viktor Dukhovni wrote: >> On Mar 11, 2021, at 3:13 PM, Dave Crocker wrote: >> >>> As email threads extend into deep chains on lists such as this one, >>> the list of message-ids appearing in "References:" headers can get >>> rather long. >> >> >> Indeed. But this is an implementation and/or operations issue, not a protocol one. > > I very much disagree. The protocol specifies length limits on physical > lines of headers, That limit is due to concerns over handling or processing limits, not over human usage limits. You have cast your concern in terms of unwieldiness, not in terms computing limits. > It makes sense to guard against damage. Please document known cases of damage. This is not a new facility. If there are actual problems with it, documentation of computing problems should be readily available. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Mar 11 09: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 2996F3A0934 for ; Thu, 11 Mar 2021 09:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbHfIL3YbPPK for ; Thu, 11 Mar 2021 09:55:33 -0800 (PST) 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 6CE9D3A0935 for ; Thu, 11 Mar 2021 09:55:33 -0800 (PST) Received: from [192.168.1.177] (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 66EF3CBF71 for ; Thu, 11 Mar 2021 12:55:32 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 11 Mar 2021 15:55:32 -0200 Content-Transfer-Encoding: quoted-printable Reply-To: emailcore@ietf.org Message-Id: <179E28BF-0C4C-4F43-926C-BA0C43838D6E@dukhovni.org> References: <8da42927-164c-54f6-2b56-f6666ede9d37@dcrocker.net> <7C7C3769-74DB-4705-B106-8AF445D04456@dukhovni.org> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Emailcore] Long threads and "References" header (5322 section 3.6.4) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 17:55:35 -0000 > On Mar 11, 2021, at 3:39 PM, Dave Crocker wrote: >=20 > Please document known cases of damage. This is not a new facility. = If there are actual problems with it, documentation of computing = problems should be readily available. I posted an example where a message id in the references list was damaged in transit because a physical line length of 999+ bytes resulted from an unfolded References header. Below is another, where the 3rd from last message id: <51E7195E-8B2E-4B83-8 DF7-5A141C531163@inria.fr> got folded and then unfolded and has an extraneous SPACE. This makes threading inaccurate and bloats mail headers: From: "Salz, Rich" To: "openssl-team@openssl.org" Thread-Topic: Birthday attack on long-running 3DES connections Thread-Index: AQHRoCokd7eX7dzmxE6z5Vd5hLYDWZ+rDftAgIUzH4D//77TgA=3D=3D Date: Fri, 29 Jul 2016 13:50:39 +0000 Message-ID: = <777c960c3e98442c837d0fee7b504708@usma1ex-dag1mb1.msg.corp.akamai.com> References: = = = <4F4C55CA-BF5E-454B-B860-A2C3B687B2F5@inria.fr> = <39291F74-CD54-42B2-A37B-B4EBB13A528D@apple.com> = <580F8806-FCAD-4060-8C06-22911368CC23@apple.com> = = <51E7195E-8B2E-4B83-8 DF7-5A141C531163@inria.fr> <7b353861098248b3b9dbcc9d90ddbc47@usma1ex-dag1mb1.msg.corp.akamai.com> <60BDDBFE-B9FF-42E5-92B4-D6FB0E61A0C2@inria.fr> In-Reply-To: <60BDDBFE-B9FF-42E5-92B4-D6FB0E61A0C2@inria.fr> --=20 Viktor. P.S. I set "Reply-To:" to the list. No need to also Cc: me directly. From nobody Thu Mar 11 11:53: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 83CCE3A1058 for ; Thu, 11 Mar 2021 11:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViB22bwHvi57 for ; Thu, 11 Mar 2021 11:53:00 -0800 (PST) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13D113A1056 for ; Thu, 11 Mar 2021 11:52:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id D8C10DA8E55B for ; Thu, 11 Mar 2021 13:52:58 -0600 (CST) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLvu19n5A4eb for ; Thu, 11 Mar 2021 13:52:57 -0600 (CST) Received: from [172.16.1.16] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id F2B86DA8E54D for ; Thu, 11 Mar 2021 13:52:56 -0600 (CST) From: Pete Resnick To: emailcore@ietf.org Date: Thu, 11 Mar 2021 13:52:56 -0600 X-Mailer: MailMate (1.14r5769) Message-ID: In-Reply-To: References: <20210311131229.GA4576@hjp.at> <03169C87-E3AB-44B9-A8B7-C77285ABC3AC@episteme.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [Emailcore] Long threads and "References" header (5322 section 3.6.4) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 19:53:01 -0000 On 11 Mar 2021, at 11:11, Viktor Dukhovni wrote: > I found a recent example, see below. Folded in the middle of the id > starting > with " > -- > Viktor. > > From: Michael Richardson > To: Eric Rescorla , "\" , > opsawg > In-reply-to: > > References: <21BA8D05-DD83-44DE-81B9-457692484CAD@cisco.com> > <053b286e-4780-1818-a79d-71b9c967bbd2@sandelman.ca> > > > <20200911114054.184988dc@totoro.tlrmx.org> > > > <7207C73E-FB80-4BD3-AE68-627355B10708@cisco.com> > > <5F503ED8-38B0-414A-906A-FE8DCF94AC92@cisco.com> > > > > > > > eXiLGD_o91nJ6fGrE_H78BO2noCP1VBnUbOXbr-E2d9MZFg@mail.gmail.com> > > Comments: In-reply-to Eric Rescorla > message dated "Wed, 16 Sep 2020 14:02:29 -0700." > X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3 > MIME-Version: 1.0 > Date: Fri, 18 Sep 2020 18:12:51 -0400 > Message-ID: <107735.1600467171@dooku> > Archived-At: > > Subject: Re: [TLS] [OPSAWG] CALL FOR ADOPTION: > draft-reddy-opsawg-mud-tls Interesting. Bad re-folding. Still parsable under the obsolete syntax, but obviously a problem. Do we know what piece of software did this? Is it Michael's MH? It appears the way you have it in the IMAP archive too, so I expect it's either Michael's or the IETF server; there doesn't appear to be anything in between. If we do address this, perhaps it's part of an "implementation advice" in the A/S instead of in 5322bis. (Yes, there is some implementation advice already in 5322bis, but limiting changes to the base spec seems prudent.) pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Thu Mar 11 13:07: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 C009E3A0BCB for ; Thu, 11 Mar 2021 13:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6EpTOFPFa_h for ; Thu, 11 Mar 2021 13:07:38 -0800 (PST) Received: from haven.eyrie.org (haven.eyrie.org [166.84.7.159]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127CA3A0BC7 for ; Thu, 11 Mar 2021 13:07:38 -0800 (PST) Received: from lothlorien.eyrie.org (unknown [IPv6:2603:3024:160b:400:ae22:bff:fe50:db06]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by haven.eyrie.org (Postfix) with ESMTPS id C324B11855D; Thu, 11 Mar 2021 13:07:36 -0800 (PST) Received: by lothlorien.eyrie.org (Postfix, from userid 1000) id AAC2BB449D2; Thu, 11 Mar 2021 13:07:35 -0800 (PST) From: Russ Allbery To: Pete Resnick Cc: "Peter J. Holzer" , emailcore@ietf.org In-Reply-To: <03169C87-E3AB-44B9-A8B7-C77285ABC3AC@episteme.net> (Pete Resnick's message of "Thu, 11 Mar 2021 07:28:52 -0600") Organization: The Eyrie References: <20210311131229.GA4576@hjp.at> <03169C87-E3AB-44B9-A8B7-C77285ABC3AC@episteme.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Date: Thu, 11 Mar 2021 13:07:35 -0800 Message-ID: <87h7lhcsbs.fsf@hope.eyrie.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Long threads and "References" header (5322 section 3.6.4) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 21:07:40 -0000 Pete Resnick writes: > Trimming was suggested during the DRUMS WG work on 2822 and was rejected > at the time. Part of the discussion was that Usenet clients were known > to screw it up, but email clients did not. Unless we have current > examples of clients that mess this up, I'd be inclined not to re-open > the issue. My recollection (it's been years now, so this may not be entirely correct) is that Usenet had a few other problems: References was absolutely central to the protocol (historically, email is less interested in accurate threading), most clients did not fold the header, and running over 998 octets was common. Also, Usenet had the problem that some agents were doing it entirely wrong: not just misfolding, but trimming by deleting initial message IDs. Usenet servers also put the References header into the overview database, and there are widespread implementations (even INN) that impose hard limits on the total length of overview lines and will malfunction in various ways if the References header gets too long. I don't think most of those concerns apply in the same way to email. -- Russ Allbery (eagle@eyrie.org) From nobody Thu Mar 11 13:16: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 7CF313A0C44 for ; Thu, 11 Mar 2021 13:16:03 -0800 (PST) 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 QzN-NjMN2nFA for ; Thu, 11 Mar 2021 13:16:02 -0800 (PST) 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 2DC903A0AD3 for ; Thu, 11 Mar 2021 13:16:02 -0800 (PST) Received: from [192.168.1.177] (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 F1E4CCC365 for ; Thu, 11 Mar 2021 16:16:00 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 11 Mar 2021 19:16:00 -0200 Content-Transfer-Encoding: quoted-printable Reply-To: emailcore@ietf.org Message-Id: <84A0A56E-45D9-459B-8C5F-EC1F48F3159E@dukhovni.org> References: <20210311131229.GA4576@hjp.at> <03169C87-E3AB-44B9-A8B7-C77285ABC3AC@episteme.net> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Emailcore] Long threads and "References" header (5322 section 3.6.4) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 21:16:04 -0000 > On Mar 11, 2021, at 5:52 PM, Pete Resnick = wrote: >=20 > Interesting. Bad re-folding. Still parsable under the obsolete syntax, = but obviously a problem. The "parseable" status does not always persist, because later in the = thread the SPACE frequently ends up in the middle of a line rather on a line = boundary. I recall seeing much worse mangling resulting from rounds of folding and = unfolding in the past, but these are the examples in my mailbox now. > Do we know what piece of software did this? Is it Michael's MH? Plausibly his MH generated a long unfolded input and then it got folded somewhat crudely (garbage in, garbage out) in transit. > It appears the way you have it in the IMAP archive too, so I expect > it's either Michael's or the IETF server; there doesn't appear to > be anything in between. Yes, I expect it is both. Michael unfolded, and the server refolded. > If we do address this, perhaps it's part of an "implementation advice" > in the A/S instead of in 5322bis. (Yes, there is some implementation > advice already in 5322bis, but limiting changes to the base spec seems > prudent.) I'd prefer to have be in whichever document is more likely to be read by implementors. Perhaps just talking about it on mailop and ietf-smtp once there is a published document to lean back on is really the best way to have it addressed in current implementations. I still think a change is warranted in 5322, which specifically = recommends to keep appending (regardless of current length). There's no good = reason to keep growing that header without bounds. --=20 Viktor. From nobody Thu Mar 11 13:19: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 433EE3A0C5D; Thu, 11 Mar 2021 13:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eoxbds6u8BAX; Thu, 11 Mar 2021 13:19:04 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71BBF3A0C59; Thu, 11 Mar 2021 13:19:01 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lKShw-00047H-4b; Thu, 11 Mar 2021 16:19:00 -0500 Date: Thu, 11 Mar 2021 16:18:54 -0500 From: John C Klensin To: Todd Herr , emailcore@ietf.org Message-ID: <9A7BDB22F3A0396EF24BF91D@PSB> In-Reply-To: References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@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] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 11 Mar 2021 21:19:06 -0000 --On Thursday, March 11, 2021 11:52 -0500 Todd Herr wrote: >... >> All that said, the RFC text in question is bogus, no client I >> know of honours it. > I believe that's where we landed during the discussion on > Wednesday. What I had not done on Wednesday, or recently enough before then, was to carefully read the entirety of Section 4.5.3.1.10, which explicitly calls for the behavior someone, I think you, mentioned in a previous message, i.e., server accepts recipients up to the limit, then generates a 452 for each succeeding RCPT command. Client then continues processing with the recipients up to that point, sends the message, and then requeues the message for additional recipients. And the client is expected to treat a 552 in response to RCPT as if it were a 452. Nothing there prohibits the client from sending messages to the recipient addresses who got the 452 (or 552) one at a time or even treating the very first 452 (or 552) as an indication that it should send QUIT or RSET and start sending the message in one recipient at a time mail transactions. It also provides for the server to indicate to the client that it is just not willing to accept mail transactions with a number of recipients larger than it wants to accept with a 503 response after DATA. Up to that point, I think the text is consistent with what we have been told about current practice, including treating a 552 response code as if it were temporary. Referring back to Wednesday's discussion and slide (I believe Slide 6), the sentence highlighted is entirely consistent with current practice and probably needed to keep that practice valid. If it is in need to changing, it would be to change the SHOULD to a MUST since that appears to be what everyone is doing anyway. I personally think that would be a bad idea because we have no way of knowing about all possible cases and that change probably wouldn't accomplish anything anyway. That suggests that, if changes are needed, there are probably three of them, the first two in the third paragraph of that section ("If an SMTP server has..."), not in the first one: (1) As I have suggested elsewhere, more explanatory cross-references in this over-complicated document would be a good idea. So: OLD: If an SMTP server has an implementation limit on the number of RCPT commands and this limit is exhausted, NEW/PROPOSED: If an SMTP server has an implementation limit on the number of RCPT commands and this limit is exhausted (See Section 7.8), Comment: Section 7.8 ("Resistance to Attacks"), which explicitly mentions large numbers of recipients, is not quite right for this. More generally, we've talked informally about flexibility for "operational necessity" for years (I even used that phrase in G.1) but it does not appear elsewhere in the document. I think it would be helpful to clarity to re-title 7.8 to "Resistance to Attacks and Local Operational Requirements" (or something similar) and probably to add a sentence or two there that would indicate that attack resistance is not the only issue that might justify local restrictions. If people agree, text welcome. Alexey, I have tentatively added the above as G.15. Unless no one agrees that the above is at least worth further discussion, please make a ticket. (2) That paragraph also says that the server MUST use a 452 response code in the "too many recipients" case. I think we should be reluctant to remove the recommendation. Especially given the "look at first digit only" rule, 452 is clearly better than 552. However, if people are uncomfortable with a MUST that is generally violated, I recommend a SHOULD with an additional sentence that indicates that many implementations do not follow that recommendation. The only justification I can think of for removing the recommendation entirely would be if harm was generally caused if 452 were returned. Given the "examine first digit" rule. it is hard to imagine such harm except in implementations that are seriously broken. (3) Unless we are going to overhaul things in ways radically different from the above and unless anyone has serious objections (and raises them soon) I intend to patch Section 4 to better indicate the role of "too many recipients" codes in the scheme of things. john From nobody Thu Mar 11 14:07: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 2B8AC3A0EEE for ; Thu, 11 Mar 2021 14:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-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=IFcQTyqp; dkim=pass (2048-bit key) header.d=wizmail.org header.b=RtIa5lrW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kngqe68c7ocm for ; Thu, 11 Mar 2021 14:07:52 -0800 (PST) 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 C7A1A3A0EEC for ; Thu, 11 Mar 2021 14:07:52 -0800 (PST) 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=D46J2oZLyt1Z7ZM/Jkq69miAY8nvtt9YbDYGshR/E7Y=; b=IFcQTyqp4NYwkuX03JNR6BVFNq tKorIwShpr3NVumSY/3gzS423pTkNuKFy/68IPRptZ6UW3EmDN29a6k0YYAg==; 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=D46J2oZLyt1Z7ZM/Jkq69miAY8nvtt9YbDYGshR/E7Y=; b=RtIa5lrWbbtJZ0lO9/+hY9CnpN VUkpD2el7v4e4ul8JStDtiA0bJo3moQGw9PbrqzaYKZR6stAQrWUWEGaQW5p8SqHbRqvDO+qVxn5Q uuABSgovyJvjuczmMEXAy+4WK1Rd2DTE5n4HYPaEYH+cWApDSDGCi4smddtRbMFJBu/0srq2pRLZ0 AfwwgRohwIuRVLaZRjIwrYb29buJl0d7kqEFcOyjhPGCpNKaQRxv5vT4iUH2gnC8YsKIzVxqavAyC H7DP7fyQN4MVtcCrkUVDoHIhT/XG0O89HW9E8Ob7VqH7IL3JLcIyRKhhfVa6+SacB3cVWY667z58y d0nVlPjg==; 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.116) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1lKTTB-00259P-Kj for emailcore@ietf.org (return-path ); Thu, 11 Mar 2021 22:07:49 +0000 To: emailcore@ietf.org References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> From: Jeremy Harris Message-ID: <397cc52c-5533-12a2-6ca2-e46f5987105c@wizmail.org> Date: Thu, 11 Mar 2021 22:07:49 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <9A7BDB22F3A0396EF24BF91D@PSB> 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 #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 11 Mar 2021 22:07:57 -0000 On 11/03/2021 21:18, John C Klensin wrote: > If it > is in need to changing, it would be to change the SHOULD to a > MUST since that appears to be what everyone is doing anyway. No, it is not. Exim does not treat a received 5xx as a 4xx. -- Cheers, Jeremy From nobody Thu Mar 11 15:30:00 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 778503A138B for ; Thu, 11 Mar 2021 15:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 54pLB-GWS-oc for ; Thu, 11 Mar 2021 15:29:56 -0800 (PST) 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 8D71C3A1384 for ; Thu, 11 Mar 2021 15:29:56 -0800 (PST) Received: from [192.168.1.177] (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 CADEECC951 for ; Thu, 11 Mar 2021 18:29:55 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Viktor Dukhovni In-Reply-To: <9A7BDB22F3A0396EF24BF91D@PSB> Date: Thu, 11 Mar 2021 21:29:55 -0200 Content-Transfer-Encoding: 7bit Reply-To: emailcore@ietf.org Message-Id: <5772045E-2EB3-44B7-BCA8-0135DF809C62@dukhovni.org> References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 11 Mar 2021 23:29:59 -0000 > On Mar 11, 2021, at 7:18 PM, John C Klensin wrote: > > That suggests that, if changes are needed, there are probably > three of them, the first two in the third paragraph of that > section ("If an SMTP server has..."), not in the first one: > > (1) As I have suggested elsewhere, more explanatory > cross-references in this over-complicated document would be a > good idea. So: > > OLD: > If an SMTP server has an implementation limit on the > number of RCPT commands and this limit is exhausted, > > NEW/PROPOSED: > If an SMTP server has an implementation limit on the > number of RCPT commands and this limit is exhausted (See > Section 7.8), I am having trouble piecing together the fragments here, with context not present in this message. Therefore, I am posting a proposed update with commentary: 4.5.3.1.10. Too Many Recipients Code RFC 821 [1] incorrectly listed the error where an SMTP server exhausts its implementation limit on the number of RCPT commands ("too many recipients") as having reply code 552. The correct reply code for this condition is 452. The above is correct and needs no changes. Clients SHOULD treat a 552 code in this case as a temporary, rather than permanent, failure so the logic below works. The above is not followed by any of the major MTAs (Exim, Postfix, or Sendmail, nor any others reported). It MUST be scrapped. If the server responds with 552, the recipient in question will almost always be immediately bounced by the sending client. Note, that the 552 in reply to "RCPT" will not be taken to mean anything about the message as a whole, earlier or subsequent recipients. If any recipients are ultimately not rejected the partially accepted message envelope will be relayed by the client unless the server rejects the "DATA" command. There are no clients that abort the MAIL transaction to start again with smaller recipient batches. Some could take 552 (when not too deeply pipelined) as a single to defer even recipients not yet mentioned, that'd be fine. I don't know of any that do that. Instead clients typically limit the number of recipients per envelope to somewhere south of 100 (perhaps hand-tuned for mail destined to some of the 800lb gorilla providers), and just send all the RCPT commands they intended to send, with perhaps the tail of the list ending up deferred. When a conforming SMTP server encounters this condition, it has at least 100 successful RCPT commands in its recipients buffer. If the server is able to accept the message, then at least these 100 addresses will be removed from the SMTP client's queue. I wish that were true. It would certainly aid interoperability. But the said 800lb gorilla providers have felt free to dictate arbitrary limits below the RFC requirements, and the rest of us have needed to make adjustments if we want to deliver list mail to these players. So long as the server is willing to defer (4XX) 100-N recipients or more without prejudicing any it already accepted, it will interoperate with clients that expect to be able to send up to 100, despite the lower limit. If a server both sets a lower limit, and prevents clients that overshoot that limit from sending even the initially accepted recipients, then the server is outside the interoperability regime defined by the specification. Email to the server will only work if clients are willing to hand-tune their MTAs for the server in question. Such hand-tuning is not always possible by server name or IP (in Postfix we can only hand tune envelope recipient counts by destination domain, before the domain's MX hosts are known). Therefore, such servers are particularly likely to impede email delivery when acting as MX hosts for a large and varying set of email domains. When the client attempts retransmission of those addresses that received 452 responses, at least 100 of these will be able to fit in the SMTP server's recipients buffer. Each retransmission attempt that is able to deliver anything will be able to dispose of at least 100 of these recipients. Largely correct, except that again with the 800lb crowd the actual number may be well south of 100. And yet even the 800 pounders should not feel quite so much at liberty to violate the specs. Don't know what other MTAs, but Postfix expects the server (by default) to accept 50 recipients without friction. Another reason for fewer than 100 is when servers want have the envelope split by some server-specific classification of recipients, that may affect recipient-specific downstream content transformations. In such a case the server might 452 every recipient in a class that is different from that of the first accepted recipient. The remaining recipient classes would then need to be tried in a separate transaction. Such a policy is risky when the number of distinct recipient classes is more than a "handful", as a message sent to a large list may then require more retries than a client is able to schedule before the message expires. On the other hand, messages with a large number recipients are most often sent by mailing-list software that does automated bounce processign, and arranges for each recipient to be associated with a separate envelope sender address, so that bounces can be tracked back to the intended recipient. Only large mailings by an occasional human to a large list of friends, romans, countrymen, ... If an SMTP server has an implementation limit on the number of RCPT commands and this limit is exhausted, it MUST use a response code of 452 (but the client SHOULD also be prepared for a 552, as noted above). Yes, the server MUST respond with 452 when the intent is to have the client "split the envelope", and send the remaining recipients that were not accepted in a separate batch. If, on the other hande, based on the sequence of presented recipient addresses the server has somehow concluded that the client is a spammer, it can of course with full knowledge of the fact that the recipients will NOT be retried, send 552 or better yet at that point, 554. If the server has a configured site-policy limitation on the number of RCPT commands, it MAY instead use a 5yz response code. In particular, if the intent is to prohibit messages with more than a site-specified number of recipients, rather than merely limit the number of recipients in a given mail transaction, it would be reasonable to return a 503 response to any DATA command received subsequent to the 452 (or 552) code or to simply return the 503 after DATA without returning any previous negative response. This is problematic and generally pointless. It serves no purpose and breaks interoperability. Clients can always send multiple copies in separate envelopes, so such absolute limits (below 100) damage interoperability and don't achieve the desired goal of actually stopping the same message arriving to more than a given number of recipients. The solution is quite simple delete the above text, the overall picture is much simpler. Respond with 4XX to defer and 5XX to permanently reject a given RCPT. There's no reason for the specification to dwell on all the creative ways in which a decision to reject might be made. The key thing in this section is to specify that "452" MUST be used when the client should retry the recipient separately because too many were sent so far to process in a single batch on the server. The number of "452" replies the server is willing to send without blocking message delivery or imposing punitive delays that'll prevent transaction completion needs to be at least 100 minus the number of initially accepted recipients. -- Viktor. From nobody Thu Mar 11 17:13: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 98DE63A1696 for ; Thu, 11 Mar 2021 17:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLiAWsS4Ssvu for ; Thu, 11 Mar 2021 17:13:36 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E54A3A1695 for ; Thu, 11 Mar 2021 17:13:36 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lKWMv-000533-GK; Thu, 11 Mar 2021 20:13:33 -0500 Date: Thu, 11 Mar 2021 20:13:27 -0500 From: John C Klensin To: Jeremy Harris , emailcore@ietf.org Message-ID: In-Reply-To: <397cc52c-5533-12a2-6ca2-e46f5987105c@wizmail.org> References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <397cc52c-5533-12a2-6ca2-e46f5987105c@wizmail.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@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 01:13:38 -0000 --On Thursday, March 11, 2021 22:07 +0000 Jeremy Harris wrote: > On 11/03/2021 21:18, John C Klensin wrote: >> If it >> is in need to changing, it would be to change the SHOULD to a >> MUST since that appears to be what everyone is doing anyway. > > > No, it is not. Exim does not treat a received 5xx as a 4xx. Jeremy, I'm happy staying with MUST --up to the WG-- but would, on principle, like to understand what EXIM is doing and why. In particular, a mail transaction, with EXIM as client, looks like: [...] MAIL FROM: 250 ... RCPT TO: 250 ... RCPT TO: 250 ... RCPT TO: 250 ... [...] RCPT TO: 552 ... Now, upon getting that first 552, does EXIM (1) Assume it is really like a 550, i.e., that is, at least for traffic coming from , a more or less permanently unavailable or non-existent address, continue with other addresses, but never retry and basically tell whomever or whatever you got the message from that it is undeliverable for that address. If so, continue that "no retry" behavior for and the (potentially) hundreds of addresses that follow. (2) Take the first one of those (the one with ) as a fatal error for more RCPT commands as a class, skip any other target addresses you have queued up, and move immediately to DATA (or, in principle, some extension-enabled command). If this option is taken, the status of the addresses in that first problem RCTP command and those not sent at all is uncertain relative to actions outside the mail transaction. (3) Assume it really is a fatal error (based on the "first digit" rule, treating it more like 554, or assuming that the server is really out of memory and would not be able to accept DATA or the content that follows) and send either RSET or QUIT as the next command. Again, status relative to trying again is not specified. In particular, the spec would allow the client to give up and bounce the message, try again with the same address list, or try again with a subset of that list, including opting for one mail transaction per recipient with each getting a copy of the same message. If one does not follow the advice about treating 552 as if were 452 and basically ignores Section 4.5.3.1.10 (since, wrt 552, it offers no alternate interpretation), I can justify any of the above on the basis of text I can find in 5321. I may be missing something (wouldn't be the first time, even this week), but that looks like it. So what does exim actually do? For everyone else: is there any desire to narrow the options in 5321bis so that guidance is given as to which of the above options is acceptable? Note that if we do so, we move into the territory of telling implementations what to do (which the spec does already) and then telling them what to do if they ignore the first requirement/instruction, a strategy to which the IESG has been known to take exception even if no one objects on Last Call. john From nobody Thu Mar 11 18:16: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 17BF23A0FEA for ; Thu, 11 Mar 2021 18:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbFSpPGnh8fV for ; Thu, 11 Mar 2021 18:16:49 -0800 (PST) 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 51B363A0FE7 for ; Thu, 11 Mar 2021 18:16:49 -0800 (PST) Received: from [192.168.1.177] (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 1FEDDCCC07 for ; Thu, 11 Mar 2021 21:16:48 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 12 Mar 2021 00:16:47 -0200 Content-Transfer-Encoding: 7bit Reply-To: emailcore@ietf.org Message-Id: <6FC2E8E6-334A-4C4B-9FB6-A0F2805C4A31@dukhovni.org> References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <397cc52c-5533-12a2-6ca2-e46f5987105c@wizmail.org> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 02:16:51 -0000 > On Mar 11, 2021, at 11:13 PM, John C Klensin wrote: > > [...] > MAIL FROM: > 250 ... > RCPT TO: > 250 ... > RCPT TO: > 250 ... > RCPT TO: > 250 ... > [...] > RCPT TO: > 552 ... > > Now, upon getting that first 552, does EXIM It is time to introduce an analogy to a famous Gary Larson THE FAR SIDE cartoon, "What dogs hear": https://www.flickr.com/photos/sluggerotoole/153603564 The server may yell: ... 250 at your service 250 at your service 552 too many recipients. 552 too many recipients. 552 too many recipients. ... But all the sending client hears is: ... 2.. ... 2.. ... 5.. ... 5.. ... 5.. ... ... the client will stash away the full error code and text for inclusion in the bounce, just in case some user or postmaster can make some sense of it, but otherwise all those carefully specified digits in the SMTP RFCs play no role whatsoever. Servers are far too likely to send some random 5XX code that does not mean exactly what the RFC intends it to mean, and in any case the last two digits make no difference, the command is either accepted, soft-failed or rejected permanently, and the first digit had better signal that correctly, the rest is irrelevant forensic information for whoever might care to read the tea leaves. > (1) Assume it is really like a 550, i.e., that > is, at least for traffic coming from > , a more or less permanently unavailable or > non-existent address, continue with other addresses, but never > retry and basically tell whomever or > whatever you got the message from that it is undeliverable for > that address. This of course, and ditto with Postfix, Sendmail, or any other mainstream MTA you're like to run across. > If so, continue that "no retry" behavior for > and the (potentially) hundreds of addresses > that follow. Sure, but any mainstream MTA will not send 100's of addresses in a single envelope to strangers, since there's no reason to expect the remote peer to be willing to accept more than 100 recipients, and by the time the message transaction has been amortised over 100 recipients most of the benefit of batching has been achieved. Also list managers typically send mail to one recipient at a time (VERP), and people rarely send mail to more than 100 readers, so larges envelopes beyond first O(100) don't have any measurable positive impact on MTA throughput. > If one does not follow the advice about treating 552 as if were > 452 and basically ignores Section 4.5.3.1.10 (since, wrt 552, it > offers no alternate interpretation), I can justify any of the > above on the basis of text I can find in 5321. I may be missing > something (wouldn't be the first time, even this week), but that > looks like it. Any such justification is divorced from the "What dogs hear" reality, did the server say "2..", "4.." or "5.."? > So what does exim actually do? Naturally, treats the "2XX" recipients as delievered (assuming DATA or BDAT LAST was accepted), retries the "4XX" recipients separately, and bounces the "5XX" recipients. That's the only correct client behaviour. > For everyone else: is there any desire to narrow the options in > 5321bis so that guidance is given as to which of the above > options is acceptable? Regardless of what the RFC says, client MTAs will continue to be dogs. The RFC can align with this reality or live in some make believe alternative universe. -- Viktor. From nobody Thu Mar 11 19:09: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 AE2C53A1B61 for ; Thu, 11 Mar 2021 19:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBXuBvYOMbwq for ; Thu, 11 Mar 2021 19:08:58 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A753A1B5F for ; Thu, 11 Mar 2021 19:08:58 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lKYAa-0005bF-Re for emailcore@ietf.org; Thu, 11 Mar 2021 22:08:56 -0500 Date: Thu, 11 Mar 2021 22:08:50 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: <1F8CB46BBE3C0D5C4EB49C96@PSB> In-Reply-To: <5772045E-2EB3-44B7-BCA8-0135DF809C62@dukhovni.org> References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <5772045E-2EB3-44B7-BCA8-0135DF809C62@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] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 03:09:01 -0000 Hi. This is another long note, so a semi-summary first although I would encourage everyone to read all the way through. I think Victor's note exposes two key issues and a couple of things not directly related to this ticket: (1) Independent (at least for now) about what clients do when they get a 552, have enough servers switched to sending 452 rather than 552 when "too many recipients" is intended that the text about interpretation of the 552 code as a 4yz one can actually be removed (or retained only in an historical note). (2) As I read Victor's note, there were many places where my response was "that is what the spec say to do already". That implies that either Victor and I are reading the same text differently (in which case I think some clarification effort is in order) or that he and I are having problems understanding each other. I don't yet have a strong opinion as to which it is; probably his response to this note will help with that. In addition... * The requirement of 100 minimum recipients is a key part of Victor's explanation. We may need to look at that type of limit as well as the "size" ones that are now part of ticket #14 (whether there or in a separate ticket). However, if we want to minimize changes, I believe that the "operational necessity" principle (see prior note) is sufficient to cover that case. * Victor has made the 100 pound Gorilla argument. I think that argument is a serious challenge for the WG and its decisions about scope and goals. I'll try to address that soon in a separate note. Again, please keep reading. --On Thursday, March 11, 2021 21:29 -0200 Viktor Dukhovni wrote: >> On Mar 11, 2021, at 7:18 PM, John C Klensin >> wrote: >> >> That suggests that, if changes are needed, there are probably >> three of them, the first two in the third paragraph of that >> section ("If an SMTP server has..."), not in the first one: >... >> NEW/PROPOSED: >> If an SMTP server has an implementation limit on the >> number of RCPT commands and this limit is exhausted (See >> Section 7.8), > I am having trouble piecing together the fragments here, with > context not present in this message. Sorry. Was trying to keep the message from getting even longer... and to encourage people to read the entire section. > Therefore, I am posting > a proposed update with commentary: > > 4.5.3.1.10. Too Many Recipients Code > > > RFC 821 [1] incorrectly listed the error where an SMTP > server exhausts its implementation limit on the number of > RCPT commands ("too many recipients") as having reply code > 552. The correct reply code for this condition is 452. > > > The above is correct and needs no changes. Good. We are on the same page so far. > > Clients SHOULD treat a > 552 code in this case as a temporary, rather than > permanent, failure so the logic below works. > > The above is not followed by any of the major MTAs (Exim, > Postfix, or Sendmail, nor any others reported). It MUST be > scrapped. If the server responds with 552, the recipient in > question will almost always be immediately bounced by the > sending client. For whatever it is worth, I don't know what it means to "bounce a recipient". The spec only talks about bouncing messages. More important, I would hope that the client would accumulate undeliverable addresses and include them in a single "bounce" message, not send one bounce message per undeliverable recipient for reasons I hope are obvious. The former is certainly consistent with behavior I've observed with other 5yz responses to RCPT commands. "Immediately" would imply one bounce message per recipient. And, of course, if the the SMTP sender getting the 552 message from its receiver is operating in some sort of relay mode so it can simply return the code in real time to whatever it got the message from, that changes the story (and is not what we usually think of as a "bounce". But see below. > Note, that the 552 in reply to "RCPT" will not be taken to mean > anything about the message as a whole, earlier or subsequent > recipients. If any recipients are ultimately not rejected the > partially accepted message envelope will be relayed by the > client unless the server rejects the "DATA" command. See my questions to Jeremy, but, if that is what they are doing, then they are conforming to the requirement to treat 552 as 442, because that is exactly the behavior one would expect 442 to do. Whether they (or you) think about that as conforming behavior doesn't make a lot of difference. If there is a difference it is in your suggestion above about an immediate bounce. And that immediate bounce, or even returning the 552 code to an earlier SMTP sender, raises another problem. One of the most important principles in SMTP-land, going back to 821, is that one does not report a message as undeliverable and then deliver it anyway. "Delayed" messages are an odd case for which 821-> 2821-> 5321 do not have any provision, but, if the message (or, if you prefer, address) is bounced, that is the end of it -- the only way that message is going to be delivered to that recipient is if the originator creates and sends what, as far as SMTP is concerned, is a new message. > There are no clients that abort the MAIL transaction to start > again with smaller recipient batches. Some could take 552 > (when not too deeply pipelined) as a single to defer even > recipients not yet mentioned, that'd be fine. I don't know of > any that do that. Good. Again, you are describing behavior consistent with the client treating the 552 as equivalent to 452 (or some other 4yz code). > Instead clients typically limit the number of recipients per > envelope to somewhere south of 100 (perhaps hand-tuned for mail > destined to some of the 800lb gorilla providers), and just send > all the RCPT commands they intended to send, with perhaps the > tail of the list ending up deferred. Again, consistent with treating the 552 as a 442, whether they precisely follow the rest of the description in that section or not. > > When a conforming SMTP server encounters this condition, it > has at least 100 successful RCPT commands in its recipients > buffer. If the server is able to accept the message, then > at least these 100 addresses will be removed from the SMTP > client's queue. > > I wish that were true. It would certainly aid > interoperability. But the said 800lb gorilla providers have > felt free to dictate arbitrary limits below the RFC > requirements, and the rest of us have needed to make > adjustments if we want to deliver list mail to these players. > So long as the server is willing to defer (4XX) 100-N > recipients or more without prejudicing any it already > accepted, it will interoperate with clients that expect to be > able to send up to 100, despite the lower limit. But that is an issue with the current semi-hard limit of a minimum or 100, not with the 452/552 requirements. And, while the text is not as precise as we might like it, clients (and, for that matter servers) are allowed to pick lower limits under the "Resistance to Attack" / Operational necessity principle. So there is nothing in the above that is non-conforming, even to the current text in 4.5.3.1.10. And, fwiw, I note your explanation above uses "defer" and "4XX" together, not 552. > If a server both sets a lower limit, and prevents clients that > overshoot that limit from sending even the initially accepted > recipients, then the server is outside the interoperability > regime defined by the specification. Email to the server will > only work if clients are willing to hand-tune their MTAs for > the server in question. Such hand-tuning is not always > possible by server name or IP (in Postfix we can only hand > tune envelope recipient counts by destination domain, before > the domain's MX hosts are known). Therefore, such servers are > particularly likely to impede email delivery when acting as MX > hosts for a large and varying set of email domains. Yes. And still consistent with what 5321bis says. In particular, note the comments in the first paragraph of Section 7.9. > > > When the client attempts retransmission of those addresses > that received 452 responses, at least 100 of these will be > able to fit in the SMTP server's recipients buffer. Each > retransmission attempt that is able to deliver anything > will be able to dispose of at least 100 of these recipients. > > Largely correct, except that again with the 800lb crowd the > actual number may be well south of 100. And yet even the 800 > pounders should not feel quite so much at liberty to violate > the specs. Don't know what other MTAs, but Postfix expects the > server (by default) to accept 50 recipients without friction. See above. And a separate note to follow about the 800lb argument. > Another reason for fewer than 100 is when servers want have the > envelope split by some server-specific classification of > recipients, that may affect recipient-specific downstream > content transformations. In such a case the server might 452 > every recipient in a class that is different from that of the > first accepted recipient. The remaining recipient classes > would then need to be tried in a separate transaction. Again, 5321 now allows clients and/or servers to pick a limit lower than 100 and encourages / specifies orderly behavior when that is done. Modulo the recommendation to use 452 for clarity rather than 552, that is what everyone you have described seems to be doing in practice. > Such a policy is risky when the number of distinct recipient > classes is more than a "handful", as a message sent to a large > list may then require more retries than a client is able to > schedule before the message expires. Yep. If you think it is useful for either 5321bis or the A/S to explicitly point that out and discuss it, please suggest how and where to do that. My personal guess (and so-far weak) preference is that the A/S is headed for a discussion of the practical issues and tradeoffs associated with the various cases and options. In particular, from the standpoint of 5321 "more retries... before the message expires" is not 5231bis-level SMTP problem. > On the other hand, messages with a large number recipients are > most often sent by mailing-list software that does automated > bounce processign, and arranges for each recipient to be > associated with a separate envelope sender address, so that > bounces can be tracked back to the intended recipient. > > Only large mailings by an occasional human to a large list of > friends, romans, countrymen, ... Agreed. See above. Independent of where I stand personally, I suggest that any attempt to further expand Section 3.9 to talk about these issues would get considerable resistance from within the WG, including from (but not limited to) those who have suggested that 3.9 be removed entirely. That is another argument for taking the above discussion to the A/S. > > If an SMTP server has an implementation limit on the number > of RCPT commands and this limit is exhausted, it MUST use a > response code of 452 (but the client SHOULD also be > prepared for a 552, as noted above). > > Yes, the server MUST respond with 452 when the intent is to > have the client "split the envelope", and send the remaining > recipients that were not accepted in a separate batch. > > If, on the other hande, based on the sequence of presented > recipient addresses the server has somehow concluded that the > client is a spammer, it can of course with full knowledge of > the fact that the recipients will NOT be retried, send 552 or > better yet at that point, 554. Agreed. And I think that is what the text says. If you think it needs clarification to distinguish between those two cases, please say so and encourage opening of another ticket. > > If the server has a configured site-policy > limitation on the number of RCPT commands, it MAY instead > use a 5yz response code. In particular, if the intent is > to prohibit messages with more than a site-specified number > of recipients, rather than merely limit the number of > recipients in a given mail transaction, it would be > reasonable to return a 503 response to any DATA command > received subsequent to the 452 (or 552) code or to simply > return the 503 after DATA without returning any previous > negative response. > This is problematic and generally pointless. It serves no > purpose and breaks interoperability. Clients can always send > multiple copies in separate envelopes, so such absolute limits > (below 100) damage interoperability and don't achieve the > desired goal of actually stopping the same message arriving to > more than a given number of recipients. But that is precisely intended to allow for the 552/554 response you are suggesting above. So, "pointless", perhaps not. More confusing than it ought to be, maybe. Suggestions welcome. > The solution is quite simple delete the above text, the > overall picture is much simpler. Respond with 4XX to defer > and 5XX to permanently reject a given RCPT. There's no reason > for the specification to dwell on all the creative ways in > which a decision to reject might be made. However, what I thought we heard Wednesday morning was that a number of servers continue to send 552 where 452 is now preferred ("preferred" may be a little weak). As long as that is the case, then the purpose of that extended section is to try to explain ways to handle the situation, including both receiving 452 and receiving 552 in a situation where it is intended to be interpreted as 452. If we are convinced that all of the SMTP servers on the Internet (or enough that others don't count -- and I'm counting gorillas who feel free to define their own standards as one each, not by their user or daily message counts) have followed the advice of 5321 so that no server is any longer sending 552 when 452 (and breaking up the mail transaction and resending) is intended, then the section should be significantly reworked, possibly including a historical note for servers that are still in existence but we cannot identify. > The key thing in this section is to specify that "452" MUST be > used when the client should retry the recipient separately > because too many were sent so far to process in a single batch > on the server. The number of "452" replies the server is > willing to send without blocking message delivery or imposing > punitive delays that'll prevent transaction completion needs > to be at least 100 minus the number of initially accepted > recipients. And, modulo the limit of 100, which I continue to believe is either a separate issue or no problem at all given the current text in 5321, I believe that is exactly what that current text says. Again, suggested clarification welcome. john From nobody Thu Mar 11 20:51: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 B81B93A1808 for ; Thu, 11 Mar 2021 20:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 IlFGf80oZhIx for ; Thu, 11 Mar 2021 20:51:54 -0800 (PST) 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 B80CB3A1807 for ; Thu, 11 Mar 2021 20:51:54 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id DA1A2CC7F9; Thu, 11 Mar 2021 23:51:51 -0500 (EST) Date: Thu, 11 Mar 2021 23:51:51 -0500 From: Viktor Dukhovni To: emailcore@ietf.org Message-ID: Reply-To: emailcore@ietf.org References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <5772045E-2EB3-44B7-BCA8-0135DF809C62@dukhovni.org> <1F8CB46BBE3C0D5C4EB49C96@PSB> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1F8CB46BBE3C0D5C4EB49C96@PSB> Archived-At: Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 04:51:57 -0000 On Thu, Mar 11, 2021 at 10:08:50PM -0500, John C Klensin wrote: > (1) Independent (at least for now) about what clients do when they get > a 552, have enough servers switched to sending 452 rather than 552 > when "too many recipients" is intended that the text about > interpretation of the 552 code as a 4yz one can actually be removed > (or retained only in an historical note). I two decades of monitoring the Postfix users list, I've seen no reports that I can recall of users having problems delivering mail to some recipients due to servers incorrectly replying 552 when an envelope size limit is exceeded. For any 5XX "RCPT" response, Postfix arranges to bounce the message for the recipient in question (delayed until all currently scheduled recipients are delivered, deferred or fail, and thus consolidated across affected failed recipients), so any non-negligible population of problem servers would have surfaced at least a few times in the last 20 years. > (2) As I read Victor's note, there were many places where my response > was "that is what the spec say to do already". That implies that > either Victor and I are reading the same text differently (in which > case I think some clarification effort is in order) or that he and I > are having problems understanding each other. Likely some of both, but I think more on the communication side. Absent nods in acknowledgement or quizzical looks, it is much to hard to know when to keep it brief and when to elaborate a point. Async communication is fundamentally limited here, especially when multicast, and not every reader needs the same level of detail. > * Victor has made the [800] pound Gorilla argument. I think that > argument is a serious challenge for the WG and its decisions about > scope and goals. I'll try to address that soon in a separate note. > > > > Clients SHOULD treat a > > 552 code in this case as a temporary, rather than > > permanent, failure so the logic below works. > > > > > The above is not followed by any of the major MTAs (Exim, > > Postfix, or Sendmail, nor any others reported). It MUST be > > scrapped. If the server responds with 552, the recipient in > > question will almost always be immediately bounced by the > > sending client. > > For whatever it is worth, I don't know what it means to "bounce > a recipient". It means that the message will not be delivered for that recipient, and if any bounce is to be sent (non-empty envelope sender and not DSN NOTIFY=..., which excludes failure), then this recipient will be reported in the bounce. Redundantly, overeloborating the point, the recipient WILL NOT be included in any attempts to retry the message delivery. This should be clear now I hope. > More important, I would hope that the client would accumulate > undeliverable addresses and include them in a single "bounce" message, > not send one bounce message per undeliverable recipient for reasons I > hope are obvious. So obvious, I didn't bother to make it explicit. :-) > > Note, that the 552 in reply to "RCPT" will not be taken to mean > > anything about the message as a whole, earlier or subsequent > > recipients. If any recipients are ultimately not rejected the > > partially accepted message envelope will be relayed by the > > client unless the server rejects the "DATA" command. > > See my questions to Jeremy, but, if that is what they are doing, > then they are conforming to the requirement to treat 552 as 442, No, definitely NOT. A 4XX (read my reply in lieu of Jeremy, though of course he is still quite welcome to answer for himself) results in the recipient being added to the list of recipients to retry, while a 5XX causes the recipient to be dropped from the list of still pending recipients for the message and to be added to the list of recipients to be bounced. Perhaps you're imagining some message-level scope for these replies, but replies to "RCPT" don't have message-level scope, they're only about that particular recipient and nothing else. It is full steam ahead to deliver the message to all the 2XX recipients if at least one has been accepted (and DATA or BDAT is accepted) regardless of any 4XX or 5XX to some proper subset of the recipients. > because that is exactly the behavior one would expect 442 to do. > Whether they (or you) think about that as conforming behavior > doesn't make a lot of difference. If there is a difference it > is in your suggestion above about an immediate bounce. Again no. 5XX "erases" the recipient, "4XX" puts the recipient on the "try later" list. So they're manifestly quite different. > And that immediate bounce, or even returning the 552 code to an > earlier SMTP sender, raises another problem. One of the most > important principles in SMTP-land, going back to 821, is that > one does not report a message as undeliverable and then deliver > it anyway. "Delayed" messages are an odd case for which 821-> > 2821-> 5321 do not have any provision, but, if the message (or, > if you prefer, address) is bounced, that is the end of it -- the > only way that message is going to be delivered to that recipient > is if the originator creates and sends what, as far as SMTP is > concerned, is a new message. You appear to me to be thinking within a model where a message has an atomic envelope with an indivisible group of recipients, but of course each recipient's fate is an independent event, and MTAs routinely "split the envelope" for any number of reasons. When some of the recipients in an envelope that the sender had attempted to deliver in a single transaction (had not intended to split) are accepted, and some are temporarily deferred (and the rest rejected) the envelope is dynamically split with the accepted batch delivered via the first transaction, the deferred batch retried separately, and the rejected batch included in a bounce (consolidated across all the scheduled pre-split envelopes envelopes of the same message). In any case you keep talking about *messages* in a context ("RCPT" replies) which is per-recipient. Again a 4XX or 5XX reply to "RCPT" is NOT about the message, it signals the status of just *that* one recipient. > Good. Again, you are describing behavior consistent with the > client treating the 552 as equivalent to 452 (or some other 4yz > code). Absolutely not. See above. They are fundamentally incompatible (for the affect "RCPT"), and don't convey anything about the transaction as a whole (unless *all* recipients temp or hard fail). > > Instead clients typically limit the number of recipients per > > envelope to somewhere south of 100 (perhaps hand-tuned for mail > > destined to some of the 800lb gorilla providers), and just send > > all the RCPT commands they intended to send, with perhaps the > > tail of the list ending up deferred. > > Again, consistent with treating the 552 as a 442, whether they > precisely follow the rest of the description in that section or > not. Still, and emphatically, nope, the two are NOT the same. > > So long as the server is willing to defer (4XX) 100-N > > recipients or more without prejudicing any it already > > accepted, it will interoperate with clients that expect to be > > able to send up to 100, despite the lower limit. > > But that is an issue with the current semi-hard limit of a > minimum or 100, not with the 452/552 requirements. Let's, at least for now, move on from any distraction that 452 is functionaly equivalent to 552, it simply isn't. And switch to the issue of the 100 "limit" (minimum the server is required to accept, and hence maximum a sensible client should attempt by default, barring prior arrangements, special local knowledge, ...). > And, while the text is not as precise as we might like it, clients > (and, for that matter servers) are allowed to pick lower limits under > the "Resistance to Attack" / Operational necessity principle. So > there is nothing in the above that is non-conforming, even to the > current text in 4.5.3.1.10. And, fwiw, I note your explanation above > uses "defer" and "4XX" together, not 552. A server is free of course to respond however it likes, but if it wants to be interoperable, it needs to take into account that compliant clients aren't psychic, and may legitimately attempt up to 100 recipients. If the server wants to accept fewer recipients *per transaction*, say 20, it needs to be willing to soft-fail (4XX/defer) up to at least 80 subsequent "RCPT" commands, without tarpitting or other barriers to having at least the first 20 recipients delivered. If a client choose to initiate transactions for over 100 recipients with "strangers", it may needs to be prepared to slow down and perhaps treat the first "452" it encounters as a strong hint to perhaps defer all the rest, without even attempting to try and include them. There appears to be some logic in Exim's source code along these lines, to stop when at least one recipient got a 2XX or 5XX when subsequently a 452 is seen. That logic is not always a good idea, because 452 can also signal other per-recipient resource limits, and the decision to defer everyone else can substantially delay the remaining recipients (perhaps beyond the message expiration time). But this is a plausible heuristic if it is correct in a sufficient supermajority of cases. I guess, since it is in the code, it is working out mostly okay... So this is one case in which Exim appears to be reading more into the server's reply that just the 2XX, 4XX, 5XX trichotomy. There is no such logic in Postfix, and none likely any time soon. > > Another reason for fewer than 100 is when servers want have the > > envelope split by some server-specific classification of > > recipients, that may affect recipient-specific downstream > > content transformations. In such a case the server might 452 > > every recipient in a class that is different from that of the > > first accepted recipient. The remaining recipient classes > > would then need to be tried in a separate transaction. > > Again, 5321 now allows clients and/or servers to pick a limit > lower than 100 and encourages / specifies orderly behavior when > that is done. Modulo the recommendation to use 452 for clarity > rather than 552, that is what everyone you have described seems > to be doing in practice. [ I'm ignoring the 452/552 equivalence catnip. ] Note that an Exim-like strategy of truncating the envelope at the first 452 works poorly in this case. Because if the various recipients classes (as is most likely) are sprinkled randomly through the envelope, with high probability only one or two get through per transaction, and as soon as there's a new class, the rest are deferred. An envelope with 100 recipients and say 5 recipient classes, might then take ~80 retries to deliver (and likely would never get to the tail of the list). So the key thing here is "orderly" deferral of the 100-N recipients, when choosing to accept N-at-a-time, where orderly does not imperil the delivery of the first N. > If you think it is useful for either 5321bis or the A/S > to explicitly point that out and discuss it, please suggest how > and where to do that. My personal guess (and so-far weak) > preference is that the A/S is headed for a discussion of the > practical issues and tradeoffs associated with the various cases > and options. In particular, from the standpoint of 5321 "more > retries... before the message expires" is not 5231bis-level SMTP > problem. Perhaps, but lack of clear protocol guidance for servers can mean that servers end up doing counter-productive things that harm the ecosystem, by imposing capricious burdens on clients that the client has no way to anticipate. Where to explain what keeps the ecosystem in balance is a judgement call. I tend to favour over-communicating such messages, but other approaches are also possible. > > If, on the other hande, based on the sequence of presented > > recipient addresses the server has somehow concluded that the > > client is a spammer, it can of course with full knowledge of > > the fact that the recipients will NOT be retried, send 552 or > > better yet at that point, 554. > > Agreed. And I think that is what the text says. If you think > it needs clarification to distinguish between those two cases, > please say so and encourage opening of another ticket. Once the "treat 552" as 452" text goes away, and it is clear that all "5XX" replies are permanent errors for the recipient in question, the servers may mostly do as they see fit, but if it were up to me, I'd include the "100-N" 4xx guidance for servers that wish to receive only short envelopes, and are expecting clients retry (and ultimately typically succeed) the rest in some separate transaction. > > This is problematic and generally pointless. It serves no > > purpose and breaks interoperability. Clients can always send > > multiple copies in separate envelopes, so such absolute limits > > (below 100) damage interoperability and don't achieve the > > desired goal of actually stopping the same message arriving to > > more than a given number of recipients. > > But that is precisely intended to allow for the 552/554 response > you are suggesting above. So, "pointless", perhaps not. More > confusing than it ought to be, maybe. Suggestions welcome. I am talking about 4XX after N < 100. If a server determines that a message is spam after it hits 3 honeypot addresses in the first 20 it can start replying 5XX for the rest, though frankly I'd prefer to not expose that side-channel as to which addresses are the honeypots and which not. Simpler to just reply "5XX" to DATA, or all BDAT commands. > > The solution is quite simple delete the above text, the > > overall picture is much simpler. Respond with 4XX to defer > > and 5XX to permanently reject a given RCPT. There's no reason > > for the specification to dwell on all the creative ways in > > which a decision to reject might be made. > > However, what I thought we heard Wednesday morning was that a > number of servers continue to send 552 where 452 is now > preferred ("preferred" may be a little weak). If there are such servers, that's their problem, as mentioned above, in 20 years of helping a community of users keep their MTAs humming, I've seen no reports I can recall of such instances. > As long as that > is the case, then the purpose of that extended section is to try > to explain ways to handle the situation, including both > receiving 452 and receiving 552 in a situation where it is > intended to be interpreted as 452. Two MTAs with a combined market share of IIRC ~90% by server count (though not email volume, given the concentration of email hosting by the 800 pounders) have no 552 to 452 downgrade heuristics, that ship has sailed over the horizon and is not coming back. > If we are convinced that all > of the SMTP servers on the Internet (or enough that others don't > count -- and I'm counting gorillas who feel free to define their > own standards as one each, not by their user or daily message > counts) have followed the advice of 5321 so that no server is > any longer sending 552 when 452 (and breaking up the mail > transaction and resending) is intended, then the section should > be significantly reworked, possibly including a historical note > for servers that are still in existence but we cannot identify. Yes, that section has long outlived its usefulness. The Postfix changelog says: 20010520 RFC 2821 recommendation: treat a RCPT 552 reply as if the server sent 452. Files: smtp/smtp_proto.c, lmtp/lmtp_proto.c. 20010607 Safety: dropped the RFC 2821 compliant code that treats 552 RCPT TO replies as 452. It created more problems than it solved. Files: smtp/smtp_proto.c, lmtp/lmtp_proto.c. The feature lasted but a few weeks, before it was withdrawn almost 20 years ago, never to reappear. I think that says everything that needs to be said. > > The key thing in this section is to specify that "452" MUST be > > used when the client should retry the recipient separately > > because too many were sent so far to process in a single batch > > on the server. The number of "452" replies the server is > > willing to send without blocking message delivery or imposing > > punitive delays that'll prevent transaction completion needs > > to be at least 100 minus the number of initially accepted > > recipients. > > And, modulo the limit of 100, which I continue to believe is > either a separate issue or no problem at all given the current > text in 5321, I believe that is exactly what that current text > says. Still not going for the catnip (again). Been there, done that... :-) -- Viktor. From nobody Thu Mar 11 21:22: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 61ED33A0C20 for ; Thu, 11 Mar 2021 21:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVU5c_tBmqmz for ; Thu, 11 Mar 2021 21:22:04 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5143A0C1C for ; Thu, 11 Mar 2021 21:22:04 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lKaFP-00064C-9Q for emailcore@ietf.org; Fri, 12 Mar 2021 00:22:03 -0500 Date: Fri, 12 Mar 2021 00:21:57 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: <420176B328E2416BF3351C95@PSB> In-Reply-To: <6FC2E8E6-334A-4C4B-9FB6-A0F2805C4A31@dukhovni.org> References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <397cc52c-5533-12a2-6ca2-e46f5987105c@wizmail.org> <6FC2E8E6-334A-4C4B-9FB6-A0F2805C4A31@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] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 05:22:06 -0000 (top post) Victor, Thanks. I'm now fairly sure I understand what you are saying. It leads to another question, mostly just to clarify the implications of what you are suggesting. We know there isn't much precision in the second and third digits of response codes, with the overloading of 552 as an example. It is also the reason we have RFC 3463 and its updates for when the server wants to supply fine-grained information. If SMTP clients are not paying attention to those codes anyway, we could save many pages of 5321bis by tearing all the theory and details of the specific three-digit codes out, specifying that servers MAY reply with the traditional codes if they want to but otherwise can just send x99 or some such thing and, if they feel like being informative should just use extended codes of the RFC 3463 variety, which actually do provide information. Would you suggest that and, if not, why not? Or, put differently, where is the stopping point between your "what dogs hear" model and doing that? john --On Friday, March 12, 2021 00:16 -0200 Viktor Dukhovni wrote: > > >> On Mar 11, 2021, at 11:13 PM, John C Klensin >> wrote: >> >> [...] >> MAIL FROM: >> 250 ... >> RCPT TO: >> 250 ... >> RCPT TO: >> 250 ... >> RCPT TO: >> 250 ... >> [...] >> RCPT TO: >> 552 ... >> >> Now, upon getting that first 552, does EXIM > > It is time to introduce an analogy to a famous Gary Larson THE > FAR SIDE cartoon, "What dogs hear": > > https://www.flickr.com/photos/sluggerotoole/153603564 > > The server may yell: > > ... > 250 at your service > 250 at your service > 552 too many recipients. > 552 too many recipients. > 552 too many recipients. > ... > > But all the sending client hears is: > > ... > 2.. ... > 2.. ... > 5.. ... > 5.. ... > 5.. ... > ... > > the client will stash away the full error code and text for > inclusion in the bounce, just in case some user or postmaster > can make some sense of it, but otherwise all those carefully > specified digits in the SMTP RFCs play no role whatsoever. > > Servers are far too likely to send some random 5XX code that > does not mean exactly what the RFC intends it to mean, and in > any case the last two digits make no difference, the command > is either accepted, soft-failed or rejected permanently, and > the first digit had better signal that correctly, the rest > is irrelevant forensic information for whoever might care > to read the tea leaves. > > >> (1) Assume it is really like a 550, i.e., that >> is, at least for traffic coming from >> , a more or less permanently unavailable or >> non-existent address, continue with other addresses, but never >> retry and basically tell whomever or >> whatever you got the message from that it is undeliverable for >> that address. > > This of course, and ditto with Postfix, Sendmail, or any other > mainstream MTA you're like to run across. > > >> If so, continue that "no retry" behavior for >> and the (potentially) hundreds of >> addresses that follow. > > Sure, but any mainstream MTA will not send 100's of addresses > in a single envelope to strangers, since there's no reason to > expect the remote peer to be willing to accept more than 100 > recipients, and by the time the message transaction has been > amortised over 100 recipients most of the benefit of batching > has been achieved. > > Also list managers typically send mail to one recipient at a > time (VERP), and people rarely send mail to more than 100 > readers, so larges envelopes beyond first O(100) don't have > any measurable positive impact on MTA throughput. > >> If one does not follow the advice about treating 552 as if >> were 452 and basically ignores Section 4.5.3.1.10 (since, wrt >> 552, it offers no alternate interpretation), I can justify >> any of the above on the basis of text I can find in 5321. I >> may be missing something (wouldn't be the first time, even >> this week), but that looks like it. > > Any such justification is divorced from the "What dogs hear" > reality, did the server say "2..", "4.." or "5.."? > >> So what does exim actually do? > > Naturally, treats the "2XX" recipients as delievered (assuming > DATA or BDAT LAST was accepted), retries the "4XX" recipients > separately, and bounces the "5XX" recipients. That's the only > correct client behaviour. > >> For everyone else: is there any desire to narrow the options >> in 5321bis so that guidance is given as to which of the above >> options is acceptable? > > Regardless of what the RFC says, client MTAs will continue to > be dogs. The RFC can align with this reality or live in some > make believe alternative universe. > > -- > Viktor. From nobody Thu Mar 11 22:13: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 37CC53A00DB for ; Thu, 11 Mar 2021 22:13:50 -0800 (PST) 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 yruIvDe4Lf3w for ; Thu, 11 Mar 2021 22:13:48 -0800 (PST) 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 56A163A00C8 for ; Thu, 11 Mar 2021 22:13:48 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 74EECCC4EC; Fri, 12 Mar 2021 01:13:46 -0500 (EST) Date: Fri, 12 Mar 2021 01:13:46 -0500 From: Viktor Dukhovni To: emailcore@ietf.org Message-ID: Reply-To: emailcore@ietf.org References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <397cc52c-5533-12a2-6ca2-e46f5987105c@wizmail.org> <6FC2E8E6-334A-4C4B-9FB6-A0F2805C4A31@dukhovni.org> <420176B328E2416BF3351C95@PSB> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420176B328E2416BF3351C95@PSB> Archived-At: Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 06:13:50 -0000 On Fri, Mar 12, 2021 at 12:21:57AM -0500, John C Klensin wrote: > If SMTP clients are not paying attention to those codes anyway, > we could save many pages of 5321bis by tearing all the theory > and details of the specific three-digit codes out, specifying > that servers MAY reply with the traditional codes if they want > to but otherwise can just send x99 or some such thing and, if > they feel like being informative should just use extended codes > of the RFC 3463 variety, which actually do provide information. Indeed, but I over-simplified somewhat. A few of the distinctions are broadly useful: * 40X and 50X codes are syntax errors. * 421 and 521 are server-initiated disconnects. * IIRC SASL is a bit more picky about some of the codes as well. * Otherwise, 4XX and 5XX are what dogs hear, but of course these are still useful as a forensic after-the-fact diagnostic aid. So my take is that at the SMTP protocol layer, the fine-grained codes are mostly cosmetic, the first digit suffices. But for debugging problems later, they are somewhat useful, at least to the postmaster of the site that replied with those code when a problem report includes the server's response. > Would you suggest that and, if not, why not? Or, put > differently, where is the stopping point between your "what dogs > hear" model and doing that? I would not suggest that servers go out of their ways to perversely invent novel codes. Aside from syntax errors and "Goodbye" X21 responses, servers can IMHO pretty much otherwise stick to just four mostly interchangeable response codes: 450, 454, 550 and 554. I can't say I'd miss most of the rest. So I would certainly not invest much energy in adding new precision to the existing codes, or even necessarily keeping all the current distinctions in place, but I'm curious to hear what others have to say about that. Below is the list of all the codes that Postfix has built-in knowledge of in the SMTP server, and the number of times seen in the source code. (in addition users can set arbitrary 4XX/5XX codes in access rules): 4 500 -- Syntax 49 501 4 502 17 503 2 504 2 220 -- Connection 2 221 9 421 2 521 1 235 -- AUTH Success 1 334 -- AUTH continue 1 530 -- AUTH FAIL 1 535 12 250 -- OK 1 252 -- VRFY 1 354 -- DATA continue 1 452 -- The reason we're here :-) 1 552 -- The reason we're here :-) 14 450 -- Sorry, you lose 6 454 7 550 7 554 3 458 -- ETRN 1 459 3 553 -- Mostly EAI misuse 2 555 -- DSN misuse The frequency count in lines of code is not necessarily indicative of actual frequency of use. So best-effort is made to use the closest approximate standard code to the reason for a failure (there's not always a good match), but the client code only cares about [45] and [45]21 as special connection-layer termination codes. The simpler "dog" model works remarkably well. -- Viktor. From nobody Fri Mar 12 02:17: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 08B893A1763 for ; Fri, 12 Mar 2021 02:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbjqvvLm0zmg for ; Fri, 12 Mar 2021 02:17:03 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07C23A1761 for ; Fri, 12 Mar 2021 02:17:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1615544213; bh=bUZRX1EBCLWRJgm5MH9a256uvqFPLZMLCI/HrfgWitM=; l=2136; h=To:Cc:References:From:Date:In-Reply-To; b=AWjQCgn7vKBKjFaTN6xQR1aHDfj9RVoG2kt8+qoLX5n+sphaDN2Aw5i0HgV6R8H3l rhKwkOTj62zfwqd0GP/Glq6nKtq40fGwWuBPhUnUn3PHCuEm7NMZnUs7nxIJ/LQ7Gw aYSaTcL2BXNQVDLn7os7IJfxZZU1RVg30gLFfbqyL7F63jVXgBM7xGHxhsWJf Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Original-Cc: "Peter J. Holzer" 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 00000000005DC07E.00000000604B3F95.0000245B; Fri, 12 Mar 2021 11:16:53 +0100 To: Ned Freed , emailcore@ietf.org Cc: "Peter J. Holzer" References: <86B11D00B74F9DA068CB3724@PSB> <20210310080645.GA2318@hjp.at> <01RWHFRDA4MG005PTU@mauve.mrochek.com> <01RWI2OOX4ZM005PTU@mauve.mrochek.com> From: Alessandro Vesely Message-ID: Date: Fri, 12 Mar 2021 11:16:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <01RWI2OOX4ZM005PTU@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 #5, rfc5321bis Section 4.5.3.1.10, and G.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, 12 Mar 2021 10:17:05 -0000 On Wed 10/Mar/2021 20:08:09 +0100 Ned Freed wrote: > >> If not removed, RCPT/552 deserves at least being discouraged.  For example, by >> noting that a 552 reply code to RCPT likely has the same effect as a 550. > > Aside from avoiding 552 because of the bug in RFC 821, I'm afraid I don't see > rationale for this. We can and do check for persistent over quota conditions at > RCPT TO time, and if that's the case return a 5YZ error. If the RFC 821 bug is > no longer a concern, the only reason for not returning 552 now is to avoid the > workaround. I assume you mean 452. >> Frankly, I don't understand the discussion in Section 4.5.3.1.10.  In >> particular (i) the two intents: >> >> A    prohibit messages with more than a site-specified number of recipients >> >> and >> >> B    merely limit the number of recipients in a given mail transaction >> >> seem to only differ by the fact that A applies systematically to all >> transactions while B might look transient, which hardly sounds like the correct >> meaning.  Then, (ii) Ned's implementation of storing separate queue entries may >> overcome what he calls "a badly implemented administrative limit", but is based >> on 4xy negative replies.  Therefore, the option to: >> >>      simply return the 503 after DATA >>      without returning any previous negative response >> >> won't work in any case. > > It will work, for some value of the word "work", because we treat 5YZs as the > permanent failures they are and don't attempt to second-guess the server. There is no point in giving 503 rather than 550. Number of recipient doesn't play any role. I'd strike that sentence, as Viktor suggests. > We only engage in recipient list limiting when given a subsequent 4YZ. Yes. > That said, given the number of clients that use a separate transaction for each > recipient, the idea that you can limit the number of recipients of a message in > this way is sufficiently dumb that I see no reason to mention it as useful > thing to do. It still has to be programmed for. Best Ale -- From nobody Fri Mar 12 02:20: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 002D83A1779 for ; Fri, 12 Mar 2021 02:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkwsKopfpih1 for ; Fri, 12 Mar 2021 02:20:09 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEC233A177A for ; Fri, 12 Mar 2021 02:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1615544406; bh=yc/vZsLuPOwrsgsPgKd39PxILkHuo1YSa8qXWmLOmKw=; l=2116; h=To:References:From:Date:In-Reply-To; b=Ay0YEp+PQ+vGa+Vw7TY1/IwaCmBT20xtU9VKclGxAvd6nkg02PDSKc/aFdru3jpo5 HmjY4T0L/qSk50ASg3sleV4VajcKf/TGDAQJ2NObVRZIAw0Bjz44N/YspPKkEamyBo IfvQ2T3iyCMiEZw237ZFIDo3vwbkVeGgUC7GS1+ZjANNSynxZrMV9KDqaLVf2 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 00000000005DC07E.00000000604B4056.000024B7; Fri, 12 Mar 2021 11:20:06 +0100 To: emailcore@ietf.org References: <86B11D00B74F9DA068CB3724@PSB> <20210310080645.GA2318@hjp.at> <01RWHFRDA4MG005PTU@mauve.mrochek.com> <8FA3FFF3827FE28A6DA9F196@PSB> <1C2CC229-9EFE-4552-B518-C0C80ECD8274@dukhovni.org> From: Alessandro Vesely Message-ID: Date: Fri, 12 Mar 2021 11:20:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <1C2CC229-9EFE-4552-B518-C0C80ECD8274@dukhovni.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #5, rfc5321bis Section 4.5.3.1.10, and G.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, 12 Mar 2021 10:20:11 -0000 On Thu 11/Mar/2021 05:44:40 +0100 Viktor Dukhovni wrote: >> On Mar 10, 2021, at 7:47 PM, John C Klensin wrote: >> >> (3) Probably (but subject to further discussion) we leave the >> first paragraph of 4.5.3.1.10 alone because all it really says >> is that a 552 code in response to RCTP is reasonably treated as >> temporary rather that the "just stop and send QUIT or RSET" >> behavior normally expected in response to a 5yz code. > > Absolutely, 100%, unconditionally, ... NO WAY. The text about > treating 5XX as though it were a 4XX reply MUST go. There is > no mechanism for the client to divine the exact reason why the > server choice 552 and not some other 5XX code. +1, 552 can be be understood as 550. > The bottom line is that a recipient that got a 5XX code WILL be > bounced, and a recipient got a 4XX code will be deferred. > > When at least one recipient is accepted, but some are deferred > (4XX) an MTA doing SMTP relaying (unlike an MUA doing SUBMIT) > MUST NOT immediately defer the accepted recipients. MTAs are > expected to be able to deliver a portion of the message envelope > in one transaction and the remainder in one or more additional > transactions. Hm... a MUA shouldn't get a 452 on submit, should it? I'm not clear what it means "immediately defer", verb and adverb sound incongruous. > Indeed when a destination has more than one MX host, and the > first transaction defers some recipients, Postfix will by > default immediately open a connection to a second MX (by > default tries at most two per envelope, before deferring > for later) and try the remaining 4XX recipients there. Indeed, some mention this as one of the reasons to have multiple MXes. It would make sense to enable this feature, quick retry, also for mail sites that only sport a single MX at a single address. Since there are multiple codes, we could convene that some 4yz want a real delay while others just need a separate transaction. I understand such distinction cannot be made in 5321bis, but maybe the A/S? Best Ale -- From nobody Fri Mar 12 07:33: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 53DE73A1321 for ; Fri, 12 Mar 2021 07:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.098 X-Spam-Level: X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, 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=71Y2Xk9V; dkim=pass (2048-bit key) header.d=wizmail.org header.b=iHvkA/2m Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mIsbBYJVZXa for ; Fri, 12 Mar 2021 07:33:16 -0800 (PST) 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 3984E3A1327 for ; Fri, 12 Mar 2021 07:33:15 -0800 (PST) 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:Subject:From:References:To: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=C5RW9ptPyQEvxkCJtfcbSWkXpE+pTuaf1Bfnf4hDE0k=; b=71Y2Xk9VPmd0vFDv5yq3egcfrl YmZSFJ/4YxMQgW1zeK1VUqQ20SG6tVG3fJGLWMYBGFx0+brwkNbVBGOR7kDQ==; 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:Subject:From:References:To: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=C5RW9ptPyQEvxkCJtfcbSWkXpE+pTuaf1Bfnf4hDE0k=; b=iHvkA/2mIWuUbFHQQqRvOq/8dR 8jfQadgkxWkp+bekAmfaS1UsymFn9S30FNWxIgJSPA5mWgg+j9HjJ9JN6NJJUggo0vsni0Y6YfF8V wVK/mR3aDBUU/WsM9U3bSu/JLziq9x8wPnIacH8uBczBV36KuSijj3SOTaybs1c9LqQ9EMDehPqIE lWDuvEMi59mj7OJlcjPlIpfzGUS1F9BJDwQE1a2KUCwJR10PF58b+BRZjpng+N7TG0vnjsrKe3JOI dVdWlSl44YIlenCZ60mYjozXPpVymbPvFcFwkbSg9+aa75nR4rJ+6OdBLsPjRb5bw/UZ4YhfBanYD qpm89kyg==; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=46.33.133.68; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [46.33.133.68] (helo=lap.dom.ain) (from_AS 51561) by wizmail.org (Exim 4.94.116) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1lKjmq-002OG9-CU for emailcore@ietf.org (return-path ); Fri, 12 Mar 2021 15:33:12 +0000 To: emailcore@ietf.org References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <397cc52c-5533-12a2-6ca2-e46f5987105c@wizmail.org> From: Jeremy Harris Message-ID: <47f870f5-494c-b8d4-b724-8fb2b2c545c9@wizmail.org> Date: Fri, 12 Mar 2021 15:33:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.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: [46.33.133.68] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 15:33:18 -0000 On 12/03/2021 01:13, John C Klensin wrote: > > > --On Thursday, March 11, 2021 22:07 +0000 Jeremy Harris > wrote: > >> On 11/03/2021 21:18, John C Klensin wrote: >>> If it >>> is in need to changing, it would be to change the SHOULD to a >>> MUST since that appears to be what everyone is doing anyway. >> >> >> No, it is not. Exim does not treat a received 5xx as a 4xx. > I'm happy staying with MUST --up to the WG-- but would, on > principle, like to understand what EXIM is doing and why. In > particular, a mail transaction, with EXIM as client, looks like: > > [...] > MAIL FROM: > 250 ... > RCPT TO: > 250 ... > RCPT TO: > 250 ... > RCPT TO: > 250 ... > [...] > RCPT TO: > 552 ... > > Now, upon getting that first 552, does EXIM > > (1) Assume it is really like a 550, i.e., that > is, at least for traffic coming from > , a more or less permanently unavailable or > non-existent address, continue with other addresses, but never > retry and basically tell whomever or > whatever you got the message from that it is undeliverable for > that address. Up to here, this is what Exim does. > If so, continue that "no retry" behavior for > and the (potentially) hundreds of addresses > that follow. Contingent on 552 responses also for these following RCPT commands (you didn't specify the response code, so I'm assuming here) any such further 5xx responses to RCPTs would be dealt with in the same way as the first one above. > > (2) Take the first one of those (the one with > ) as a fatal error for more RCPT commands as > a class, skip any other target addresses you have queued up, and > move immediately to DATA (or, in principle, some > extension-enabled command). No, Exim does not do this. > (3) Assume it really is a fatal error (based on the "first > digit" rule, treating it more like 554, or assuming that the > server is really out of memory and would not be able to accept > DATA or the content that follows) and send either RSET or QUIT > as the next command. No, Exim does not do this. It proceeds to send further RCPTs (if available for the message) and to send DATA (or equivalent). -- Cheers, Jeremy From nobody Fri Mar 12 07:46: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 E7D253A13AF for ; Fri, 12 Mar 2021 07:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=GfUNIkkr; dkim=pass (2048-bit key) header.d=wizmail.org header.b=Ty0hY7lG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9AWz-SJHw1O for ; Fri, 12 Mar 2021 07:46:16 -0800 (PST) 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 23EF93A13B6 for ; Fri, 12 Mar 2021 07:46:16 -0800 (PST) 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:Subject:From:References:To: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=TWueydYxycen0dcJXSLp9pBsZhtx9sVCDDB2f3tFeBA=; b=GfUNIkkrsnJycRbDiTA/jsbmcN YyQWvFi/K6VDFDKzldHYWRR683k2+CQxkHAAdVB5ma6pVMMcsqjJFCO01fAA==; 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:Subject:From:References:To: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=TWueydYxycen0dcJXSLp9pBsZhtx9sVCDDB2f3tFeBA=; b=Ty0hY7lGGhS4/Y4Qmv2kss4XtI UkZvF+srVAIN9aln1ADKw1mQbB9CVC3cPrxhoUzLPBRrw44gOhCegBt0RmBT2YpXqo63ejSVnK9/3 CGjp3tIP4lVgRw3GZ08O1TIyGGda9qs/OFkALJwUzBM2vuMiyIBEyOPvknTe5Qw1FXne4m63A3v6G NPkw9QRVqe/gDfqsZxuQmYuUk6YnEReQDAIumCe/xCQw7+00cewf5GegyeGLnQAdsgGnjGC1E/Nae oZ0wzySKQhapt55oDZ+ThP2pjXJLpKoPBbsV9gR/fCFgS07RFSiPJRv0CDYrj9gwC3Kvb0uzDfkab ThzKejfQ==; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=46.33.133.68; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [46.33.133.68] (helo=lap.dom.ain) (from_AS 51561) by wizmail.org (Exim 4.94.116) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1lKjzR-002OUd-2b for emailcore@ietf.org (return-path ); Fri, 12 Mar 2021 15:46:13 +0000 To: emailcore@ietf.org References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <5772045E-2EB3-44B7-BCA8-0135DF809C62@dukhovni.org> From: Jeremy Harris Message-ID: <68cd718f-3bf5-3906-25e1-94ecfdb0ba2f@wizmail.org> Date: Fri, 12 Mar 2021 15:46:12 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <5772045E-2EB3-44B7-BCA8-0135DF809C62@dukhovni.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: [Emailcore] Proposed ESMTP keyword RCPTLIMIT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 15:46:18 -0000 On 11/03/2021 23:29, Viktor Dukhovni wrote: > > When a conforming SMTP server encounters this condition, it has at > least 100 successful RCPT commands in its recipients buffer. If the > server is able to accept the message, then at least these 100 > addresses will be removed from the SMTP client's queue. > > > I wish that were true. It would certainly aid interoperability. > But the said 800lb gorilla providers have felt free to dictate > arbitrary limits below the RFC requirements This is outside the current work item, but: We should consider a new method for the server to advertise limits on RCPT before use; this would be more efficient given pipelining. Perhaps an ESTMP keyword "RCPTLIMIT" taking parameters MAX=nnn SINGLE_DOMAIN These would be advisory for the client; the server would still have to apply limits via responses to RCPT commands, and the client MUST NOT take any different action to command responses based on the EHLO keyword seen. The client SHOULD choose command sequences based on the EHLO keyword parameters, for example by issuing no more than RCPT commands in any single transaction performed on this connection. -- Cheers, Jeremy From nobody Fri Mar 12 07:53: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 4765C3A141E for ; Fri, 12 Mar 2021 07:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHTy43C_NyAh for ; Fri, 12 Mar 2021 07:53:24 -0800 (PST) Received: from forward5-smtp.messagingengine.com (forward5-smtp.messagingengine.com [66.111.4.239]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1503A141D for ; Fri, 12 Mar 2021 07:53:24 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailforward.nyi.internal (Postfix) with ESMTP id F10A819427BD; Fri, 12 Mar 2021 10:53:23 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 12 Mar 2021 10:53:23 -0500 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 :reply-to:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=FH2bHkXO4+jSmzkKisaW9JNOMk4Jh 7pjWDKi6+s5s7w=; b=N8qMhwiAg/ascgKs7XYJhi5hgLiYUJR2PyjorCvHzr5cn tEpcLKgx0uhjnQWnEcvITJlaMXB7sYtVZA10QuNyuedi39kQOeU8tRHN77u6d6gl vO3ciVlj1bzNPO5UhXmOUs/efrLJF0gbjFzYUNHC5eDwksWP+UgCprsa0kVr3FvL YXjObIOFN0pylfPrZeUfHSq3uEi219hYn9l8GCSRKERPtWUdpzzUbIE8ZHdk8Cnb UE/Cnhru7hKc3bYpCd00AD7FNzqjnfqvijX39efg3DzfarH4CnJsO6x9avNI57Hg tBsgAuzQJ9tzsUU74JVj5QDBy0bwXNF/CBQI+do+g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvvddgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpehruffvfhfhohfkffgfgggjtgfgse htkeertddtfeejnecuhfhrohhmpeffrghvvgcuvehrohgtkhgvrhcuoeguhhgtsegutghr ohgtkhgvrhdrnhgvtheqnecuggftrfgrthhtvghrnheptddvjeefkeejledtvdeiuefgie eugfeffeejveegueevvdefleetveehffetvddvnecuffhomhgrihhnpegssghifidrnhgv thenucfkphepuddtkedrvddviedrudeivddrieefnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepughhtgesuggtrhhotghkvghrrdhnvght X-ME-Proxy: Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 11B9424005D; Fri, 12 Mar 2021 10:53:21 -0500 (EST) Reply-To: dcrocker@bbiw.net To: Jeremy Harris , emailcore@ietf.org References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <5772045E-2EB3-44B7-BCA8-0135DF809C62@dukhovni.org> <68cd718f-3bf5-3906-25e1-94ecfdb0ba2f@wizmail.org> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <5aef8939-092d-b6e9-9662-4599251fb920@dcrocker.net> Date: Fri, 12 Mar 2021 07:53:21 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <68cd718f-3bf5-3906-25e1-94ecfdb0ba2f@wizmail.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Proposed ESMTP keyword RCPTLIMIT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 15:53:26 -0000 On 3/12/2021 7:46 AM, Jeremy Harris wrote: > We should consider a new method for the server to advertise limits > on RCPT before use; this would be more efficient given pipelining. > > Perhaps an ESTMP keyword "RCPTLIMIT" taking parameters >   MAX=nnn >   SINGLE_DOMAIN If this is pursued, I suggest it be for /any/ limitation the server applies, not just addressing limits. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Mar 12 08:07: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 2654F3A1506 for ; Fri, 12 Mar 2021 08:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-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=LunDHmdI; dkim=pass (2048-bit key) header.d=wizmail.org header.b=GM1mR5yQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Xsptn-KrfpC for ; Fri, 12 Mar 2021 08:07:53 -0800 (PST) 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 27E783A1675 for ; Fri, 12 Mar 2021 08:07:25 -0800 (PST) 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=lMR2LwzTczG5ssp+AO+Mt5V4lNiLaYPwC31pMoRp464=; b=LunDHmdIxDbwkOqbiVIUQWKLAZ 4ggApLs4G6/51pSkVmMZJAqeMMO+rRZCXnj2tNnZOl8VyNjrxw7tcZicq/CQ==; 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=lMR2LwzTczG5ssp+AO+Mt5V4lNiLaYPwC31pMoRp464=; b=GM1mR5yQi7bAs/rKfQRAoV7/mU DHS9qiuPrnL+aAh+gENSTEaa79GVoY8zGctafwscuVZo2gBWK1Uu6fupE7klGM4nmSuzDHIbD2ffL cKVXSoDS4xttfOVgyIsPwGdGGKBnEr3jUHZ1kZ3bpnYOQveqnDWh8t2PWai8nPXn4agrMjgBIaz08 87PVYbL7ZVg5eqSahbuNKu6HZHvkmFLsTTi/Ru/DGzSr0u9foI4UcM+wl+un40eeujBMKnpK92+Ex kAEMyMIaqdflpBHYb1tppzVbqlxnflWznq7kV6vvdekS1ROupCxcRFjCHc3gaQP/NLD3DNw7XUHiw DdLGLWHA==; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=46.33.133.68; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [46.33.133.68] (helo=lap.dom.ain) (from_AS 51561) by wizmail.org (Exim 4.94.116) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1lKkJw-002Oun-1A for emailcore@ietf.org (return-path ); Fri, 12 Mar 2021 16:07:24 +0000 To: emailcore@ietf.org References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <5772045E-2EB3-44B7-BCA8-0135DF809C62@dukhovni.org> <68cd718f-3bf5-3906-25e1-94ecfdb0ba2f@wizmail.org> <5aef8939-092d-b6e9-9662-4599251fb920@dcrocker.net> From: Jeremy Harris Message-ID: <05d6b2cb-ae9f-83eb-28cc-b5cee030906a@wizmail.org> Date: Fri, 12 Mar 2021 16:07:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <5aef8939-092d-b6e9-9662-4599251fb920@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Emailcore] Proposed ESMTP keyword RCPTLIMIT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 16:07:55 -0000 On 12/03/2021 15:53, Dave Crocker wrote: > On 3/12/2021 7:46 AM, Jeremy Harris wrote: >> We should consider a new method for the server to advertise limits >> on RCPT before use; this would be more efficient given pipelining. >> >> Perhaps an ESTMP keyword "RCPTLIMIT" taking parameters >>    MAX=nnn >>    SINGLE_DOMAIN > > > If this is pursued, I suggest it be for /any/ limitation the server applies, not just addressing limits. Certainly. Did you have a case in mind that isn't covered by the above two parameters? (I should have specified "taking one or more parameters from the list...") -- Cheers, Jeremy From nobody Fri Mar 12 08:23: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 2A7DE3A1651 for ; Fri, 12 Mar 2021 08:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h92M4bVrMb8D for ; Fri, 12 Mar 2021 08:23:11 -0800 (PST) Received: from forward5-smtp.messagingengine.com (forward5-smtp.messagingengine.com [66.111.4.239]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65E53A1650 for ; Fri, 12 Mar 2021 08:23:11 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailforward.nyi.internal (Postfix) with ESMTP id B06E61943A38; Fri, 12 Mar 2021 11:23:10 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Fri, 12 Mar 2021 11:23:10 -0500 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 :reply-to:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=oGwBzfkjOuAZuQR/k2NKKbwZaeiqJ 1LnXaYrAdOkUuQ=; b=k57Tvbctjc3IR0RRBEpVZqrQab9Wzp/Qduc8o92IY4OTo CR2fstcmKIPccZ6G214P54sgxbxv7f6sdExQdCAHWvpDDf07i6WYZxs+SF+8IVJX N4VpnxAHcDqyPrwltDX284SVYkozKm1LeLLZD9WL1KlCktDtIDj62AK+Ko1lbphb wXfLA5MO0KB0SxAn7YvbuTlak11IoFYR5yHCdd8SERhtKzCfTM3vUybHGxOQLyPY FxuREi1ZLyjFv2WEtgiThXR/Rq7++e8yw9DgrX15xCZnvuPJj7j+pffjWMwhbA2I MKGfq6Micd5vZVbOU+Mw2iWeA/FP/SLfXy6ltzpdA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvvddgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpehruffvfhfhohfkffgfgggjtgfgse htkeertddtfeejnecuhfhrohhmpeffrghvvgcuvehrohgtkhgvrhcuoeguhhgtsegutghr ohgtkhgvrhdrnhgvtheqnecuggftrfgrthhtvghrnheptddvjeefkeejledtvdeiuefgie eugfeffeejveegueevvdefleetveehffetvddvnecuffhomhgrihhnpegssghifidrnhgv thenucfkphepuddtkedrvddviedrudeivddrieefnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepughhtgesuggtrhhotghkvghrrdhnvght X-ME-Proxy: Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 08E75240065; Fri, 12 Mar 2021 11:23:08 -0500 (EST) Reply-To: dcrocker@bbiw.net To: Jeremy Harris , emailcore@ietf.org References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <5772045E-2EB3-44B7-BCA8-0135DF809C62@dukhovni.org> <68cd718f-3bf5-3906-25e1-94ecfdb0ba2f@wizmail.org> <5aef8939-092d-b6e9-9662-4599251fb920@dcrocker.net> <05d6b2cb-ae9f-83eb-28cc-b5cee030906a@wizmail.org> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Fri, 12 Mar 2021 08:23:07 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <05d6b2cb-ae9f-83eb-28cc-b5cee030906a@wizmail.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Proposed ESMTP keyword RCPTLIMIT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 16:23:13 -0000 On 3/12/2021 8:07 AM, Jeremy Harris wrote: > > Certainly.  Did you have a case in mind that isn't covered by > the above two parameters? > > (I should have specified "taking one or more parameters from the list...") max line length\ max number of lines max number of characters for total message MIME limits (eg., nesting depth) Unicode or other character limits I'm not advocating for particular and am not sure any of the above are of practical interest, nevermind sufficient interest to standardize, but I think they serve as plausible examples. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Mar 12 08:53: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 2E78C3A0B53 for ; Fri, 12 Mar 2021 08:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_32=0.001, 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 jKwsFTPzDSqz for ; Fri, 12 Mar 2021 08:53:02 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 8249E3A0C2E for ; Fri, 12 Mar 2021 08:53:02 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id a9so24866947qkn.13 for ; Fri, 12 Mar 2021 08:53:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CmpWeH5Eint/Y3W5seVAU+A8St11MExbOETxiXZstx4=; b=HVCqrJ/wuJpKWpOiZn6FS6PPR7Isy6Hq8uX62m2fLoK17KXWdlwXFmGiGsPmCpL6EB 0zSSTKFVnJVWRy2prvYhCEwSI812vOrUTCUap4rL1FGHDKELYVwBJ28ai+A4Me5O1ahj K11tjwBbIs6S0gCxywsjjEd8SU1VZuZTGgHs5W3QoYB+zVzu9dsONYXo/ndtxFPilZzU 4guHi8NivilncZbu2YCR2wBPl9aO8S+EKXlgYy2uDmXFXutkNFyVJbwec3QKFEC7+eE6 jMg8tCdixkx5wq6orMeVLQJMyWdXBb1osiB20D3FxnHGfSdUeWYjfzieJ3YDCbswfV3S 7ScQ== 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=CmpWeH5Eint/Y3W5seVAU+A8St11MExbOETxiXZstx4=; b=NjyZbf7WD+nMO2bRPcWJ0Q1R/UeLw5JpUvRN7jScPAomKzJMa7zRijNDeE5p5z9+Ss VGDtym0eEnBCbD4UlnoDBklBhpRpkGr1Xp/b4cxGe1LgmBO1Ouq5iFOxT74TVbGUauLq BCIqTz0ViZqk6L6+M4zUjH1BgqeTDqm1jgsxGS6xUH0X/7mLzmMxzFDGfIFfArblAUVB JZ785m9MBldMpI6omeNifoAqzJd4LUyOu0EC1CjJbBkFrc/BtCVyFfznUl5lER8fz1pW E8pQfTvwhZaitplT+0jEzXwjHGxtnlW85+/qnvelpvKG1Gu3rNIYEgWZtddRVza89nmD 9qBw== X-Gm-Message-State: AOAM530qdz9iy9PYwXcYj9XMbDHD+75aeva4c7aT0e2mS6C6+rC5V3Ds Iafa53+1Yz7L2jhLBpIS3LxWuKc7YXUCViYjYK94fA== X-Google-Smtp-Source: ABdhPJwdJ2W8V+QcoNUjSw8k9ySmDa2/D+g1w6zcIPruYVN8BCtbOgx92a1DN9dFsrc4LByyjOBAogCHpFsHybQmCo4= X-Received: by 2002:a37:596:: with SMTP id 144mr14031443qkf.387.1615567981384; Fri, 12 Mar 2021 08:53:01 -0800 (PST) MIME-Version: 1.0 References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <5772045E-2EB3-44B7-BCA8-0135DF809C62@dukhovni.org> <68cd718f-3bf5-3906-25e1-94ecfdb0ba2f@wizmail.org> <5aef8939-092d-b6e9-9662-4599251fb920@dcrocker.net> <05d6b2cb-ae9f-83eb-28cc-b5cee030906a@wizmail.org> In-Reply-To: From: Todd Herr Date: Fri, 12 Mar 2021 11:52:45 -0500 Message-ID: To: Dave Crocker Cc: Jeremy Harris , emailcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000a42afa05bd59bbdc" Archived-At: Subject: Re: [Emailcore] Proposed ESMTP keyword RCPTLIMIT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 16:53:04 -0000 --000000000000a42afa05bd59bbdc Content-Type: text/plain; charset="UTF-8" On Fri, Mar 12, 2021 at 11:23 AM Dave Crocker wrote: > On 3/12/2021 8:07 AM, Jeremy Harris wrote: > > > > Certainly. Did you have a case in mind that isn't covered by > > the above two parameters? > > > > (I should have specified "taking one or more parameters from the > list...") > > [snip] > max number of characters for total message > > Don't we already have this with SIZE? -- *Todd Herr* | Sr. Technical Program Manager *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. --000000000000a42afa05bd59bbdc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Mar 12, 2021 at 11:23 AM Dave Crocker <dhc@dcrocker.net> wrote:
= On 3/12/2021 8:07 AM, Jeremy Harris wrote:
>
> Certainly.=C2=A0 Did you have a case in mind that isn't covered by=
> the above two parameters?
>
> (I should have specified "taking one or more parameters from the = list...")

[snip= ]
max number of characters for total message


Don= 't we already have this with SIZE?

--

Todd Herr | Sr= . Technical Program Manager
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 recip= ient you are hereby notified of any use, disclosure, copying or distributio= n of the information included in this transmission is prohibited and may be= unlawful. Please immediately notify the sender by replying to this email a= nd then delete it from your system.

--000000000000a42afa05bd59bbdc-- From nobody Fri Mar 12 09:07: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 012F63A15C7 for ; Fri, 12 Mar 2021 09:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2Zc5CGxseSn for ; Fri, 12 Mar 2021 09:07:01 -0800 (PST) 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 AA1423A15C0 for ; Fri, 12 Mar 2021 09:07:01 -0800 (PST) Received: from [192.168.1.177] (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 609A6CCECE for ; Fri, 12 Mar 2021 12:07:00 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Viktor Dukhovni In-Reply-To: <68cd718f-3bf5-3906-25e1-94ecfdb0ba2f@wizmail.org> Date: Fri, 12 Mar 2021 15:07:00 -0200 Content-Transfer-Encoding: 7bit Reply-To: emailcore@ietf.org Message-Id: <2FF5B408-A1FC-435D-A219-2E97F0B1F7C1@dukhovni.org> References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <5772045E-2EB3-44B7-BCA8-0135DF809C62@dukhovni.org> <68cd718f-3bf5-3906-25e1-94ecfdb0ba2f@wizmail.org> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Emailcore] Proposed ESMTP keyword RCPTLIMIT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 17:07:03 -0000 > On Mar 12, 2021, at 1:46 PM, Jeremy Harris wrote: > > > Perhaps an ESTMP keyword "RCPTLIMIT" taking parameters > MAX=nnn > SINGLE_DOMAIN I think think these would be fine extensions. Given Dave C.'s point perhaps: LIMITS RCPT=nnn SINGLEDOMAIN ... unlike SIZE or DSN there's no need for any additional keywords in the client's MAIL or RCPT commands, this is just advisory data from the server to the client that aids interoperability. A sufficiently sophisticated server might even tune such limits based on the IP reputation and EHLO name of the connecting client. The "LIMITS" keyword would then have an IANA registry for the individual parameters, that might not even need standards action, just expert review and specification required? -- Viktor. From nobody Fri Mar 12 09:16: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 C9E943A1734 for ; Fri, 12 Mar 2021 09:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 OyPe3SnAJyty for ; Fri, 12 Mar 2021 09:16:26 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 156293A1721 for ; Fri, 12 Mar 2021 09:16:25 -0800 (PST) Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 7BB729F149 for ; Fri, 12 Mar 2021 09:16:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1615569385; bh=qpyU1wE7uW9AVl91MW1X1Qp9qDe9edYZC53KY3kxq7Y=; h=From:Subject:Date:References:To:In-Reply-To:From; b=WicAPC1UBQSRWtiMHhXEMyhYqFkHColcpICD/4VdQ4zlHA+nk2BvwQ/d415bRk/m/ FqHq+wdTL/n9YSiC7d5i3eZBqGr+PMY4CGqVAnqiP7Oi43n/6Px4gMIeRisnLNWWnI WldGEz5lLr42Zo/9zLRuAm3CeAW0IDTss6by1bGM= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_54AD4558-C8F1-498E-B9F1-05CC77BA9FB3" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 12 Mar 2021 17:16:22 +0000 References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <5772045E-2EB3-44B7-BCA8-0135DF809C62@dukhovni.org> <68cd718f-3bf5-3906-25e1-94ecfdb0ba2f@wizmail.org> <5aef8939-092d-b6e9-9662-4599251fb920@dcrocker.net> <05d6b2cb-ae9f-83eb-28cc-b5cee030906a@wizmail.org> To: emailcore@ietf.org In-Reply-To: Message-Id: <77B21231-47EA-4CA6-A665-5880B6A54D4D@wordtothewise.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Emailcore] Proposed ESMTP keyword RCPTLIMIT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 17:16:28 -0000 --Apple-Mail=_54AD4558-C8F1-498E-B9F1-05CC77BA9FB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 12 Mar 2021, at 16:23, Dave Crocker wrote: >=20 > On 3/12/2021 8:07 AM, Jeremy Harris wrote: >> Certainly. Did you have a case in mind that isn't covered by >> the above two parameters? >> (I should have specified "taking one or more parameters from the = list...") >=20 > max line length\ > max number of lines > max number of characters for total message > MIME limits (eg., nesting depth) > Unicode or other character limits >=20 > I'm not advocating for particular and am not sure any of the above are = of practical interest, nevermind sufficient interest to standardize, but = I think they serve as plausible examples. Is there a place for =E2=80=98max connections=E2=80=99 - a number of = places already limit the number of maximum connections that any sending = system can make at one time. A way to mechanically advertise that might = be useful.=20 laura=20 --=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=_54AD4558-C8F1-498E-B9F1-05CC77BA9FB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 12 Mar 2021, at 16:23, Dave Crocker <dhc@dcrocker.net> = wrote:

On 3/12/2021 8:07 AM, Jeremy Harris wrote:
Certainly.  Did you = have a case in mind that isn't covered by
the above two = parameters?
(I should have specified "taking one or more = parameters from the list...")

max line length\
max number of lines
max number of characters for total message
MIME = limits (eg., nesting depth)
Unicode or other character = limits

I'm not advocating for particular = and am not sure any of the above are of practical interest, nevermind = sufficient interest to standardize, but I think they serve as plausible = examples.

Is there a place for =E2=80=98max connections=E2=80=99= - a number of places already limit the number of maximum connections = that any sending system can make at one time. A way to mechanically = advertise that might be useful. 

laura 

-- 
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=_54AD4558-C8F1-498E-B9F1-05CC77BA9FB3-- From nobody Fri Mar 12 10:04: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 778183A192A for ; Fri, 12 Mar 2021 10:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcG81njFQWvc for ; Fri, 12 Mar 2021 10:04:19 -0800 (PST) Received: from wforward3-smtp.messagingengine.com (wforward3-smtp.messagingengine.com [64.147.123.22]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D40B3A1924 for ; Fri, 12 Mar 2021 10:04:19 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailforward.west.internal (Postfix) with ESMTP id 4B03C1633; Fri, 12 Mar 2021 13:04:16 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 12 Mar 2021 13:04:16 -0500 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 :reply-to:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=VGFEs296t8TtIEBBExoiUd7z8E8zz nVRmeR9krAakik=; b=ZCT7hUj+HSk1/ohdkuxuIFFm77n3PBvJx5sxbWs5ATR3Q wu1+NKvT90ituj4dKMSMqt41f3gFpOrJKPvEhmKMyGgKCUiIEjnoMutRi8iGbFZT AEg/5Q4P3laoknDCH4S/PwbnmeCv+TffMhA5tIXbmNnJniYKgec5vE4vhnEZ1/Nq BS2sdDjy4D3boQe41XNbw6FmPc84egP5mrZlqaQ13IXz/FDGww0pL04+d5+g2Ppn jnwD95L+pi5PQp+LbCy7s3VaEqs/gVkh0YqiBVTQlV3QWSrmpyNP4UopPj979Iid 3V2AjO/zDXrR+uCHOcqcIaPbNxqq8mfXE7UHqAqvQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvvddguddtjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheprhfuvfhfhfhokffffgggjggtgf esthekredttdefjeenucfhrhhomhepffgrvhgvucevrhhotghkvghruceoughhtgesuggt rhhotghkvghrrdhnvghtqeenucggtffrrghtthgvrhhnpedtvdejfeekjeeltddvieeugf eiuefgfeefjeevgeeuvedvfeelteevhefftedvvdenucffohhmrghinhepsggsihifrdhn vghtnecukfhppedutdekrddvvdeirdduiedvrdeifeenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguhhgtsegutghrohgtkhgvrhdrnhgvth X-ME-Proxy: Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 0141024005A; Fri, 12 Mar 2021 13:04:12 -0500 (EST) Reply-To: dcrocker@bbiw.net To: Todd Herr , Dave Crocker Cc: emailcore@ietf.org, Jeremy Harris References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <5772045E-2EB3-44B7-BCA8-0135DF809C62@dukhovni.org> <68cd718f-3bf5-3906-25e1-94ecfdb0ba2f@wizmail.org> <5aef8939-092d-b6e9-9662-4599251fb920@dcrocker.net> <05d6b2cb-ae9f-83eb-28cc-b5cee030906a@wizmail.org> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <36694a3d-6b25-37aa-7c18-a3a1bbba61be@dcrocker.net> Date: Fri, 12 Mar 2021 10:04:11 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; 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 Archived-At: Subject: Re: [Emailcore] Proposed ESMTP keyword RCPTLIMIT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 18:04:21 -0000 > On Fri, Mar 12, 2021 at 11:23 AM Dave Crocker > wrote: > > On 3/12/2021 8:07 AM, Jeremy Harris wrote: > > > > Certainly.  Did you have a case in mind that isn't covered by > > the above two parameters? > > > > (I should have specified "taking one or more parameters from the > list...") > > [snip] > max number of characters for total message > > > Don't we already have this with SIZE? So, you are saying that it was a good idea for me both to list a variety of possibilities and to note that I wasn't advocating for any of them but merely meant them as examples? I agree... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Mar 12 12:12: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 943E03A0FFA; Fri, 12 Mar 2021 12:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXJ9N1Mvy1vd; Fri, 12 Mar 2021 12:12:22 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D1B3A0FF9; Fri, 12 Mar 2021 12:12:22 -0800 (PST) Received: from pps.filterd (m0156891.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12CKC8lR006229; Fri, 12 Mar 2021 15:12:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=20190412; bh=hjbWPbJiTMZkRp7B0JTn+T0WAQBOMwS3VMXquGF9HkM=; b=gB/aubsyvKd/q7Y+fFQ72nsey/2DadD8MRrvtT3vqX/1SJB9ztwLVmULjkySx76tLLTw rAn8SUEr5SBGqKCKUxymG5oPgMWQWQP6R41Ox6xPu0w/9Glset85nnjhaRfv+yt7xMhE CaPQizCOrOp18GrxNfLROWgw8001T2vbqdJ9D6cTrQiYpDQE0XhZh80xqxRevJuHgbz4 cD7ext6OTdF50iv+QUlrqmon2knNtXjyuNQoEnh6vHBV36Wnimx9FOMHkItQi5/0bilR hm1MNJ/nkNtJxvhctYZmr1fZaW5dOqfgmd8op0alSJb0EaDOHv2+KXFcUv3/AHCEMYA9 EQ== Received: from pacdcex49.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0a-00143702.pphosted.com with ESMTP id 378cu8scdx-10 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 12 Mar 2021 15:12:19 -0500 Received: from PACDCEX49.cable.comcast.com (24.40.2.148) by PACDCEX49.cable.comcast.com (24.40.2.148) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 12 Mar 2021 15:12:02 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX49.cable.comcast.com (24.40.2.148) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 12 Mar 2021 15:12:02 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.45) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 12 Mar 2021 15:11:53 -0500 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by MN2PR11MB4176.namprd11.prod.outlook.com (2603:10b6:208:13b::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.28; Fri, 12 Mar 2021 20:11:51 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::2495:cfaf:88ca:6b2d]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::2495:cfaf:88ca:6b2d%7]) with mapi id 15.20.3912.029; Fri, 12 Mar 2021 20:11:51 +0000 From: "Brotman, Alex" To: "dcrocker@bbiw.net" , Todd Herr CC: "emailcore@ietf.org" , Jeremy Harris Thread-Topic: [Emailcore] Proposed ESMTP keyword RCPTLIMIT Thread-Index: AQHXF1bpyUO6yJM1+kqkyKYfbMgVqqqAgPmAgAAD7ICAAARlgIAACEeAgAAT9oCAACI30A== Date: Fri, 12 Mar 2021 20:11:51 +0000 Message-ID: References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <5772045E-2EB3-44B7-BCA8-0135DF809C62@dukhovni.org> <68cd718f-3bf5-3906-25e1-94ecfdb0ba2f@wizmail.org> <5aef8939-092d-b6e9-9662-4599251fb920@dcrocker.net> <05d6b2cb-ae9f-83eb-28cc-b5cee030906a@wizmail.org> <36694a3d-6b25-37aa-7c18-a3a1bbba61be@dcrocker.net> In-Reply-To: <36694a3d-6b25-37aa-7c18-a3a1bbba61be@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bbiw.net; dkim=none (message not signed) header.d=none;bbiw.net; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380:9d50:cd63:5a2a:9e5f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: db4d9dca-b699-4b5d-2b34-08d8e59312dc x-ms-traffictypediagnostic: MN2PR11MB4176: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: u2wi7O2wfYCvmsnfK67I8dKIstvnv5TLzsh0CGGG8lEQna/ECwnQ/KywMchcgNYq4jLlEZJ5FlsTaKck+MyNQSbfwArjtvRaGyqz3m/c1YgROdlIvI9O4KrwRqVgmq24m82KRMNjFieApqLbiBTKrXcHQ46Qfq0penUIAciaa6uVKw2/MJcrRRS+776hOqbcxYu8TQfMWRMvMyW9FqvenlGHO2ygUqomUULVN+pAXilSgeMb+TKdXyiqvtuwWIL9hfks+L5uPDQxePqSb4v7ttrcp5pj1dVJ0WaCDKMoMQmAi6YzeBJwIDpeVV2xhRv7irQwsApM94wwbSev33u7JS2wgu0EExzhFLqLgiQ7eSryKh6pQ9uw/sbMuV4GyDi0POcYEjq6YL85yb6ISC9lUG1HsqNDlknSoIV0AzA/4DjW2a8756qdL9QAbjzHuVQbqUGceSxiGSLOLomjGK2EGlXvjjPcXU/p/Hx4t7D1tjkPck7p6LQIsuPc2vFkBKbakWYM4imSDGlqEpLF3QKwttwebGnjFkyYbiBvXnX9UB7pLU0eGyV965b0dR7tAfWgnQ5WPcWyxMNDOKh/Px/Vs+xiSRCqYIxaK9BjA5Zag1w= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(346002)(396003)(39860400002)(376002)(86362001)(966005)(7696005)(6506007)(33656002)(53546011)(9686003)(66946007)(55016002)(66446008)(66476007)(66556008)(64756008)(76116006)(316002)(478600001)(110136005)(54906003)(8936002)(71200400001)(5660300002)(83380400001)(52536014)(186003)(8676002)(2906002)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?a1orSE41RElwYjV4Z3loeitkSVZIcDJYUDFXWnlqcVdGdkszOXFOQ3UxV0ZW?= =?utf-8?B?R0hXNmpxSTVJaVZXZHRTV0JuMHRVVHI1bVdsb2MyU215N0gyTm5jNmVHZk5m?= =?utf-8?B?a01LMjZKQk5UcXRaWHhNRGlwMmpMNm1zZ0dNM3hTcXUyOWN3V3Zuc0xQYTVz?= =?utf-8?B?Wll4YzVHRi9WTWxiUDBpQjAxaDEvVDJIcVBSaTMvNTRGWDZHekRUVVlFNHZE?= =?utf-8?B?VWdtZTQ2TEdDRXhsSmFNRmtTcjA1MW5LejBIVEJsMkkvVkZIeXRoSTF6aTY1?= =?utf-8?B?Uk9YV3AyNlBFQkxWNW9ZNGFCYlp2OStySi9RUDM2b092c2dXRzBhUC9yKy9L?= =?utf-8?B?K2RJMFp1Mi9DaDFYY3pkSWNRV3lsTjk4aGlGa3NEYWthbkhaZnVWcVh3V25L?= =?utf-8?B?Y1Eyd1pXTkpiM2xDWWNCRFZSV3pLVDN1N0FnNGlxUE1nRGFZMWYwTDNITWNH?= =?utf-8?B?R3dDTXF1YjNvSkhKVk1qM1FvSURzWXdEYXlOdXFVLzAxOHQrZnNqOU5aRm1B?= =?utf-8?B?RDVlckIwNUI1UWlMeHhCUTFqNUtnYnFtS2s3U1o5RkpUTjF2RnZkNUoxSUNu?= =?utf-8?B?Wkl5bXZvWGltbDFvbFZVWk13Y0M3bThWeUh5Y1ZGSFNFc2pRMFoycFViU1Vx?= =?utf-8?B?YlZIK3NjdmdITklnQmpHZE5aeFAwaDFZbFpKSWpWRE1TQ3BBak5HejlLZURL?= =?utf-8?B?Wm1Zb1p4ZFYrWmVoMm1rakxRMzhuSmRKcDVoeHNIU0xEaTJpbDY1cFVhZ0xQ?= =?utf-8?B?OTVnRzF0VXE4STFMdFN2YVhaKzdSWkJyRk50cmU1T1pzaHJwWXRtRklJL2dQ?= =?utf-8?B?cmxudmh4MWE2VWpLc1MxRXFaYVBML0ZnZW4wNW81dmJmdi9EeFBUK2NKMmp5?= =?utf-8?B?T01ZMTlXNTVCM1VPOFpnMldlc1F5WmNScWhUaU5hUVc1VmFUS2JSOUR0ZWJJ?= =?utf-8?B?MWVQS1VJdGRYTE9iNG9tRU9SNnJwNDFjVUxGbncvU2xRVkJXZEgzR3ZYQVJB?= =?utf-8?B?SFBIblR1azc4VGRoRlBNZTlOdXlMN1lWbEFrbkxpVC9iZnFBTnRaUG44K09P?= =?utf-8?B?Vm1pNkZhUk5mZW0xeklSR1pRZFVpNXFFRERSUXV1azBlSnEyaUFmckwzalJn?= =?utf-8?B?NEs3VmpaamVRU3g4MFk4KzBRZ0FZU1ZRNVNFR2NXRmdmaGJiRjNsSzdMVXYv?= =?utf-8?B?VDdONWthRzgzRWM1Y2I2TmNpMXRiQmptQjRBK2VMVEVYenA2bEFxQ3IyQ0ZR?= =?utf-8?B?T2RjaFlkRHdaVWx5bk82UVRNRkhGclpPWVRQTGgrZTFWdmRVMWhzSWRpNm9p?= =?utf-8?B?aUU3bTZCUE1zVnJWRk0wMG9yOG1zNGkrRjNJSnAvQmhnVjhjY3NKTVdFSWhC?= =?utf-8?B?ZlgvaDRvRjJyRHMzUDFPMXNQRy9xcmlteUlEaDJsbkNHZEFQWG45ZEkvM0xJ?= =?utf-8?B?UEJTTElPdU9FejJCSENGTWZyU29NTUV4TEZNVjEzWmpuQjFrcTZ2bDhSNld4?= =?utf-8?B?NEsyTG5va1ZKU0JBdThZOFlWSXVLQ2tnM3ZHcktNUmpnRHlqWDB1ZmdPUzlj?= =?utf-8?B?Nzk1SEtxalBlTjY1UEV5WnBaL1FJNzg0VDgyeEkxZ3FDVEk4b1RJNXJybmdo?= =?utf-8?B?Nm10NjBjbXBYQW0xZm94OVNkSmdRZmNGcUJzTUt1NGdtUWdIK05RUXpoeEtO?= =?utf-8?B?cTkrVU90QTBrd1pKUUlXWkh4UnJmTDZZKzNyWllLVk1TRHdvQVFtWWN0TXlR?= =?utf-8?B?c3A2YTdadG4zUnJxeGlKOWFOUWU3aVBlemVHanhRZjhvR0pxcHhGRkJ1M1ky?= =?utf-8?Q?kPjTFN41JNRfKzpQjku5Wapwkyppmn5XdujII=3D?= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ywzict6T3wYhr3Y+DepaQTsyKGc+ilxb5EIwRJEN+705v/q4Up+QW3PYUgilSjWWbmk4Q0GZRVw6UMwL/dNGYVQOPDpeT6cjCG96hA0VUuvGFaHz2KzDxDThcw0BAk4MTn8DnQUEriMQiLJfSeKT1PcxKBK1tIosa8H6RkFPMXk702s9QC6GRH74SjVI7fbX1F+EjqXVYwXGwG0feXrrShEV2MVr9k98+2jho8cqg/u4nZaEwBBdUynR5RguQGaw+T35ubN/i5EMXPes5H7W3/w3DvOMMWHVLjZFunEOmjIBoIClug3tErBe5EVn81ibBqWJ9EEBvRha52m9fHTG4Q== 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=8+hRi2mQeabjpZanjVHwzVfV4jLcGZr7KsUNSLfDbug=; b=FexrRLtZ4r38wzsXRdUMdccPUG5YvQ/WUuL1g7RIQ8IMdD3gRggTPu8BPpJOXuiRA6cK0xV8JBNNDG1LAE7nEysaFsvcuUej5D2WjxbHvZcY8FHG3yk4Gm5Y4ff0HFyLtPiZVPa2TQRlDoxo6ECyuKOIDZLD3G7cxm42zZvsbDPAq3JxtE4ZHcxJDp4j0QSpKCJwGgDCrBG+oWIGPJI/e4nKQam263mRv/xnk4cXoo3E6WvQoN0wXvwMnJ0UihpnIOIu4t8dS4w3tIWUowZCimBKxL2ByLcGWKTiam5h/KCORb62MRNZc1MdfHij6g11bCfhq2dhhMhX3AeIxYMYHw== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: db4d9dca-b699-4b5d-2b34-08d8e59312dc x-ms-exchange-crosstenant-originalarrivaltime: 12 Mar 2021 20:11:51.0928 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: n687UPc5zimSLG2zXzIBbJztHXZsWgqLTcrxG0bQZmkzI9wkE4O2q7eAuG6V4rC6hajtimgZ0Ky7Oz5rjSrkH7fbC7lwPApK2AVjBqwBQSk= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4176 x-originatororg: comcast.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWZ X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-12_12:2021-03-12, 2021-03-12 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Emailcore] Proposed ESMTP keyword RCPTLIMIT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 20:12:24 -0000 VGhpcyBtYXkgbm90IHdvcmsgd2VsbCBpbiBwcmFjdGljZS4gIEl0J3MgZW50aXJlbHkgcG9zc2li bGUgdGhhdCB0aGUgbnVtYmVyIG9mIHBlcm1pdHRlZCByZWNpcGllbnRzIChvciBhbnkgc2ltaWxh ciBsaW1pdGF0aW9uKSBjb3VsZCBjaGFuZ2UgZHVyaW5nIHRoZSBzZXNzaW9uIGFzIG1vcmUgaXMg bGVhcm5lZCBhYm91dCB0aGUgc2VuZGVyLiAgU3VjaCBhcyBvbmNlIE1BSUwgRlJPTSBpcyBzZW50 LCB0aGUgcmVjZWl2ZXIgZGVjaWRlcyB0aGF0IHRoZSBzZW5kZXIgaXMgbGVzcyB0cnVzdHdvcnRo eSBhbmQgd2lsbCBub3cgY2hhbmdlIHRoZSBtYXggcmVjaXBpZW50cyBvbiBhIHNpbmdsZSBtZXNz YWdlLg0KDQpBbHNvLCBJIHJlYWxpemUgdGhlIHJlY2VpdmVyIGNvdWxkIGp1c3Qgbm90IGFkdmVy dGlzZSB0aGlzIGV4dGVuc2lvbi4NCg0KLS0NCkFsZXggQnJvdG1hbg0KU3IuIEVuZ2luZWVyLCBB bnRpLUFidXNlICYgTWVzc2FnaW5nIFBvbGljeQ0KQ29tY2FzdA0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IEVtYWlsY29yZSA8ZW1haWxjb3JlLWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBEYXZlIENyb2NrZXINCj4gU2VudDogRnJpZGF5LCBNYXJjaCAxMiwg MjAyMSAxOjA0IFBNDQo+IFRvOiBUb2RkIEhlcnIgPHRvZGQuaGVycj00MHZhbGltYWlsLmNvbUBk bWFyYy5pZXRmLm9yZz47IERhdmUgQ3JvY2tlcg0KPiA8ZGNyb2NrZXJAYmJpdy5uZXQ+DQo+IENj OiBlbWFpbGNvcmVAaWV0Zi5vcmc7IEplcmVteSBIYXJyaXMgPGpnaEB3aXptYWlsLm9yZz4NCj4g U3ViamVjdDogUmU6IFtFbWFpbGNvcmVdIFByb3Bvc2VkIEVTTVRQIGtleXdvcmQgUkNQVExJTUlU DQo+DQo+DQo+ID4gT24gRnJpLCBNYXIgMTIsIDIwMjEgYXQgMTE6MjMgQU0gRGF2ZSBDcm9ja2Vy IDxkaGNAZGNyb2NrZXIubmV0DQo+ID4gPG1haWx0bzpkaGNAZGNyb2NrZXIubmV0Pj4gd3JvdGU6 DQo+ID4NCj4gPiAgICAgT24gMy8xMi8yMDIxIDg6MDcgQU0sIEplcmVteSBIYXJyaXMgd3JvdGU6 DQo+ID4gICAgICA+DQo+ID4gICAgICA+IENlcnRhaW5seS4gIERpZCB5b3UgaGF2ZSBhIGNhc2Ug aW4gbWluZCB0aGF0IGlzbid0IGNvdmVyZWQgYnkNCj4gPiAgICAgID4gdGhlIGFib3ZlIHR3byBw YXJhbWV0ZXJzPw0KPiA+ICAgICAgPg0KPiA+ICAgICAgPiAoSSBzaG91bGQgaGF2ZSBzcGVjaWZp ZWQgInRha2luZyBvbmUgb3IgbW9yZSBwYXJhbWV0ZXJzIGZyb20gdGhlDQo+ID4gICAgIGxpc3Qu Li4iKQ0KPiA+DQo+ID4gICAgIFtzbmlwXQ0KPiA+ICAgICBtYXggbnVtYmVyIG9mIGNoYXJhY3Rl cnMgZm9yIHRvdGFsIG1lc3NhZ2UNCj4gPg0KPiA+DQo+ID4gRG9uJ3Qgd2UgYWxyZWFkeSBoYXZl IHRoaXMgd2l0aCBTSVpFPw0KPg0KPg0KPiBTbywgeW91IGFyZSBzYXlpbmcgdGhhdCBpdCB3YXMg YSBnb29kIGlkZWEgZm9yIG1lIGJvdGggdG8gbGlzdCBhIHZhcmlldHkgb2YNCj4gcG9zc2liaWxp dGllcyBhbmQgdG8gbm90ZSB0aGF0IEkgd2Fzbid0IGFkdm9jYXRpbmcgZm9yIGFueSBvZiB0aGVt IGJ1dCBtZXJlbHkNCj4gbWVhbnQgdGhlbSBhcyBleGFtcGxlcz8NCj4NCj4gSSBhZ3JlZS4uLg0K Pg0KPg0KPiBkLw0KPg0KPiAtLQ0KPiBEYXZlIENyb2NrZXINCj4gQnJhbmRlbmJ1cmcgSW50ZXJu ZXRXb3JraW5nDQo+IGJiaXcubmV0DQo+DQo+IC0tDQo+IEVtYWlsY29yZSBtYWlsaW5nIGxpc3QN Cj4gRW1haWxjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VtYWlsY29yZQ0KPiBfXzshIUNRbDNt Y0hYMkEhV1JYY2ZzSksyM1J4b3JndzlzV200NndabVF1c2Y4Zmw3QlVrdkRXNDcxSHNCallhDQo+ IElsT1NOVVh4MVBpbmFfRUxYWklYJA0K From nobody Fri Mar 12 12:22: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 2D0453A112E for ; Fri, 12 Mar 2021 12:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnWOXFJFA5yE for ; Fri, 12 Mar 2021 12:22:05 -0800 (PST) Received: from wforward5-smtp.messagingengine.com (wforward5-smtp.messagingengine.com [64.147.123.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD673A1129 for ; Fri, 12 Mar 2021 12:22:05 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailforward.west.internal (Postfix) with ESMTP id 866311AED; Fri, 12 Mar 2021 15:22:04 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 12 Mar 2021 15:22:04 -0500 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 :reply-to:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=wUgK7Nbjxr+g8fx6NwocaQqtVvTx0 3JDlWPXi34J8QY=; b=P9WHS+WTezwUvkP0nhmKKU8FvrFnADU5Oqa9ETmDdj4fc nrNuiciwY8J3WgFlpH64Is499XhyBEEcLDrCDs8gae3uX8x3uocojRRKzMZabgL1 QPd71E211Q2TMa/pDp7kmTXxg9P/zHi8+RpE/Z2UTtcYO3m8BGVOZZa15I2gLm+z WBuL+tmDQbAptN2Lsy+qf0yz3UL9w0R8fuJrdOKSFxuA4ef3Sx9eIupEvYPxosQ0 jeLFkeponAvrGUVqTSUB3ACJn58JFxiWyDuwPAAy61YkHlvgicYClz/zSilk1/YJ FFTZe8wwyqWbkehjGfclFc3lhPJPSz1d9VeGqrfUA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvvddgudefhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpehruffvfhfhohfkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpeff rghvvgcuvehrohgtkhgvrhcuoeguhhgtsegutghrohgtkhgvrhdrnhgvtheqnecuggftrf grthhtvghrnhepkedtleffgfdvieduhfdvhefhjedvvdduieekvdeufeeigfetheefgeef vefftedunecuffhomhgrihhnpegssghifidrnhgvthenucfkphepuddtkedrvddviedrud eivddrieefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepughhtgesuggtrhhotghkvghrrdhnvght X-ME-Proxy: Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) by mail.messagingengine.com (Postfix) with ESMTPA id D080624005D; Fri, 12 Mar 2021 15:21:59 -0500 (EST) Reply-To: dcrocker@bbiw.net To: "Brotman, Alex" , "dcrocker@bbiw.net" , Todd Herr Cc: "emailcore@ietf.org" , Jeremy Harris References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <5772045E-2EB3-44B7-BCA8-0135DF809C62@dukhovni.org> <68cd718f-3bf5-3906-25e1-94ecfdb0ba2f@wizmail.org> <5aef8939-092d-b6e9-9662-4599251fb920@dcrocker.net> <05d6b2cb-ae9f-83eb-28cc-b5cee030906a@wizmail.org> <36694a3d-6b25-37aa-7c18-a3a1bbba61be@dcrocker.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <29350ca2-f1eb-092f-f1ec-8bb9e1c6ea55@dcrocker.net> Date: Fri, 12 Mar 2021 12:21:58 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; 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 Archived-At: Subject: Re: [Emailcore] Proposed ESMTP keyword RCPTLIMIT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 20:22:12 -0000 On 3/12/2021 12:11 PM, Brotman, Alex wrote: > This may not work well in practice. It's entirely possible that the number of permitted recipients (or any similar limitation) could change during the session as more is learned about the sender. I have two responses: 1. Wow. 2. Don't advertise a number. If the practice is widespread, then yeah, it's probably not worth doing the particular option. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Mar 12 12:25: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 ABA9A3A1189 for ; Fri, 12 Mar 2021 12:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, 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 wn4HEHt0Gflt for ; Fri, 12 Mar 2021 12:25:56 -0800 (PST) Received: from mail-ob1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id 850223A1188 for ; Fri, 12 Mar 2021 12:25:56 -0800 (PST) Received: (qmail 3489 invoked from network); 12 Mar 2021 20:25:55 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (261ac96e-8371-11eb-b724-8f75ed356ad7); Fri, 12 Mar 2021 12:25:55 -0800 To: emailcore@ietf.org References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <5772045E-2EB3-44B7-BCA8-0135DF809C62@dukhovni.org> <68cd718f-3bf5-3906-25e1-94ecfdb0ba2f@wizmail.org> <5aef8939-092d-b6e9-9662-4599251fb920@dcrocker.net> <05d6b2cb-ae9f-83eb-28cc-b5cee030906a@wizmail.org> <36694a3d-6b25-37aa-7c18-a3a1bbba61be@dcrocker.net> <29350ca2-f1eb-092f-f1ec-8bb9e1c6ea55@dcrocker.net> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: Date: Fri, 12 Mar 2021 12:25:55 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <29350ca2-f1eb-092f-f1ec-8bb9e1c6ea55@dcrocker.net> 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: 261ac96e-8371-11eb-b724-8f75ed356ad7 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] Proposed ESMTP keyword RCPTLIMIT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 20:25:58 -0000 We do that.. rate limiter changes depending on sending pattern.. On 2021-03-12 12:21 p.m., Dave Crocker wrote: > On 3/12/2021 12:11 PM, Brotman, Alex wrote: >> This may not work well in practice.  It's entirely possible that the >> number of permitted recipients (or any similar limitation) could >> change during the session as more is learned about the sender. > > I have two responses: > >    1.  Wow. > >    2.  Don't advertise a number. > > If the practice is widespread, then yeah, it's probably not worth doing > the particular option. > > d/ > -- "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 Mar 12 12:32: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 4E0463A1204 for ; Fri, 12 Mar 2021 12:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=jzdRy11O; dkim=pass (2048-bit key) header.d=taugh.com header.b=IH6Oeb0q Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eu1XSvOTZ9G3 for ; Fri, 12 Mar 2021 12:32:27 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F183A1201 for ; Fri, 12 Mar 2021 12:32:27 -0800 (PST) Received: (qmail 45588 invoked from network); 12 Mar 2021 20:32:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=b211.604bcfd9.k2103; bh=fWEve0EPca15/6FZOHw4e/f+G1BsCBMmazVn9pMwwjU=; b=jzdRy11Owvro0GfFDAe9yjiVfUxTsDFFJdl2LvCgV2IcjOQYyD5jd55jRd5plUVNdcJW9qNRfYwfR1lMCbTdHPDcEvHQHJuNZNrv62ft+sWMpvvPOIoVEvH/LjCBAlTc94UMgQmpi1/oFT0IqLPs2HTCauw0Pjfc5mvOeuK9Uhb/CUUVIVyMtH2jRQXRiPD2nGLbpiEKCgEgtL6VldU0V1IFjPECtlAb097B84UR6u638KNc82XUaO1lDDHa71jDMYwOk0kmKTEbmBnhRgd6DKTsjWyIz0O+7saO8f12gPLfHwhdE7NHIO0wb+DHeJV5na32vsNAE84+T9YPNuNG0w== 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=b211.604bcfd9.k2103; bh=fWEve0EPca15/6FZOHw4e/f+G1BsCBMmazVn9pMwwjU=; b=IH6Oeb0qRMWklrjMfLho1YYfr6+J5T5Z78rWMyfUMFByc5drr2THZLgmlnBqZbqBgRgeRB9D++b5MJXKhMuaIt6FzK01q66HD0HTxBXU496eYsC2AdESCWK/I+kJMa7iBis1eT5j6wg5q9p/IWQB8MPH2PYr7XtiLuSwwbOFm8MgER9X2iHfhkeDox5qkfICA6zw+XBZSFNJzOrUeGoVDJk7dc/JYxQXZbZtmDCKqTWb4Q/CTAcqx4iq9Ms0p8qLZk/9xaUKZHC1HSpidQFKgjq5+mG3hZk1ipwyH9ar4zXgdEd1R+08Drnj3lIimb7Ev0Od33RrxBV1PrH9tkh1RQ== 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; 12 Mar 2021 20:32:25 -0000 Received: by ary.qy (Postfix, from userid 501) id F3739701E4C5; Fri, 12 Mar 2021 15:32:24 -0500 (EST) Date: 12 Mar 2021 15:32:24 -0500 Message-Id: <20210312203224.F3739701E4C5@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: laura@wordtothewise.com In-Reply-To: <77B21231-47EA-4CA6-A665-5880B6A54D4D@wordtothewise.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] Proposed ESMTP keyword RCPTLIMIT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Mar 2021 20:32:29 -0000 It appears that Laura Atkins said: >> max line length\ >> max number of lines >> max number of characters for total message >> MIME limits (eg., nesting depth) >> Unicode or other character limits I don't think it is a good idea to provide standard ways to say that an implementation doesn't comply with a standard. There's a line length limit in the spec, it's not hard to support. >Is there a place for ‘max connections’ - a number of places already limit the number of maximum connections that >any sending system can make at one time. A way to mechanically advertise that might be useful. Intereesting question but then I ask max connections from what, a single IP, a /24, something else? I also worry this could be close to saying here's how to DDoS me. Also for this particular case I'd say the excess connection should greet with 421 and enhanced status code (it's be 4.3.7) to say too many connections. R's, John From nobody Sat Mar 13 06: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 14D0F3A10C0 for ; Sat, 13 Mar 2021 06:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 UpuMmlQNIF-Y for ; Sat, 13 Mar 2021 06:55:09 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 599153A10BF for ; Sat, 13 Mar 2021 06:55:09 -0800 (PST) Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id C87749F149 for ; Sat, 13 Mar 2021 06:55:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1615647308; bh=wq+xUPNH+jIdLkFcbVhiV5fNYhZfJQw7jiBjg9YGuF8=; h=From:Subject:Date:References:To:In-Reply-To:From; b=JQcqnHGiLz1Pr2ZScb/QW7Kda8K4FbUNP131kT+v5u/J2CKLMIuTLXQ5svwof+qGj aBeT/72jgNURVMvX593LQYSQAgufXe2pqHILka8a8jamQLaqM3UXo7h7hj39Fehhch ITN+DxVME0BqH/RfH6zUmKchBDmKLTCODCjSeYWA= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_53E2239E-BE70-46FE-8BF2-F89775E82068" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 13 Mar 2021 14:55:05 +0000 References: <20210312203224.F3739701E4C5@ary.qy> To: emailcore@ietf.org In-Reply-To: <20210312203224.F3739701E4C5@ary.qy> Message-Id: <99914607-1DBE-4782-AE81-04FC77D29028@wordtothewise.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Emailcore] Proposed ESMTP keyword RCPTLIMIT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 13 Mar 2021 14:55:11 -0000 --Apple-Mail=_53E2239E-BE70-46FE-8BF2-F89775E82068 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 12 Mar 2021, at 20:32, John Levine wrote: >=20 > It appears that Laura Atkins said: >>> max line length\ >>> max number of lines >>> max number of characters for total message >>> MIME limits (eg., nesting depth) >>> Unicode or other character limits >=20 > I don't think it is a good idea to provide standard ways to say that = an > implementation doesn't comply with a standard. There's a line length = limit > in the spec, it's not hard to support. >=20 >> Is there a place for =E2=80=98max connections=E2=80=99 - a number of = places already limit the number of maximum connections that >> any sending system can make at one time. A way to mechanically = advertise that might be useful.=20 >=20 > Intereesting question but then I ask max connections from what, a = single IP, a /24, > something else? =20 That would be for the folks advertising to say what they=E2=80=99re = using and what they=E2=80=99re limiting by. The limits are actively in = place, it=E2=80=99s just do we want to describe them in a more formal = way.=20 > I also worry this could be close to saying here's how to DDoS me. The limits I was thinking of are policy not technology. Alex brings up a = good point that the limits are not set in stone but do change depending = on the reputation of the sender / mailstream / IP address.=20 > Also for this particular case I'd say the excess connection should = greet > with 421 and enhanced status code (it's be 4.3.7) to say too many = connections. Makes sense.=20 laura=20 --=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=_53E2239E-BE70-46FE-8BF2-F89775E82068 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 12 Mar 2021, at 20:32, John Levine <johnl@taugh.com> = wrote:

It appears that Laura Atkins  <laura@wordtothewise.com> said:
max line = length\
max number of lines
max number of = characters for total message
MIME limits (eg., nesting = depth)
Unicode or other character limits

I don't think it is = a good idea to provide standard ways to say that an
implementation doesn't comply with a standard.  There's = a line length limit
in the spec, it's not hard to = support.

Is there a place for =E2=80=98max connections=E2=80=99 - a = number of places already limit the number of maximum connections that
any sending system can make at one time. A way to = mechanically advertise that might be useful.

Intereesting question but then I = ask max connections from what, a single IP, a /24,
something= else?  

That = would be for the folks advertising to say what they=E2=80=99re using and = what they=E2=80=99re limiting by. The limits are actively in place, = it=E2=80=99s just do we want to describe them in a more formal = way. 

I also worry this could be close to saying = here's how to DDoS me.

The limits I was thinking of are policy not = technology. Alex brings up a good point that the limits are not set in = stone but do change depending on the reputation of the sender / = mailstream / IP address. 

Also for this = particular case I'd say the excess connection should greet
with 421 and enhanced status code (it's be 4.3.7) to say too = many connections.

Makes = sense. 

laura 

-- 
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=_53E2239E-BE70-46FE-8BF2-F89775E82068-- From nobody Mon Mar 15 08:11: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 90F173A122B; Mon, 15 Mar 2021 08:11:04 -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=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 ONkMaiozeVGE; Mon, 15 Mar 2021 08:11:02 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02EE03A1353; Mon, 15 Mar 2021 08:11:01 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RWOUM521PS0073BL@mauve.mrochek.com>; Mon, 15 Mar 2021 08:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1615820758; bh=kcJNGNEm4JEIxXWHkl0Oes5k/E0PIOpweKMtIr4LCms=; h=Date:From:Subject:In-reply-to:References:To:From; b=CxRwG3/d+FRsI0/J4F1GMltC6Mm8deD0/DArnu38eCxfoRZ1l2FeuGD6SZ//HBMS6 lBlonebm67qnOx/08OPpR72xLsBR9xm9EDp3E6XhXlPfSIMBg6ZFhoNG0ybuWgXjX1 8NTE11IrGanBxveutEoqXkX09Hs0AbH63gk8sQbc= 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 <01RWJORF3ZF4005PTU@mauve.mrochek.com>; Mon, 15 Mar 2021 08:05:55 -0700 (PDT) Message-id: <01RWOUM3HK0Q005PTU@mauve.mrochek.com> Date: Mon, 15 Mar 2021 07:59:09 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 12 Mar 2021 15:32:24 -0500" <20210312203224.F3739701E4C5@ary.qy> References: <77B21231-47EA-4CA6-A665-5880B6A54D4D@wordtothewise.com> <20210312203224.F3739701E4C5@ary.qy> To: emailcore@ietf.org, ietf-smtp@ietf.org Archived-At: Subject: Re: [Emailcore] Proposed ESMTP keyword RCPTLIMIT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 15 Mar 2021 15:11:05 -0000 The idea of a limits extension has come up several times before, but for various reasons never went forward. I think this extension is an important thing to have, so I've put together the beginnings of a specification: https://datatracker.ietf.org/doc/draft-freed-smtp-limits/ (I've tried to incorporate most of the ideas I've seen on the list, but have probably missed some.) Since this isn't directly relevant to emailcore, furthr discussion should be taken to the ietf-smtp list, which I have cc'ed. Ned P.S. One thing that's definitely missing is an acknowldgements section. Apologies for the omissiom, but I ran out of time. It will be the first thing I add to -01. From nobody Mon Mar 15 14:40: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 DBFE03A0FE5; Mon, 15 Mar 2021 14:40: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=sonnection.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LC02QuwDSdsl; Mon, 15 Mar 2021 14:40:17 -0700 (PDT) Received: from mx30.mailtransaction.com (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CFE93A0FE7; Mon, 15 Mar 2021 14:40:17 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx30.mailtransaction.com (Postfix) with ESMTP id 4Dzqb20Nprz2nGPR; Mon, 15 Mar 2021 22:40:14 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 mx30.mailtransaction.com 4Dzqb20Nprz2nGPR DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1615844414; bh=l/k/x2rsPNdxoW1EqaEVL8O81/rI5Sjl39ubuH4m+YY=; h=Subject:To:From:Message-ID:Date:From; b=BNDbbF6QGO5iw/8a35qJ483JCL9012tueLVFxKsrO6OhdMm18frUSRd5FHnKc0bJx Kyb2SRDKqSPXZybENVi2xFr89oQZ5SSjGJ2QpFvZFkNi0xtfmJPjF61wuM0r3Ub8/I z2jscz3Kkr1ivffOk2ap7KH2e/Gzy+PttgV67xs8= Received: from tiger.sonnection.nl (D57E1706.static.ziggozakelijk.nl [213.126.23.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx24.mailtransaction.com (Postfix) with ESMTPS id 4Dzqb1627fz1tp4q; Mon, 15 Mar 2021 22:40:13 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tiger.sonnection.nl (Postfix) with ESMTP id 95C654223CF; Mon, 15 Mar 2021 22:40:13 +0100 (CET) X-Virus-Scanned: amavisd-new at tiger.sonnection.nl Received: from tiger.sonnection.nl ([127.0.0.1]) by localhost (tiger.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QhJHyLM7eXah; Mon, 15 Mar 2021 22:40:13 +0100 (CET) Received: from [192.168.40.49] (cat.sonnection.nl [192.168.40.49]) by tiger.sonnection.nl (Postfix) with ESMTPSA id 778FD4223CE; Mon, 15 Mar 2021 22:40:13 +0100 (CET) To: Ned Freed , emailcore@ietf.org, ietf-smtp@ietf.org References: <77B21231-47EA-4CA6-A665-5880B6A54D4D@wordtothewise.com> <20210312203224.F3739701E4C5@ary.qy> <01RWOUM3HK0Q005PTU@mauve.mrochek.com> From: "Rolf E. Sonneveld" Organization: Sonnection B.V. Message-ID: <44832734-bf0f-2458-69b8-23eee823c1bc@sonnection.nl> Date: Mon, 15 Mar 2021 22:40:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <01RWOUM3HK0Q005PTU@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Emailcore] [ietf-smtp] Proposed ESMTP keyword RCPTLIMIT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 15 Mar 2021 21:40:23 -0000 Hi, Ned, On 15/03/2021 15:59, Ned Freed wrote: > The idea of a limits extension has come up several times before, but > for various reasons never went forward. > > I think this extension is an important thing to have, so I've put together the > beginnings of a specification: > > https://datatracker.ietf.org/doc/draft-freed-smtp-limits/ > > (I've tried to incorporate most of the ideas I've seen on the list, but have > probably missed some.) > > Since this isn't directly relevant to emailcore, furthr discussion should be > taken to the ietf-smtp list, which I have cc'ed. > > Ned > > P.S. One thing that's definitely missing is an acknowldgements section. > Apologies for the omissiom, but I ran out of time. It will be the first thing I > add to -01. In chapter 4 there is a copy/paste error: all three paragraphs within this chapter refer to: "Description: RCPTMAX specifies the maximum number of [...]" This should be: "Description: MAILMAX specifies the maximum number of [...]" (par. 4.1) and "Description: RCPTDOMAINMAX specifies the maximum number of [...]" (par. 4.3) which makes me think you wrote par. 4.2 before you wrote the other paragraphs :-) /rolf From nobody Mon Mar 15 15:06: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 B42D53A10A1; Mon, 15 Mar 2021 15:06:09 -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 WNLBN_f7YQ5I; Mon, 15 Mar 2021 15:06:08 -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 BA3B33A10A0; Mon, 15 Mar 2021 15:06:08 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RWP93T45JK006CZG@mauve.mrochek.com>; Mon, 15 Mar 2021 15:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1615845664; bh=S/IjcVRaky5AWhi7eRuCxL5OwfJH0yQKe59GvaZW99E=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=nV4xhHClABZSAwt7/wojUilea2cv92vV/10yqQihDWKHZx4NFjA4EIISgxhECeqlW OeyiojvSiQeJ65h1KdUYAInL1oa9JF30k7/ZSeKKEewb7yGPeoGevORoSQr7MeOFS/ N7+UGH0J3qNA6qXGAb1g7107n9lDUOjyTCHa7xQY= 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 <01RWJORF3ZF4005PTU@mauve.mrochek.com>; Mon, 15 Mar 2021 15:01:01 -0700 (PDT) Cc: Ned Freed , emailcore@ietf.org, ietf-smtp@ietf.org Message-id: <01RWP93QV5LS005PTU@mauve.mrochek.com> Date: Mon, 15 Mar 2021 15:00:38 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 15 Mar 2021 22:40:13 +0100" <44832734-bf0f-2458-69b8-23eee823c1bc@sonnection.nl> References: <77B21231-47EA-4CA6-A665-5880B6A54D4D@wordtothewise.com> <20210312203224.F3739701E4C5@ary.qy> <01RWOUM3HK0Q005PTU@mauve.mrochek.com> <44832734-bf0f-2458-69b8-23eee823c1bc@sonnection.nl> To: "Rolf E. Sonneveld" Archived-At: Subject: Re: [Emailcore] [ietf-smtp] Proposed ESMTP keyword RCPTLIMIT X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 15 Mar 2021 22:06:10 -0000 > In chapter 4 there is a copy/paste error: all three paragraphs within > this chapter refer to: > "Description: RCPTMAX specifies the maximum number of [...]" > This should be: > "Description: MAILMAX specifies the maximum number of [...]" (par. 4.1) > and > "Description: RCPTDOMAINMAX specifies the maximum number of [...]" (par. > 4.3) > which makes me think you wrote par. 4.2 before you wrote the other > paragraphs :-) Got me on that one! Ned From nobody Wed Mar 17 13:28: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 A70DF3A134E for ; Wed, 17 Mar 2021 13:28:05 -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 jGgOe6ao1GfR for ; Wed, 17 Mar 2021 13:28:03 -0700 (PDT) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 A3A8C3A134C for ; Wed, 17 Mar 2021 13:28:03 -0700 (PDT) Received: by mail-qv1-xf2c.google.com with SMTP id 30so2050293qva.9 for ; Wed, 17 Mar 2021 13:28:03 -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=Rrqp1jWBWOZhXq3prK/dfoLw05sIypqCwZskRGVL1Tw=; b=ezCF1Kwecql3U8Q8k60q7KFscaQdRmtAGdqqDjkWLY0us8iake19mnOTemKV5OD5hH LSeJODTsjcEd6ymBdzxfIjeDbspl5LlboY5v8xDgzLeY5wir/GZO+3lFnKjPneUdBjJn Tg+S+FuxZaidbW0udw3JhviDbbJhCCbDNg1W6oQHRnUGhtQs0n/4+EPCXAXhJwKKJF6h 5gisuw7l/KlX4Q3Y+gVj7E1pj1Db069uc0KzqUNwphZnrzNqmNErOmG1qJXTir3x4PhL UWFia7CqvrIPZbcYUEamzN/6p64mMq40AgVe09T7TH/IpnKmzZjRHz22wFuJaIy9o3sk jAnA== 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=Rrqp1jWBWOZhXq3prK/dfoLw05sIypqCwZskRGVL1Tw=; b=Bk8JxT9z3/Kovb25nPylBc62yo70KCUSGBcHd6vSi5zy/gmcYf4JXMbLA8L1D88RhC HbNx4ma1B2E7FX4ClFHQKAh/RZT2DdGWT8fbe170HQWBAMg7HsH9wHt2htS0eR4xhIzL 8qnrIScGB+buV4E8ziZioaNO1bdEH1Ttz2qRZJWvIKPsb0HLpS1RvJv9H7JFVg5gy2g1 weC19AYVfyX5NleWdVtSl6Eq45HZMobx5pc2ehaTwDUvYeaT9i4ZeeYGV60LyhBp7z4Z D5i3FW3LNwRrvwmdT6UhNZMaPy0WYE7yr9iqPLoXV1tTq9t0flXDmQ2bBN40GwmBX2MQ 3OQQ== X-Gm-Message-State: AOAM532BZ3cp81CF2zUIdyc6ilydlP287t/6Qlyu2STPUIJU2mol4lIM su4kOHRd5ymZWXgQVokZF1XLqFnzT5U0c6eynTO80xDq+rugyg== X-Google-Smtp-Source: ABdhPJy/F9gj47D/KGn5H/9VLfciXJIJ0KRfgsRj8YWKkqIBotXcpwkmgKUndBXjkgjJyAt45T0Rq9NiROVjfFyBzU8= X-Received: by 2002:a05:6214:d8a:: with SMTP id e10mr966100qve.39.1616012880471; Wed, 17 Mar 2021 13:28:00 -0700 (PDT) MIME-Version: 1.0 From: Todd Herr Date: Wed, 17 Mar 2021 16:27:44 -0400 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000b17a8705bdc15159" Archived-At: Subject: [Emailcore] Issue #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: Wed, 17 Mar 2021 20:28:06 -0000 --000000000000b17a8705bdc15159 Content-Type: text/plain; charset="UTF-8" The text of the subject ticket reads: Dave Crocker wrote: Section 3.6.2 says: This specification does not deal with the verification of return paths for use in delivery notifications. Recent work, such as that on SPF [29] and DKIM [30] [31], has been done to provide ways to ascertain that an address is valid or belongs to the person who actually sent the message. It should say: This specification does not deal with the verification of return paths for use in delivery notifications. Notes: Neither SPF nor DKIM determine "validity" of an address. SPF determines whether an IP Address is 'authorized' to send mail with a particular domain name in the return address, but that does not validate the entire address, nevermind validating any destination or author addresses. DKIM has nothing at all to do with any existing address or domain name elsewhere in the message. So I suggest merely dropping the problematic sentence. The full text of the paragraph at issue reads: This specification does not deal with the verification of return paths for use in delivery notifications. Recent work, such as that on SPF [29 ] and DKIM [30 ] [31 ], has been done to provide ways to ascertain that an address is valid or belongs to the person who actually sent the message. 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. I second Dave's suggestion, and propose that the paragraph be edited to read: 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. I propose 31 March as the deadline for discussion on this ticket. -- *Todd Herr* | Sr. Technical Program Manager *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. --000000000000b17a8705bdc15159 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The text of the subject ticket reads:

Dave Crocker wr= ote:

Section 3.6.2 says:

This spe= cification does not deal with the verification of return
paths for use i= n delivery notifications. Recent work, such as that
on SPF=C2=A0[29]=C2=A0and DKIM=C2=A0[30]=C2=A0[31], ha= s been done to provide ways to
ascertain that an address is valid or bel= ongs to the person who
actually sent the message.

It should say:

This specification does not= deal with the verification of return
paths for use in delivery notifica= tions.

Notes:

Neither SPF nor DK= IM determine "validity" of an address. SPF determines whether an = IP Address is 'authorized' to send mail with a particular domain na= me in the return address, but that does not validate the entire address, ne= vermind validating any destination or author addresses. DKIM has nothing at= all to do with any existing address or domain name elsewhere in the messag= e.

So I suggest merely dropping the problematic sentence.


The full text of the paragraph at issue reads:

   This specification=
 does not deal with the verification of return
   paths for use in delivery notifications.  Recent work, such as that
   on SPF [29] and DKIM [30] [31], has been done to provide ways to
   ascertain that an address is valid or belongs to the person who
   actually sent the message.  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=C2=A0
      recommended at=
 this time.

I s=
econd Dave's suggestion, and propose that the paragraph be edited to re=
ad:
=

   This specification does not deal w=
ith 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=C2=A0
      recommended at this time.
=

<=
/pre>
I propose 31 Mar=
ch as the deadline for discussion on this ticket.

-- 
Todd Herr | Sr. Technical Program Manage=
r
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.
--000000000000b17a8705bdc15159-- From nobody Wed Mar 17 13:53: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 9B8CE3A1471 for ; Wed, 17 Mar 2021 13:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGoguJJx5rdi for ; Wed, 17 Mar 2021 13:53:05 -0700 (PDT) Received: from forward5-smtp.messagingengine.com (forward5-smtp.messagingengine.com [66.111.4.239]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D67B3A146F for ; Wed, 17 Mar 2021 13:53:05 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailforward.nyi.internal (Postfix) with ESMTP id 749EF194097C; Wed, 17 Mar 2021 16:53:03 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 17 Mar 2021 16:53:03 -0400 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 :reply-to:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=56ENlbz0Qp5eB9nDBILfS5DJXP+1t 5G4ROcY75m+e/Y=; b=O5X1zybQgyxTt0jn9F+gbXFkmhwBa+vKA0FyoF9V38cO4 FGuaNNQB8G4fJoYJZbOtfA68lx34kXVEahz0VkWk6KevW9RIMCRDW4V88tb2k5k/ eFuqEtkTyg87tC+hrg+AoIdxMYDtQ8Z6JeNo0VOUGe3uWekoEQk9PU+LgSeGvYjR 1u03DDmvzULOZCBVeuNxXo/ucHRAKcHMM4rDCFZDrnLRD4uQusf4JzKl7IJoenbl hZPJBurN3IeIaozbm6vOh/9xJbln22H997eDVWlxEjuBZo0qBcV7EEweHplyUdlG 1ecQmd5O5OFJLBXw/98cxCEzqLSAubpX5DUMKtA9w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudefgedgudegiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheprhfuvfhfhfhokffffgggjggtgf esthejredttdefjeenucfhrhhomhepffgrvhgvucevrhhotghkvghruceoughhtgesuggt rhhotghkvghrrdhnvghtqeenucggtffrrghtthgvrhhnpeektdelfffgvdeiudfhvdehhf ejvddvudeikedvueefiefgteehfeegfeevffetudenucffohhmrghinhepsggsihifrdhn vghtnecukfhppedutdekrddvvdeirdduiedvrdeifeenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguhhgtsegutghrohgtkhgvrhdrnhgvth X-ME-Proxy: Received: from [192.168.0.102] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) by mail.messagingengine.com (Postfix) with ESMTPA id B24811080063; Wed, 17 Mar 2021 16:53:01 -0400 (EDT) Reply-To: dcrocker@bbiw.net To: Todd Herr , emailcore@ietf.org References: From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Wed, 17 Mar 2021 13:52:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; 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 Archived-At: Subject: Re: [Emailcore] Issue #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: Wed, 17 Mar 2021 20:53:07 -0000 On 3/17/2021 1:27 PM, Todd Herr wrote: > I second Dave's suggestion, and propose that the paragraph be edited to > read: > > > 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. > > I propose 31 March as the deadline for discussion on this ticket. I think the intent, here, is reasonable, but the second sentence is problematic. It uses normative language for a non-specification. In terms of the scope of a specification, implementations are always free to do things that are outside that scope. The specification has no business purporting to give permission. That is, normative language needs to be restricted to text that specifies actual protocol or format details. Similarly language like 'at this time' turns out not to have any real meaning in a specification produced by the IETF. Statements implying possible future activity or changes really are meaningless. So, perhaps a small tweak: This specification does not deal with the verification of return paths for use in delivery notifications. Server efforts to verify the return path using it is outside the scope of this specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Mar 17 17:02: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 D700D3A1878; Wed, 17 Mar 2021 17:02: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 wAVEXJ-ZnXZc; Wed, 17 Mar 2021 17:02:29 -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 9C8CA3A1877; Wed, 17 Mar 2021 17:02:29 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lMg7P-000Ijb-Pb; Wed, 17 Mar 2021 20:02:27 -0400 Date: Wed, 17 Mar 2021 20:02:20 -0400 From: John C Klensin To: dcrocker@bbiw.net, Todd Herr , emailcore@ietf.org Message-ID: <6BCAF72097DD9E309ED3271A@PSB> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Issue #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: Thu, 18 Mar 2021 00:02:31 -0000 --On Wednesday, March 17, 2021 13:52 -0700 Dave Crocker wrote: > So, perhaps a small tweak: > > This specification does not deal with the verification > of return paths for use in delivery notifications. Server > efforts to verify the return path using it is outside the > scope of this specification. Dave, I cannot attach a clear antecedent to "it" in the second sentence and, of course, "Server efforts... _are_". Did you intend something closer to: Server efforts to verify a return path for that purpose are outside the scope of this specification. (which more clearly points back to delivery notification) or Server efforts to verify return paths are outside the scope of this specification. (those efforts are out of scope whether for delivery notification or any other purpose) or even Mechanisms that might be used by servers to verify return paths are outside the scope of this specification. (somewhat more extensive in coverage but perhaps closer to the principle that verification issues are out of scope) best, john From nobody Wed Mar 17 17:23: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 A85683A18D3 for ; Wed, 17 Mar 2021 17:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfmmVh_Y4zSv for ; Wed, 17 Mar 2021 17:23:49 -0700 (PDT) Received: from forward4-smtp.messagingengine.com (forward4-smtp.messagingengine.com [66.111.4.238]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147D13A18D2 for ; Wed, 17 Mar 2021 17:23:48 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailforward.nyi.internal (Postfix) with ESMTP id 0C7751940DE4 for ; Wed, 17 Mar 2021 20:23:47 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 17 Mar 2021 20:23:47 -0400 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 :reply-to:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=3a4qXaEV72nYl7V4hSgym3UZxZyQv 3THTXN58zn6dNk=; b=h2QQURMvSi84gQb+M4tfVD+DDdsViOs3aLi3qA5/r1PAl aRujfvr5Ka4yzDw/vAvECJqSQggAVAjgfMrg8hvj4wg9aOGoxmv4f5LodQRvEpOS 7aXjoaYZLJ70qNtMommVbQZFvVqFVdhGup+NcRDB3/pHyWleoYG5X94mWKhwjP0u /g5V0pC8QF6voJGJ8GYbJzSwrkmi8DCM7mIWnKcAu8/exHgHUM/nJoRo9B8vIIEE mqINGHhYBThOrxUe2K8j+8fhik8ra9aIUa+H6CuYkFH4mjctIWAlrkjAumGIXdfd gfg8JuMWrA9uI9o8ucNtbZfGcAYVCmL0M4s0h8rrw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudefhedgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpehruffvfhfhohfkffgfgggjtgfgse htjeertddtfeejnecuhfhrohhmpeffrghvvgcuvehrohgtkhgvrhcuoeguhhgtsegutghr ohgtkhgvrhdrnhgvtheqnecuggftrfgrthhtvghrnhepkedtleffgfdvieduhfdvhefhje dvvdduieekvdeufeeigfetheefgeefvefftedunecuffhomhgrihhnpegssghifidrnhgv thenucfkphepuddtkedrvddviedrudeivddrieefnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepughhtgesuggtrhhotghkvghrrdhnvght X-ME-Proxy: Received: from [192.168.0.102] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 779621080067 for ; Wed, 17 Mar 2021 20:23:45 -0400 (EDT) Reply-To: dcrocker@bbiw.net To: emailcore@ietf.org References: <6BCAF72097DD9E309ED3271A@PSB> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Wed, 17 Mar 2021 17:23:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <6BCAF72097DD9E309ED3271A@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Issue #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: Thu, 18 Mar 2021 00:23:51 -0000 >> This specification does not deal with the verification >> of return paths for use in delivery notifications. Server >> efforts to verify the return path using it is outside the >> scope of this specification. To clarify and make more crisp: This specification does not deal with the verification of a return path. Server efforts to verify a return path are outside the scope of this specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Mar 18 07:25: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 D05053A2CA6 for ; Thu, 18 Mar 2021 07:25:36 -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 6nUCVkm7bd84 for ; Thu, 18 Mar 2021 07:25: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 9FE563A2CA4 for ; Thu, 18 Mar 2021 07:25:35 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lMtag-000MmB-Ir; Thu, 18 Mar 2021 10:25:34 -0400 Date: Thu, 18 Mar 2021 10:25:29 -0400 From: John C Klensin To: dcrocker@bbiw.net, emailcore@ietf.org Message-ID: In-Reply-To: References: <6BCAF72097DD9E309ED3271A@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] Issue #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: Thu, 18 Mar 2021 14:25:37 -0000 --On Wednesday, March 17, 2021 17:23 -0700 Dave Crocker wrote: > >>> This specification does not deal with the verification >>> of return paths for use in delivery notifications. Server >>> efforts to verify the return path using it is outside the >>> scope of this specification. > > > To clarify and make more crisp: > > > This specification does not deal with the verification > of a return path. Server efforts to verify a return path are > outside the scope of this specification. Dave, this is at least as reasonable as any of the suggestions I made in the note pointing out the problem with your earlier text. Unless someone objects or has a yet-better suggestion, I'll incorporate it into the working version of 5321bis. My only concern is that there may be a substantive difference between saying: * Out of scope and you are on your own and * Servers MAY try to verify if they can find a way to do so that they consider appropriate The latter, even without references, is a bit closer to reflecting (or at least hinting at) with supposed current practice and is closer to the intent of the paragraph we are replacing. I'm agnostic about that choice, but would like to understand WG consensus on the topic rather than excluding the second option because we have gotten hung up on worthsmithing the first one. john From nobody Thu Mar 18 09: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 037B53A2FA6 for ; Thu, 18 Mar 2021 09:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H87Ztbff4G4K for ; Thu, 18 Mar 2021 09:59:25 -0700 (PDT) Received: from wforward5-smtp.messagingengine.com (wforward5-smtp.messagingengine.com [64.147.123.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C273A2FA4 for ; Thu, 18 Mar 2021 09:59:25 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailforward.west.internal (Postfix) with ESMTP id EAA3B1686; Thu, 18 Mar 2021 12:59:19 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 18 Mar 2021 12:59:20 -0400 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 :reply-to:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=YfIguDm1MDWfLxw3z3xr5vQUdSP5G N0p8LRg3U09s2Q=; b=D2w2+IyjWcKgK5Ti8zcudQhMCa8TZmRldE//mRWhbhnbs wUZosf977CaxHCZsBC4LPt2fOxZNtFpAqzZmZkYom8N0JlOZVXmPtvNJUj3qG5PH +C5R+/BjI4M53PsrbrajQK+PuZXtrdHeM8m5H0p7fETCuhMj2/vlzp9/UUgi4Egt 5DqN+dyB7YiGIBcdc6tu6kU35cNm1MBe4nLPZv+9SZiiixYTR+SJetFpSpTz8cog QEebJug7GBOxihfZUFuPy4HWwfuULhMRm7SVwbLOA55eBKD8t2ImbTMB3MHFp8jt bp0Nyt3uMJF0r9twOh38K7JKQQRXpjFiFoMR96zTQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudefiedgleekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpehruffvfhfhohfkffgfgggjtgfgse htjeertddtfeejnecuhfhrohhmpeffrghvvgcuvehrohgtkhgvrhcuoeguhhgtsegutghr ohgtkhgvrhdrnhgvtheqnecuggftrfgrthhtvghrnhepkedtleffgfdvieduhfdvhefhje dvvdduieekvdeufeeigfetheefgeefvefftedunecuffhomhgrihhnpegssghifidrnhgv thenucfkphepuddtkedrvddviedrudeivddrieefnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepughhtgesuggtrhhotghkvghrrdhnvght X-ME-Proxy: Received: from [192.168.0.102] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 86846108005F; Thu, 18 Mar 2021 12:59:17 -0400 (EDT) Reply-To: dcrocker@bbiw.net To: John C Klensin , dcrocker@bbiw.net, emailcore@ietf.org References: <6BCAF72097DD9E309ED3271A@PSB> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Thu, 18 Mar 2021 09:59:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; 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 Archived-At: Subject: Re: [Emailcore] Issue #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: Thu, 18 Mar 2021 16:59:27 -0000 On 3/18/2021 7:25 AM, John C Klensin wrote: > My only concern is that there may be a substantive difference > between saying: > > * Out of scope and you are on your own > and > * Servers MAY try to verify if they can find a way to do > so that they consider appropriate There's a big difference. The latter is normative bloat. It is pretending to specify something when, in fact, it isn't specifying anything. Validation isn't precisely defined -- and, yes, it can have different meanings -- and the procedure for it isn't defined. Out of scope means out of scope. Giving people 'permission' to do something out of scope is pretending it isn't out of scope. > The latter, even without references, is a bit closer to > reflecting (or at least hinting at) with supposed current > practice and is closer to the intent of the paragraph we are > replacing. If the goal is to specify current practice, then none of the candidate text does that. It needs to be explicitly within scope and it needs to be concretely specified. (I'm not advocating for doing that. Quite the opposite.) Commenting on the range of practices that are outside the scope of the specification but are nonetheless interesting isn't the job of a protocol specification. Whether it is in scope for a BCP is a separate discussion. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Mar 19 09:57: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 1AF913A1A43 for ; Fri, 19 Mar 2021 09:57:00 -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 vTQgMApJoJKZ for ; Fri, 19 Mar 2021 09:56:58 -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 49AC33A1A42 for ; Fri, 19 Mar 2021 09:56:58 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lNIQj-0003Gw-4R; Fri, 19 Mar 2021 12:56:57 -0400 Date: Fri, 19 Mar 2021 12:56:50 -0400 From: John C Klensin To: dcrocker@bbiw.net, emailcore@ietf.org Message-ID: <034BDCDDB066135DFD35273E@PSB> In-Reply-To: References: <6BCAF72097DD9E309ED3271A@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] Issue #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, 19 Mar 2021 16:57:00 -0000 Dave, --On Thursday, March 18, 2021 09:59 -0700 Dave Crocker wrote: > On 3/18/2021 7:25 AM, John C Klensin wrote: >> My only concern is that there may be a substantive difference >> between saying: >> >> * Out of scope and you are on your own >> and >> * Servers MAY try to verify if they can find a way to do >> so that they consider appropriate > > There's a big difference. If I didn't think there was a difference, I would not have said anything. > The latter is normative bloat. > It is pretending to specify something when, in fact, it isn't > specifying anything. > > Validation isn't precisely defined -- and, yes, it can have > different meanings -- and the procedure for it isn't defined. > Out of scope means out of scope. Giving people 'permission' > to do something out of scope is pretending it isn't out of > scope. See below. >> The latter, even without references, is a bit closer to >> reflecting (or at least hinting at) with supposed current >> practice and is closer to the intent of the paragraph we are >> replacing. > > If the goal is to specify current practice, then none of the > candidate text does that. It needs to be explicitly within > scope and it needs to be concretely specified. (I'm not > advocating for doing that. Quite the opposite.) > > Commenting on the range of practices that are outside the > scope of the specification but are nonetheless interesting > isn't the job of a protocol specification. Whether it is in > scope for a BCP is a separate discussion. Dave, I am a strong supporter of a narrow scope for any modifications to 5321 and 5322 and have been taking that position consistently since discussions of revising the documents to create Internet Standards first started (IIR when Alexey was still AD). I proposed the idea of a supplemental Applicability Statement [1] precisely as a way to provide a place for range of practice (your words) discussions without drawing them into the text of either of the base documents. So please don't lecture me on that subject. However, the boundaries of what is, or is not, out of scope are less exact than your statements above and on other matters would seem to imply. The boundary is, IMO, especially fuzzy when the discussion is not about adding something new but about replacing or removing text that came out of DEUMS and/or YAM --WGs that had more broad participation than this one seems to and that operated at a time when the IETF as a whole seemed much more interested in the details of how core email protocols worked and were defined that it appears (at least to me) to be today. You have your opinions, I have mine (and we might even agree -- my presenting a possibility is not a position in its favor) but the decision as to what is, or is not, out of scope is ultimately the province of the WG Co-chairs and the WG itself, not your beliefs or mine. If you want to ask the Co-chairs for a consensus call on whether some proposal is in scope or not, by all means do so. If you don't like the answer, by all means appeal to the IESG (although I note that the number of times in my memory that the IESG has pushed back on a specification that had WG consensus just because it pushed the boundaries of the WG charter have been few indeed). To me at least, the argument that discussions of this topic are out of scope are particularly dubious given that the charter specifically calls out addressing existing, pre-WG, errata as part of the WG's mission. Again at least from my perspective, demeaning particular suggestions (or their authors) by describing them as "normative bloat" or "pretending to specify something when, in fact, it isn't specifying anything", is not helpful either. Even though I will defend your right to have those opinions and express them, almost any use of MAY in almost any IETF specification could be attacked on similar grounds. But, otherwise, can we try to have discussions about substantive matters, such as different possible ways to address a specific and in-scope topic, rather than engaging in what appears (at least to me) to be an effort to suppress such discussion by claiming that any position with which you disagree is out of scope. thanks, john [1] Whether that should be a BCP instead, or whether there should be an A/S and a BCP are separate issues. However, if you want to focus on scope consistent the charter, I note that it says "Applicability Statement" and indicates that any other documents are out of scope until work on 5321bis, 5322bis, and that A/S are completed. If you believe that a narrow interpretation of the charter is the best way to move the WG forward, then suggesting something about a BCP is inconsistent with that position. From nobody Fri Mar 19 10:05: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 2E9D43A1A74 for ; Fri, 19 Mar 2021 10:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=bYWiUfeb; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=ikm7HT9g Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16SOz7-Nr6Mw for ; Fri, 19 Mar 2021 10:05:36 -0700 (PDT) Received: from mail.winserver.com (ntbbs.winserver.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74F23A1A70 for ; Fri, 19 Mar 2021 10:05:36 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2526; t=1616173533; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=+ClhNMfv7PMKkyiNBq7soSD68YLU VakKFtgjn4Qpmb0=; b=bYWiUfebFnL5+oDjsVxhUCvNcLWj5hU2i/NtAunmV3uf N3361glyEhBieXvq08NSe5XYi0DJzjO7213wfTIJCdX6M8iXdJwqfBTVUJTmXoOR t7j5K51RSKU6ZNlSEmGks2TmmmNDLnyycfV9HxJY2KI5hjCo241Pt6PKdfeZGLE= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Fri, 19 Mar 2021 12:05:33 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 206728954.10953.4028; Fri, 19 Mar 2021 12:05:32 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2526; t=1616173549; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=+ClhNMf v7PMKkyiNBq7soSD68YLUVakKFtgjn4Qpmb0=; b=ikm7HT9g98D7wkKwYvw0u8G yUDs8QnQMAst430V2LmY7u26dG+RHFvv2codvjLDxFeOoQhxkm4KZ2AmNzDhq/PX cFrGOlpF64RtLHKNy6vjs4rgtCZOhr+foXm+tFYS8yZRLMgg3b0Khy+6gblVBWF2 ubWuaFfh8Lb/xfMguX+8= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Fri, 19 Mar 2021 13:05:49 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 890393519.1.68964; Fri, 19 Mar 2021 13:05:48 -0400 Message-ID: <6054D9E1.6070208@isdg.net> Date: Fri, 19 Mar 2021 13:05:37 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: emailcore@ietf.org References: <6BCAF72097DD9E309ED3271A@PSB> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Issue #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, 19 Mar 2021 17:05:39 -0000 On 3/17/2021 8:23 PM, Dave Crocker wrote: > >>> This specification does not deal with the verification >>> of return paths for use in delivery notifications. Server >>> efforts to verify the return path using it is outside the >>> scope of this specification. > > > To clarify and make more crisp: > > > This specification does not deal with the verification of a > return path. Server efforts to verify a return path are outside the > scope of this specification. > > > d/ -1 Here is why: For the record, since RFC2821 and now RFC5321,while described as beyond the scope of the document as to how validation can be done, it does describe the idea for a client/server protocol negotiation considerations for the acceptability of the the return path in section: 3.3: https://tools.ietf.org/html/rfc5321#section-3.3 Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies. (Note: This will save at least X% of return-path validation when X% of the RCPT fails). It has nothing to do with whether it is easily spoofed or not, the return path MUST be valid for the purposes of returns. It can't be any "random" address per se. It should be validated. SPF allows one form of validation. Call Back Verification (CBV), a concept employed since Caller-ID Modem days, has been applied to SMTP. It has been the #1 rejection method for invalid return paths within our wcSMTP package since 2003. Due to CBV overhead, I would never recommend it as a IETF standard. However, empirical data collected daily since 2003 has solidify the high payoff of a CBV operation. It is a local policy option in our package. That said: I would not recommend editing SPF RFC4405 to remove its validation statement. Validation is the main purpose for using the SPF mechanism. Why else would you use it? Again, it has nothing to do whether it is can be spoofed or not, the return path MUST always be a valid address per RFC5321. If not, then, imto, it is easily classifiable as rejectable mail transport identity. Thanks. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Fri Mar 19 10:45: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 E84B03A1B2E for ; Fri, 19 Mar 2021 10:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zj8bZP2Qgf8x for ; Fri, 19 Mar 2021 10:45:44 -0700 (PDT) Received: from wforward4-smtp.messagingengine.com (wforward4-smtp.messagingengine.com [64.147.123.34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD923A1B08 for ; Fri, 19 Mar 2021 10:45:44 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailforward.west.internal (Postfix) with ESMTP id EF99012B0; Fri, 19 Mar 2021 13:45:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 19 Mar 2021 13:45:41 -0400 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 :reply-to:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=vDO7qOgoOKi++tDrOf/+ij9weSXaI jQWk1kCNa5hsiE=; b=ZbNpv7eU5naAphJMmQXsxK3y9ZFPxtDguR19mHOjT80fq mQAQocynZIOCtAxu7dqdkPzDfJs7IYxijWg/Nk/lt+xy8u4uOaDBq/DuHU3eKtk/ vuh67L5rVOQLGP6uTuas+xtYc2hDThjp+rD1V7WhUTt3/Yc4li3VQq9+1v5SM34e fxbFg3z95hRmYvbFrAiXwxO5SBBiI6a4w8iJ6ua6Tdp/+z+7OwOEcFFNnx+Uh2qB 3ilfTHXeIMD6EeGWMJ1peAJC8IrQQIZLf9aRnftdhKZrFWBzpUAYNIBbs2Uk9p46 RGTuEEPHaUnSPNrGjLHHFBZlshITcld3SSY6VUZqA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudefkedguddthecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheprhfuvfhfhfhokffffgggjggtgf esthejredttdefjeenucfhrhhomhepffgrvhgvucevrhhotghkvghruceoughhtgesuggt rhhotghkvghrrdhnvghtqeenucggtffrrghtthgvrhhnpeektdelfffgvdeiudfhvdehhf ejvddvudeikedvueefiefgteehfeegfeevffetudenucffohhmrghinhepsggsihifrdhn vghtnecukfhppedutdekrddvvdeirdduiedvrdeifeenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguhhgtsegutghrohgtkhgvrhdrnhgvth X-ME-Proxy: Received: from [192.168.0.102] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 69F571080057; Fri, 19 Mar 2021 13:45:38 -0400 (EDT) Reply-To: dcrocker@bbiw.net To: John C Klensin , dcrocker@bbiw.net, emailcore@ietf.org References: <6BCAF72097DD9E309ED3271A@PSB> <034BDCDDB066135DFD35273E@PSB> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <51eda78b-ff32-6ac3-cb3d-e84aa5af34e3@dcrocker.net> Date: Fri, 19 Mar 2021 10:45:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <034BDCDDB066135DFD35273E@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Issue #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, 19 Mar 2021 17:45:46 -0000 On 3/19/2021 9:56 AM, John C Klensin wrote: > --On Thursday, March 18, 2021 09:59 -0700 Dave Crocker > wrote: > >> On 3/18/2021 7:25 AM, John C Klensin wrote: >>> My only concern is that there may be a substantive difference >>> between saying: >>> >>> * Out of scope and you are on your own >>> and >>> * Servers MAY try to verify if they can find a way to do >>> so that they consider appropriate >> >> There's a big difference. > > If I didn't think there was a difference, I would not have said > anything. Is it ok that we agreed? Your comment seems to imply a problem. > However, the boundaries of what is, or is not, out of scope are > less exact than your statements above and on other matters would > seem to imply. Not sure what exactly you are claiming isn't exact, on this matter. As I said in my note, if the item is in scope, then it needs substantive specification. If it isn't, then there is no basis for making a normative statement that has no substance. Based on the existing specification -- which provides no substance on this matter -- it is out of scope. (And my own view is that it /should/ be out of scope.) > The boundary is, IMO, especially fuzzy when the > discussion is not about adding something new but about replacing > or removing text that came out of DEUMS and/or YAM --WGs that Fuzzy specifications. An interesting challenge to interoperability. > but the > decision as to what is, or is not, out of scope is ultimately > the province of the WG Co-chairs and the WG itself, not your > beliefs or mine. Your feeling the need to utter something this basic suggests that you think an individual's expressing their views constitutes a threat to the authority of the working group. Why is that? It might be more productive to engage in the substance of the topic, rather than have a lengthy note that invokes history, process, and the like. > Again at least from my perspective, demeaning particular > suggestions (or their authors) by describing them as "normative > bloat" or "pretending to specify something when, in fact, it What language would you find acceptable, John? Let's make sure that we document what can be written without your taking exception. We should probably spend a lot of time developing guidance for the community, about proper language when criticizing technical content. Use of normative language that does not contain any technical specification is not meaningful. It purports to be saying something substantial, but it isn't. > But, otherwise, can we try to have discussions about substantive > matters Excellent suggestions. So, please re-read my note and try to respond to exactly the substance of it. I didn't see it here. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Mar 22 12:19: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 3F9283A0B58 for ; Mon, 22 Mar 2021 12:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 FssdNa5Mobsu for ; Mon, 22 Mar 2021 12:19:47 -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 A9FAD3A0B55 for ; Mon, 22 Mar 2021 12:19:47 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id C1AB2D354D; Mon, 22 Mar 2021 15:19:46 -0400 (EDT) Date: Mon, 22 Mar 2021 15:19:46 -0400 From: Viktor Dukhovni To: emailcore@ietf.org Message-ID: Reply-To: emailcore@ietf.org References: <20201217034150.AA9142AC1E50@ary.qy> <76CF0B1097EB28A5BDE902EE@PSB> <47407afa-6e6a-d0d2-a829-67d68fd0ee90@tana.it> <8a9a363a-68dd-80ed-2ff2-b4d19fb74359@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8a9a363a-68dd-80ed-2ff2-b4d19fb74359@dcrocker.net> Archived-At: Subject: Re: [Emailcore] Ticket #13: G.7.7. Does the 'first digit only' and/or non-listed reply code text need clarification? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 22 Mar 2021 19:19:49 -0000 On Tue, Jan 19, 2021 at 07:31:50AM -0800, Dave Crocker wrote: > Given the normative term in the second sentence it seems odd -- and > possibly problematic -- to have no normative term in the first sentence. > > I assume the intention here is: > > Sender-SMTP MUST first test the whole 3 digit reply code it > receives, as well as any accompanying supplemental codes or information > (see RFC 3463 and RFC 5248). If the full reply code or additional > information is not recognized, Sender-SMTP MUST use the first digit > (severity indication) of a reply code it receives I'm rather late to the party, this was posted Jan 19th, but perhaps better late than never... To whit, I have no idea what the above mandate to 'test' the whole 3 digit reply actually means. If some hypothetical MTA divides the whole 3 digits by 100, and then bases its actions on the quotient, is that conformant? https://github.com/vdukhovni/postfix/blob/master/postfix/src/smtp/smtp_proto.c#L1980 if (resp->code / 100 != 2) { smtp_mesg_fail(state, STR(iter->host), resp, "host %s said: %s (in reply to %s)", session->namaddr, translit(resp->str, "\n", " "), xfer_request[SMTP_STATE_MAIL]); mail_from_rejected = 1; } What exactly is such testing expected to entail? With negative replies the only effect of the extra digits on the above MTA is that 50x syntax errors are used to pessimistically guess that the protocol state machines may be out of sync between client and server, and so the connection should not be reused for additional messages: https://github.com/vdukhovni/postfix/blob/master/postfix/src/smtp/smtp_trouble.c#L189-L208 -- Viktor. From nobody Wed Mar 24 13:38:00 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 ED1F13A0121 for ; Wed, 24 Mar 2021 13:37:57 -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 ys583lE5Hck3 for ; Wed, 24 Mar 2021 13:37:53 -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 A0B093A011D for ; Wed, 24 Mar 2021 13:37:53 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RX1QNI31JK00FYKP@mauve.mrochek.com> for emailcore@ietf.org; Wed, 24 Mar 2021 13:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1616617969; bh=zJd5YFEYzYGIvPWL3liCTUiVr26dAJFunxOnhreoaPI=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Knwuc2vFGmyD0Ro7iLgvxbFvO9CwFA1YhGKQJh5e+s9zmqLSHaXxqHzA+WRF04Y36 uQsVgE0Ow1mwkjaE9/3x3ds3gtKhsUDtny56FB2Ba6jxPbRYrQMNBza5ftO3lMeACG M967TS0v/MP/U4HA07PWYx/2mKT0BPlaXpC5ro7M= 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 <01RX1H5VBEBK0085YQ@mauve.mrochek.com>; Wed, 24 Mar 2021 13:32:47 -0700 (PDT) Cc: emailcore@ietf.org Message-id: <01RX1QNGJ04Q0085YQ@mauve.mrochek.com> Date: Wed, 24 Mar 2021 13:21:06 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 22 Mar 2021 15:19:46 -0400" References: <20201217034150.AA9142AC1E50@ary.qy> <76CF0B1097EB28A5BDE902EE@PSB> <47407afa-6e6a-d0d2-a829-67d68fd0ee90@tana.it> <8a9a363a-68dd-80ed-2ff2-b4d19fb74359@dcrocker.net> To: Viktor Dukhovni Archived-At: Subject: Re: [Emailcore] Ticket #13: G.7.7. Does the 'first digit only' and/or non-listed reply code text need clarification? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 24 Mar 2021 20:37:58 -0000 > On Tue, Jan 19, 2021 at 07:31:50AM -0800, Dave Crocker wrote: > > Given the normative term in the second sentence it seems odd -- and > > possibly problematic -- to have no normative term in the first sentence. > > > > I assume the intention here is: > > > > Sender-SMTP MUST first test the whole 3 digit reply code it > > receives, as well as any accompanying supplemental codes or information > > (see RFC 3463 and RFC 5248). If the full reply code or additional > > information is not recognized, Sender-SMTP MUST use the first digit > > (severity indication) of a reply code it receives > I'm rather late to the party, this was posted Jan 19th, but perhaps > better late than never... To whit, I have no idea what the above > mandate to 'test' the whole 3 digit reply actually means. I don't know what it's supposed to mean, but I do know that there are implementations that take this to heart and then get things badly wrong: At least one widely used code base fails with an error if the code isn't one that's listed in RFC5321. > If some hypothetical MTA divides the whole 3 digits by 100, and then > bases its actions on the quotient, is that conformant? > https://github.com/vdukhovni/postfix/blob/master/postfix/src/smtp/smtp_proto.c#L1980 > if (resp->code / 100 != 2) { > smtp_mesg_fail(state, STR(iter->host), resp, > "host %s said: %s (in reply to %s)", > session->namaddr, > translit(resp->str, "\n", " "), > xfer_request[SMTP_STATE_MAIL]); > mail_from_rejected = 1; > } > What exactly is such testing expected to entail? With negative replies > the only effect of the extra digits on the above MTA is that 50x syntax > errors are used to pessimistically guess that the protocol state > machines may be out of sync between client and server, and so the > connection should not be reused for additional messages: > https://github.com/vdukhovni/postfix/blob/master/postfix/src/smtp/smtp_trouble.c#L189-L208 I think the intent is to check for things like forwarding addresses and act on them if possible. But even if you agree that this sort of thing is worth supporting - and I don't - the fact remains that the emphasis needs to be on first digit processing, not on the rest of the line. The alternate text I would like to see is something like: Sender-SMTP MUST first test the first digit (severity indication) of the reply code it receives, it MUST act in a fashion consistent with that code, and it MUST be able to handle all syntactically valid reply codes. Sender-SMTP MAY examine and use any any accompanying supplemental codes or information to refine any actions it performs (see RFC 3463 and RFC 5248). Regardless of what text we use, we need to get away from the notion that clients absolutely have to do sophisticated processing of the entire line, while recognizing that some clients do need and will perform such processing. Ned From nobody Wed Mar 24 14:28: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 B99563A0BE3 for ; Wed, 24 Mar 2021 14:28:22 -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 NomINGIrl9px for ; Wed, 24 Mar 2021 14:28:18 -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 56F5F3A0BDF for ; Wed, 24 Mar 2021 14:28:18 -0700 (PDT) Received: from [192.168.1.177] (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 3B833D5377 for ; Wed, 24 Mar 2021 17:28:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Viktor Dukhovni In-Reply-To: <01RX1QNGJ04Q0085YQ@mauve.mrochek.com> Date: Wed, 24 Mar 2021 17:28:17 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: emailcore@ietf.org Message-Id: <1FF4D621-9CDF-43E3-94D6-39F2F6219FB3@dukhovni.org> References: <20201217034150.AA9142AC1E50@ary.qy> <76CF0B1097EB28A5BDE902EE@PSB> <47407afa-6e6a-d0d2-a829-67d68fd0ee90@tana.it> <8a9a363a-68dd-80ed-2ff2-b4d19fb74359@dcrocker.net> <01RX1QNGJ04Q0085YQ@mauve.mrochek.com> To: emailcore@ietf.org X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Emailcore] Ticket #13: G.7.7. Does the 'first digit only' and/or non-listed reply code text need clarification? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 24 Mar 2021 21:28:23 -0000 > =0D> =0D> =0D> =0D> =0D> On Mar 24, 2021, at 4:21 PM, Ned Freed = wrote: >=20 > I think the intent is to check for things like forwarding addresses = and > act on them if possible. But even if you agree that this sort of thing > is worth supporting - and I don't - the fact remains that the emphasis > needs to be on first digit processing, not on the rest of the line. >=20 > The alternate text I would like to see is something like: >=20 > Sender-SMTP MUST first test the first digit (severity indication) > of the reply code it receives, it MUST act in a fashion > consistent with that code, and it MUST be able to handle all > syntactically valid reply codes. Sender-SMTP MAY examine and use any > any accompanying supplemental codes or information to refine any > actions it performs (see RFC 3463 and RFC 5248).=0D +1. I think this is actually clear and actionable. > Regardless of what text we use, we need to get away from the notion = that clients > absolutely have to do sophisticated processing of the entire line, = while > recognizing that some clients do need and will perform such = processing. That's fine. They should however know to be prepared to find that the digits after the first are often ad-hoc approximations or even just wildly off-base from the RFC and/or the actual reason why the server is responding with that [245]XX code. --=20 Viktor. From nobody Wed Mar 24 21:27: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 8E8933A0D00 for ; Wed, 24 Mar 2021 21:27: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 zH3Hj24i6vNF for ; Wed, 24 Mar 2021 21:27:29 -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 4FDCB3A0CFC for ; Wed, 24 Mar 2021 21:27:29 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lPHah-000HMK-Ee; Thu, 25 Mar 2021 00:27:27 -0400 Date: Thu, 25 Mar 2021 00:27:21 -0400 From: John C Klensin To: Ned Freed cc: emailcore@ietf.org Message-ID: In-Reply-To: <01RX1QNGJ04Q0085YQ@mauve.mrochek.com> References: <20201217034150.AA9142AC1E50@ary.qy> <76CF0B1097EB28A5BDE902EE@PSB> <47407afa-6e6a-d0d2-a829-67d68fd0ee90@tana.it> <8a9a363a-68dd-80ed-2ff2-b4d19fb74359@dcrocker.net> <01RX1QNGJ04Q0085YQ@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 #13: G.7.7. Does the 'first digit only' and/or non-listed reply code text need clarification? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 25 Mar 2021 04:27:34 -0000 (As individual) --On Wednesday, March 24, 2021 13:21 -0700 Ned Freed wrote: >... > I think the intent is to check for things like forwarding > addresses and act on them if possible. But even if you agree > that this sort of thing is worth supporting - and I don't - > the fact remains that the emphasis needs to be on first digit > processing, not on the rest of the line. > > The alternate text I would like to see is something like: > > Sender-SMTP MUST first test the first digit (severity > indication) of the reply code it receives, it MUST act in a > fashion consistent with that code, and it MUST be able to > handle all syntactically valid reply codes. Sender-SMTP MAY > examine and use any any accompanying supplemental codes or > information to refine any actions it performs (see RFC 3463 > and RFC 5248). I rather like this. > Regardless of what text we use, we need to get away from the > notion that clients absolutely have to do sophisticated > processing of the entire line, while recognizing that some > clients do need and will perform such processing. Agreed. john From nobody Thu Mar 25 03:54: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 0552A3A1D7F for ; Thu, 25 Mar 2021 03:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.238 X-Spam-Level: * X-Spam-Status: No, score=1.238 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, RCVD_IN_SBL_CSS=3.335, 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 (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 AKVzsP1TCkrT for ; Thu, 25 Mar 2021 03:54:42 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 847713A1E06 for ; Thu, 25 Mar 2021 03:53:55 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 40E6E9F149 for ; Thu, 25 Mar 2021 03:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1616669634; bh=T2745O1Q+3zLNnUUsDjGMfqRJi85Op/p27zlrsjxjE0=; h=From:Subject:Date:References:To:In-Reply-To:From; b=WxC28065tM1oAsm7QtKY7v4iqO/ojpDFJ0GYoMaAgmXASV0muD0DHrPdz9bKrIt8Z D01M/hVqwKqo+S0530RX8kgvh/q3urmrGAzM8lnsbBExgxXYArxOiU+xEzPpbJIPDc vcUKbUBDMrCAQCCFCoAIoR0zbvrGm/lM9fOSOCOk= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_BBB12BFE-8725-406F-B154-44878213C09C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 25 Mar 2021 10:53:54 +0000 References: <20201217034150.AA9142AC1E50@ary.qy> <76CF0B1097EB28A5BDE902EE@PSB> <47407afa-6e6a-d0d2-a829-67d68fd0ee90@tana.it> <8a9a363a-68dd-80ed-2ff2-b4d19fb74359@dcrocker.net> <01RX1QNGJ04Q0085YQ@mauve.mrochek.com> <1FF4D621-9CDF-43E3-94D6-39F2F6219FB3@dukhovni.org> To: emailcore@ietf.org In-Reply-To: <1FF4D621-9CDF-43E3-94D6-39F2F6219FB3@dukhovni.org> Message-Id: <6237BD37-05F8-4B22-88D4-195CBDEDA9CD@wordtothewise.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Emailcore] Ticket #13: G.7.7. Does the 'first digit only' and/or non-listed reply code text need clarification? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 25 Mar 2021 10:54:47 -0000 --Apple-Mail=_BBB12BFE-8725-406F-B154-44878213C09C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 24 Mar 2021, at 21:28, Viktor Dukhovni = wrote: >=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Mar 24, 2021, at 4:21 PM, Ned Freed wrote: >>=20 >> I think the intent is to check for things like forwarding addresses = and >> act on them if possible. But even if you agree that this sort of = thing >> is worth supporting - and I don't - the fact remains that the = emphasis >> needs to be on first digit processing, not on the rest of the line. >>=20 >> The alternate text I would like to see is something like: >>=20 >> Sender-SMTP MUST first test the first digit (severity indication) >> of the reply code it receives, it MUST act in a fashion >> consistent with that code, and it MUST be able to handle all >> syntactically valid reply codes. Sender-SMTP MAY examine and use any >> any accompanying supplemental codes or information to refine any >> actions it performs (see RFC 3463 and RFC 5248). >=20 > +1. I think this is actually clear and actionable. I like this language, too.=20 >> Regardless of what text we use, we need to get away from the notion = that clients >> absolutely have to do sophisticated processing of the entire line, = while >> recognizing that some clients do need and will perform such = processing. >=20 > That's fine. They should however know to be prepared to find that > the digits after the first are often ad-hoc approximations or even > just wildly off-base from the RFC and/or the actual reason why the > server is responding with that [245]XX code. Yup. eg: 452 this message will never succeed.=20 laura=20 --=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=_BBB12BFE-8725-406F-B154-44878213C09C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 24 Mar 2021, at 21:28, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:






On Mar 24, 2021, = at 4:21 PM, Ned Freed <ned.freed@mrochek.com> wrote:

I think the intent is to check for things like forwarding = addresses and
act on them if possible. But even if you = agree that this sort of thing
is worth supporting - and I = don't - the fact remains that the emphasis
needs to be on = first digit processing, not on the rest of the line.

The alternate text I would like to see is something like:

Sender-SMTP MUST first test the first digit = (severity indication)
of the reply code it receives, it = MUST act in a fashion
consistent with that code, and it = MUST be able to handle all
syntactically valid reply = codes. Sender-SMTP MAY examine and use any
any = accompanying supplemental codes or information to refine any
actions it performs (see RFC 3463 and  RFC 5248).

+1.  I think this is = actually clear and actionable.

I like = this language, too. 

Regardless of what text we use, we need to get = away from the notion that clients
absolutely have to do = sophisticated processing of the entire line, while
recognizing that some clients do need and will perform such = processing.

That's fine. =  They should however know to be prepared to find that
the digits after the first are often ad-hoc approximations or = even
just wildly off-base from the RFC and/or the actual = reason why the
server is responding with that [245]XX = code.

Yup. eg: 452 = this message will never succeed. 

laura 


-- 
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=_BBB12BFE-8725-406F-B154-44878213C09C-- From nobody Thu Mar 25 05:19: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 EC3763A1FF3 for ; Thu, 25 Mar 2021 05:19: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, 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 l1wSoOJCeG3V for ; Thu, 25 Mar 2021 05:19:43 -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 A70B33A1FDB for ; Thu, 25 Mar 2021 05:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1616674777; bh=k0xyfpDOWeJvg0DlKibYLFrE7glwXqNR80pLnUGN26o=; l=1162; h=To:References:From:Date:In-Reply-To; b=AiCgXuo5G9Z+4TY1QdoOq/80/YYip9LIFUwJngFxe3L4TFC2X2lGPidXAxZOsOeiB sbcfg+m3+0PTbSKPsBUHhxTSzHEbnev+Gg7CFFrKsXxoeDcl/X3TxHSXZ+4A/VQpvO AZWPuwjRwr8tR9iU6iqKm6+QFG2Couh5XGIu9E9ffrJ6ncKDM78y4/WBDoMtx 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.00000000605C7FD9.000079C0; Thu, 25 Mar 2021 13:19:37 +0100 To: emailcore@ietf.org References: <20201217034150.AA9142AC1E50@ary.qy> <76CF0B1097EB28A5BDE902EE@PSB> <47407afa-6e6a-d0d2-a829-67d68fd0ee90@tana.it> <8a9a363a-68dd-80ed-2ff2-b4d19fb74359@dcrocker.net> <01RX1QNGJ04Q0085YQ@mauve.mrochek.com> From: Alessandro Vesely Message-ID: Date: Thu, 25 Mar 2021 13:19:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.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 #13: G.7.7. Does the 'first digit only' and/or non-listed reply code text need clarification? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 25 Mar 2021 12:19:48 -0000 On Thu 25/Mar/2021 05:27:21 +0100 John C Klensin (As individual) wrote: > --On Wednesday, March 24, 2021 13:21 -0700 Ned Freed wrote: > >> >> The alternate text I would like to see is something like: >> >> Sender-SMTP MUST first test the first digit (severity >> indication) of the reply code it receives, it MUST act in a >> fashion consistent with that code, and it MUST be able to >> handle all syntactically valid reply codes. Sender-SMTP MAY >> examine and use any any accompanying supplemental codes or >> information to refine any actions it performs (see RFC 3463 >> and RFC 5248). > > I rather like this. strncmp(response, "421", 3)==0 has to come before *response=='4'. According to previous threads, *response=='4' allows a client to try RCPT commands for another 100-N recipients. strncmp(response, "421", 3)==0 suggests to quit the transaction sooner. BTW, Section 3.8 allows 421 at any time a server must forcibly shut down. However, Section 4.3.2 only contemplates: RCPT S: 250, 251 (but see Section 3.4 for discussion of 251 and 551) E: 550, 551, 552, 553, 450, 451, 452, 503, 455, 555 Best Ale -- From nobody Thu Mar 25 07:41: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 8306D3A2451 for ; Thu, 25 Mar 2021 07:41:26 -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 (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 5JkOxX9n8uYP for ; Thu, 25 Mar 2021 07:41:21 -0700 (PDT) Received: from bumble.birch.relay.mailchannels.net (bumble.birch.relay.mailchannels.net [23.83.209.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 3A2E53A244D for ; Thu, 25 Mar 2021 07:41:20 -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 0264D1E27CD; Thu, 25 Mar 2021 14:41:19 +0000 (UTC) Received: from nl-srv-smtpout4.hostinger.io (100-96-16-41.trex.outbound.svc.cluster.local [100.96.16.41]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 0585C1E2AC6; Thu, 25 Mar 2021 14:41:16 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout4.hostinger.io ([UNAVAILABLE]. [145.14.159.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.16.41 (trex/6.1.1); Thu, 25 Mar 2021 14:41:18 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Soft-Wide-Eyed: 27c490d635034307_1616683278535_643697264 X-MC-Loop-Signature: 1616683278535:626497879 X-MC-Ingress-Time: 1616683278535 Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout4.hostinger.io (smtp.hostinger.com) with ESMTPSA id CC84631CE8A3; Thu, 25 Mar 2021 14:41:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1616683275; bh=YwhTo24VkdSFqFfaY6BDOOX5X+u5lUI6FDdPzUgCiKw=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=GrSs/mAO4v4lPR8MSPWntnX+Jf23ZYnjqelV+ueV1NwAYpz+cEUmJhdd9qo+f3wB+ KSpF8DI8YeJHkHm2WZwdCzTrbEN6aeeG0MzDINYAbdJbb/BveISIll9DLAcxpvMopj +9oV6bz9mGY4aPji5wgftDMYQ7wgsKUZmfuzZah9DBTeNMkDb52MqPB7/tRZp1aJSR 3j02hBglTMp/6NtbvT4HfZjHLtiAh0BLt7oJTMIwlMQphLZUoDu6TNtrNRcQqJ1XKM EfnGCetk3moHGxrbpOFy4Rn2KyAhSG1HanLfEFTzIqZEPwcf719h2TcEd/44Yk/HSW Cb+okdV9q4SGA== Reply-To: dcrocker@bbiw.net To: John C Klensin , emailcore@ietf.org References: <6BCAF72097DD9E309ED3271A@PSB> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <1bfe797a-b0b6-0ed7-c688-c93a508ac584@dcrocker.net> Date: Thu, 25 Mar 2021 07:41:01 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; 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 Archived-At: Subject: Re: [Emailcore] Issue #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: Thu, 25 Mar 2021 14:41:27 -0000 On 3/18/2021 7:25 AM, John C Klensin wrote: >> To clarify and make more crisp: >> >> This specification does not deal with the verification >> of a return path. Server efforts to verify a return path are >> outside the scope of this specification. > > Dave, this is at least as reasonable as any of the suggestions I > made in the note pointing out the problem with your earlier > text. Unless someone objects or has a yet-better suggestion, > I'll incorporate it into the working version of 5321bis. John, Given the exchange we had after in response to the above, it would be helpful for you to confirm that the draft will incorporate the above change, as you originally indicated. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Mar 25 09: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 B2B343A26B9 for ; Thu, 25 Mar 2021 09:19:39 -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 Tdl_h8XXqpx3 for ; Thu, 25 Mar 2021 09:19:35 -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 437D03A26BC for ; Thu, 25 Mar 2021 09:19:35 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RX2VWLYXE800GF2Z@mauve.mrochek.com> for emailcore@ietf.org; Thu, 25 Mar 2021 09:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1616688871; bh=vgMTXlJ2lXzX4WEBLshCQSMzbyhOC5E+Y5mTyRrnPSg=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Dt1jUEHfaWMn34sOgQGKE5amBDze/iTOhxB32OBd0bRHf5+TUlIWUASMhgaUUM1Gk Mu9oc+PMZ/b5iLjX0HxnG6Mdi6CwxnYGXFesgsPIiLEXfdghvAa8N2gQzvv3obYt8g CwqH/WzAiuLDasXZAbYygslHET9dAq+IAPYewFkU= 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 <01RX1H5VBEBK0085YQ@mauve.mrochek.com>; Thu, 25 Mar 2021 09:14:29 -0700 (PDT) Cc: emailcore@ietf.org Message-id: <01RX2VWKSR5M0085YQ@mauve.mrochek.com> Date: Thu, 25 Mar 2021 08:09:58 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 25 Mar 2021 13:19:36 +0100" References: <20201217034150.AA9142AC1E50@ary.qy> <76CF0B1097EB28A5BDE902EE@PSB> <47407afa-6e6a-d0d2-a829-67d68fd0ee90@tana.it> <8a9a363a-68dd-80ed-2ff2-b4d19fb74359@dcrocker.net> <01RX1QNGJ04Q0085YQ@mauve.mrochek.com> To: Alessandro Vesely Archived-At: Subject: Re: [Emailcore] Ticket #13: G.7.7. Does the 'first digit only' and/or non-listed reply code text need clarification? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 25 Mar 2021 16:19:40 -0000 > On Thu 25/Mar/2021 05:27:21 +0100 John C Klensin (As individual) wrote: > > --On Wednesday, March 24, 2021 13:21 -0700 Ned Freed wrote: > > > >> > >> The alternate text I would like to see is something like: > >> > >> Sender-SMTP MUST first test the first digit (severity > >> indication) of the reply code it receives, it MUST act in a > >> fashion consistent with that code, and it MUST be able to > >> handle all syntactically valid reply codes. Sender-SMTP MAY > >> examine and use any any accompanying supplemental codes or > >> information to refine any actions it performs (see RFC 3463 > >> and RFC 5248). > > > > I rather like this. > strncmp(response, "421", 3)==0 has to come before *response=='4'. In fact it's exactly the opposite: The client needs the ability to treat 421 as a generic temporary error. Without that ability pipelining is effectively forbidden by the standard, because now you are saying that you have to check every command response as it arrives, so you can tell whether or not it's OK to proceed. And in the case of 421, this is completely unnecessary. If a 421 does arrive, and if, as the standard requires, the connection is then closed, it doesn't matter whether the client has sent a gazillion more RCPT TOs, DATA, BDAT, another 10 transactions, whatever. All of that data is discarded, in effect with additional 421 codes. At this point - and only at this point - does it make sense for the client to make decisions about what it's going to do on subsequent attempts to transfer the message. I for one don't believe that you can safely conclude that the reason for a 421 response to a RCPT TO is that you sent too many recipients, but if a client wants to implement that strategy, that's its choice. Of course it's possible that the 421 isn't followed by a disconnect. In this case the server is operating outside what the standard specifies. In this case the meaning of 421 is effectively unknown, and it's even less clear what the client should do - other than treat it as a temporary error. 451 is actually the more interesting case - it's the code that should be used when a recipient limit has been hit. But once again the freedom to treat it as a generic temporary error during the current session is needed in order to allow pipelining. And since 452 does have other meansing, it's not at all clear to me that the right thing for a client to do is assume subsequent RCPT TOs will be rejected with the same error. Why not send them and find out? But if you want to make that assumption, that's also fine. Nothing in the suggested text is inconsistent with using a 451 as an indication to stop sending more RCPT TOs. > According to previous threads, *response=='4' allows a client to try RCPT > commands for another 100-N recipients. Absolutely, and that has to include 421 and 451 response. See above. > strncmp(response, "421", 3)==0 suggests > to quit the transaction sooner. I disagree that's what 421 suggests. 451 might suggest that, but it most certainly doesn't require it. What is required is that 4YZ be treated as a temporary error. Nothing more, nothing less. The nasty case is when you start getting 4YZ errors in response to RCPT TOs and then get a 4YZ error in response to DATA/BDAT. When this happens it makes some sense for the client to conclude that a recipient limit was hit and to limit the number of recipients it tries next time to the number of RCPT TOs that were accepted prior to the first 4YZ. But this is a case of a client dealing with bad server behavior, and for that reason it is one where if I implemented this I would base the choice of how to proceed on the first digit only. > BTW, Section 3.8 allows 421 at any time a server must forcibly shut down. > However, Section 4.3.2 only contemplates: > RCPT > S: 250, 251 (but see Section 3.4 for discussion of 251 and 551) > E: 550, 551, 552, 553, 450, 451, 452, 503, 455, 555 421 isn't listed as a repsonse to anything in that section. There's no point to doing so since it can be sent at any time and therefore valid in any state where a command response is expected. Ned From nobody Thu Mar 25 10:36: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 991803A2868 for ; Thu, 25 Mar 2021 10:36:42 -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, NICE_REPLY_A=-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 (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 wiRtMQmKDuiM for ; Thu, 25 Mar 2021 10:36: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 9B3E33A2866 for ; Thu, 25 Mar 2021 10:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1616693793; bh=tBcSr0b+AAM5qg0T90Mnsz4wnYooBCpX+2ibtg+aLv4=; l=6157; h=To:References:From:Date:In-Reply-To; b=CEIiY1lMGwKVi71LjQQ/+6iylN36TfWYTP7ud1Ho+LXQCQJ7Bwmb0yyMU74BRHVqP pWqm/Kr5s82VsVZ6AnTo3GUMWDa9ZUoaP/yYXtQ7yqIIlYx1XEGCXOv0RfZhrwuTLf k7IcqRKhRaBZdLysz0WJMZ2pVb4oeQ01bwUdN6X/5FusvDScyKqGYIXUaSiC8 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.00000000605CCA21.00001DD8; Thu, 25 Mar 2021 18:36:33 +0100 To: Ned Freed , emailcore@ietf.org References: <20201217034150.AA9142AC1E50@ary.qy> <76CF0B1097EB28A5BDE902EE@PSB> <47407afa-6e6a-d0d2-a829-67d68fd0ee90@tana.it> <8a9a363a-68dd-80ed-2ff2-b4d19fb74359@dcrocker.net> <01RX1QNGJ04Q0085YQ@mauve.mrochek.com> <01RX2VWKSR5M0085YQ@mauve.mrochek.com> From: Alessandro Vesely Message-ID: Date: Thu, 25 Mar 2021 18:36:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <01RX2VWKSR5M0085YQ@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 #13: G.7.7. Does the 'first digit only' and/or non-listed reply code text need clarification? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 25 Mar 2021 17:36:43 -0000 On Thu 25/Mar/2021 16:09:58 +0100 Ned Freed wrote: > On Thu 25/Mar/2021 13:19:36 +0100 Alessandro Vesely wrote: >> On Thu 25/Mar/2021 05:27:21 +0100 John C Klensin (As individual) wrote: >>> --On Wednesday, March 24, 2021 13:21 -0700 Ned Freed wrote: >>> >>>> >>>> The alternate text I would like to see is something like: >>>> >>>>   Sender-SMTP MUST first test the first digit (severity >>>> indication)   of the reply code it receives, it MUST act in a >>>> fashion   consistent with that code, and it MUST be able to >>>> handle all   syntactically valid reply codes. Sender-SMTP MAY >>>> examine and use any   any accompanying supplemental codes or >>>> information to refine any   actions it performs (see RFC 3463 >>>> and  RFC 5248). >>> >>> I rather like this. >> >> strncmp(response, "421", 3)==0 has to come before *response=='4'. > > In fact it's exactly the opposite: The client needs the ability to treat 421 as > a generic temporary error. Without that ability pipelining is effectively > forbidden by the standard, because now you are saying that you have to check > every command response as it arrives, so you can tell whether or not it's OK to > proceed. Pipelining may have its own reasons, rules, and methods. In fact, it allows clients to send commands before looking at the responses. Whether a client doesn't look at the first byte of the response, rather than not looking at the whole code, sounds quite irrelevant. > And in the case of 421, this is completely unnecessary. If a 421 does arrive, > and if, as the standard requires, the connection is then closed, it doesn't > matter whether the client has sent a gazillion more RCPT TOs, DATA, BDAT, > another 10 transactions, whatever. All of that data is discarded, in effect with > additional 421 codes. The server can tear down the connection before the client acknowledges a 421. Isn't it still preferable to issue a QUIT? Perhaps, a non-pipelining client can: if (*response=='4') { // react to special codes if (strncmp(response, "421", 3)==0) do_quit(); // react to generic temporary errors // ... } > At this point - and only at this point - does it make sense for the client to > make decisions about what it's going to do on subsequent attempts to transfer > the message. I for one don't believe that you can safely conclude that the > reason for a 421 response to a RCPT TO is that you sent too many recipients, but > if a client wants to implement that strategy, that's its choice. A client can also send unrecognizable commands. I'd call it a TCP client, but hardly an SMTP client. > Of course it's possible that the 421 isn't followed by a disconnect. In > this case the server is operating outside what the standard specifies. > In this case the meaning of 421 is effectively unknown, and it's even > less clear what the client should do - other than treat it as a temporary > error. A dialog between the deaf and the dumb? > 451 is actually the more interesting case - it's the code that should be > used when a recipient limit has been hit. But once again the freedom to treat it > as a generic temporary error during the current session is needed in order to > allow pipelining. And since 452 does have other meansing, it's not at all > clear to me that the right thing for a client to do is assume subsequent > RCPT TOs will be rejected with the same error. Why not send them and > find out? > > But if you want to make that assumption, that's also fine. Nothing in the > suggested text is inconsistent with using a 451 as an indication to stop sending > more RCPT TOs. > >> According to previous threads, *response=='4' allows a client to try RCPT >> commands for another 100-N recipients. > > Absolutely, and that has to include 421 and 451 response. See above. What is doing a non-pipelining client that continues to send RCPT commands after getting a 421? Is it testing the server behavior? Is it deaf? >>  strncmp(response, "421", 3)==0 suggests to quit the transaction sooner. > > I disagree that's what 421 suggests. Do you? > 451 might suggest that, but it most certainly doesn't require it. Surely you must be joking. 451 tells me the last RCPT I sent must be retried later. If there are more recipients, I should still try each one of them. Replying QUIT because of a 451 is nonsensical, especially if some previous recipients were accepted. > What is required is that 4YZ be treated as a temporary error. Nothing more, > nothing less. For requirements, maybe. (Although the current wording still says to consider the whole code first.) Yet, a client MAY be smarter than minimal requirements. > The nasty case is when you start getting 4YZ errors in response to RCPT TOs and > then get a 4YZ error in response to DATA/BDAT. When this happens it makes some > sense for the client to conclude that a recipient limit was hit and to limit the > number of recipients it tries next time to the number of RCPT TOs that were > accepted prior to the first 4YZ. > > But this is a case of a client dealing with bad server behavior, and for that > reason it is one where if I implemented this I would base the choice of how to > proceed on the first digit only. That depends on the YZ. If the last code was a 421 due to an unanticipated event, or a 450 due to policy reasons, such as waiting for a verdict about something found in the message content, inferring a recipient limit is excessively smart. >> BTW, Section 3.8 allows 421 at any time a server must forcibly shut down. >> However, Section 4.3.2 only contemplates: >> >>        RCPT >> >>           S: 250, 251 (but see Section 3.4 for discussion of 251 and 551) >>           E: 550, 551, 552, 553, 450, 451, 452, 503, 455, 555 > > 421 isn't listed as a response to anything in that section. There's no > point to doing so since it can be sent at any time and therefore valid > in any state where a command response is expected. Ack, thank you. Best Ale -- From nobody Thu Mar 25 12:31: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 B34863A2AD6 for ; Thu, 25 Mar 2021 12:31:26 -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=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 opoz8BlQKq7Q for ; Thu, 25 Mar 2021 12:31:21 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1AA83A2ACE for ; Thu, 25 Mar 2021 12:31:21 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RX32MCV90W00CW9K@mauve.mrochek.com> for emailcore@ietf.org; Thu, 25 Mar 2021 12:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1616700377; bh=z565OPLzl5OhHCh2p6T05ijzbBPRKR+ymDTpIHk+z8Q=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Y5Aci5gwwbRVqnAEti1MIh3CZ/a+LfNE3qDF6SviN2dHMhOBOjsIkdPFqme7WvwL0 8NyJXJv5p+vJOQjxxgf8wl/EeTN1U/AdVjIUTM1/UW8yOJn/hYiBvzoRlCbyWpI47Z bxdRYpC7uQVL/PKZD7aA0aqGFOfq++DwI4c77DR0= 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 <01RX1H5VBEBK0085YQ@mauve.mrochek.com>; Thu, 25 Mar 2021 12:26:14 -0700 (PDT) Cc: Ned Freed , emailcore@ietf.org Message-id: <01RX32MAICRC0085YQ@mauve.mrochek.com> Date: Thu, 25 Mar 2021 12:16:14 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 25 Mar 2021 18:36:33 +0100" References: <20201217034150.AA9142AC1E50@ary.qy> <76CF0B1097EB28A5BDE902EE@PSB> <47407afa-6e6a-d0d2-a829-67d68fd0ee90@tana.it> <8a9a363a-68dd-80ed-2ff2-b4d19fb74359@dcrocker.net> <01RX1QNGJ04Q0085YQ@mauve.mrochek.com> <01RX2VWKSR5M0085YQ@mauve.mrochek.com> To: Alessandro Vesely Archived-At: Subject: Re: [Emailcore] Ticket #13: G.7.7. Does the 'first digit only' and/or non-listed reply code text need clarification? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 25 Mar 2021 19:31:27 -0000 I'm afraid none of this makes the slightest bit of sense to me, so I'm done trying to respond to the overall argument. I will answer one question: > The server can tear down the connection before the client acknowledges a 421. > Isn't it still preferable to issue a QUIT? The answer is it's irrelevant what the client does at this point - the service is supposed to be closing the connection, so whatever the client sends will be dropped on the floor, regardless of whether it's a QUIT or some pipelined command. And if the server doesn't do that, I will reiterate the point others have repeatedly made: When a server misbehaves in a rather obvious way, trusting that the reply codes it sends are sensible when it's other behavior is not makes very little sense. Ned > On Thu 25/Mar/2021 16:09:58 +0100 Ned Freed wrote: > > On Thu 25/Mar/2021 13:19:36 +0100 Alessandro Vesely wrote: > >> On Thu 25/Mar/2021 05:27:21 +0100 John C Klensin (As individual) wrote: > >>> --On Wednesday, March 24, 2021 13:21 -0700 Ned Freed wrote: > >>> > >>>> > >>>> The alternate text I would like to see is something like: > >>>> > >>>>   Sender-SMTP MUST first test the first digit (severity > >>>> indication)   of the reply code it receives, it MUST act in a > >>>> fashion   consistent with that code, and it MUST be able to > >>>> handle all   syntactically valid reply codes. Sender-SMTP MAY > >>>> examine and use any   any accompanying supplemental codes or > >>>> information to refine any   actions it performs (see RFC 3463 > >>>> and  RFC 5248). > >>> > >>> I rather like this. > >> > >> strncmp(response, "421", 3)==0 has to come before *response=='4'. > > > > In fact it's exactly the opposite: The client needs the ability to treat 421 as > > a generic temporary error. Without that ability pipelining is effectively > > forbidden by the standard, because now you are saying that you have to check > > every command response as it arrives, so you can tell whether or not it's OK to > > proceed. > Pipelining may have its own reasons, rules, and methods. In fact, it allows > clients to send commands before looking at the responses. Whether a client > doesn't look at the first byte of the response, rather than not looking at the > whole code, sounds quite irrelevant. > > And in the case of 421, this is completely unnecessary. If a 421 does arrive, > > and if, as the standard requires, the connection is then closed, it doesn't > > matter whether the client has sent a gazillion more RCPT TOs, DATA, BDAT, > > another 10 transactions, whatever. All of that data is discarded, in effect with > > additional 421 codes. > The server can tear down the connection before the client acknowledges a 421. > Isn't it still preferable to issue a QUIT? > Perhaps, a non-pipelining client can: > if (*response=='4') > { > // react to special codes > if (strncmp(response, "421", 3)==0) > do_quit(); > // react to generic temporary errors > // ... > } > > At this point - and only at this point - does it make sense for the client to > > make decisions about what it's going to do on subsequent attempts to transfer > > the message. I for one don't believe that you can safely conclude that the > > reason for a 421 response to a RCPT TO is that you sent too many recipients, but > > if a client wants to implement that strategy, that's its choice. > A client can also send unrecognizable commands. I'd call it a TCP client, but > hardly an SMTP client. > > Of course it's possible that the 421 isn't followed by a disconnect. In > > this case the server is operating outside what the standard specifies. > > In this case the meaning of 421 is effectively unknown, and it's even > > less clear what the client should do - other than treat it as a temporary > > error. > A dialog between the deaf and the dumb? > > 451 is actually the more interesting case - it's the code that should be > > used when a recipient limit has been hit. But once again the freedom to treat it > > as a generic temporary error during the current session is needed in order to > > allow pipelining. And since 452 does have other meansing, it's not at all > > clear to me that the right thing for a client to do is assume subsequent > > RCPT TOs will be rejected with the same error. Why not send them and > > find out? > > > > But if you want to make that assumption, that's also fine. Nothing in the > > suggested text is inconsistent with using a 451 as an indication to stop sending > > more RCPT TOs. > > > >> According to previous threads, *response=='4' allows a client to try RCPT > >> commands for another 100-N recipients. > > > > Absolutely, and that has to include 421 and 451 response. See above. > What is doing a non-pipelining client that continues to send RCPT commands > after getting a 421? Is it testing the server behavior? Is it deaf? > >>  strncmp(response, "421", 3)==0 suggests to quit the transaction sooner. > > > > I disagree that's what 421 suggests. > Do you? > > 451 might suggest that, but it most certainly doesn't require it. > Surely you must be joking. 451 tells me the last RCPT I sent must be retried > later. If there are more recipients, I should still try each one of them. > Replying QUIT because of a 451 is nonsensical, especially if some previous > recipients were accepted. > > What is required is that 4YZ be treated as a temporary error. Nothing more, > > nothing less. > For requirements, maybe. (Although the current wording still says to consider > the whole code first.) Yet, a client MAY be smarter than minimal requirements. > > The nasty case is when you start getting 4YZ errors in response to RCPT TOs and > > then get a 4YZ error in response to DATA/BDAT. When this happens it makes some > > sense for the client to conclude that a recipient limit was hit and to limit the > > number of recipients it tries next time to the number of RCPT TOs that were > > accepted prior to the first 4YZ. > > > > But this is a case of a client dealing with bad server behavior, and for that > > reason it is one where if I implemented this I would base the choice of how to > > proceed on the first digit only. > That depends on the YZ. If the last code was a 421 due to an unanticipated > event, or a 450 due to policy reasons, such as waiting for a verdict about > something found in the message content, inferring a recipient limit is > excessively smart. From nobody Thu Mar 25 15:22: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 DC68E3A0C58 for ; Thu, 25 Mar 2021 15:22:14 -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 3kjG7Idcd6VL for ; Thu, 25 Mar 2021 15:22:10 -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 7CC593A0C56 for ; Thu, 25 Mar 2021 15:22:10 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lPYMi-000NZR-NX; Thu, 25 Mar 2021 18:22:08 -0400 Date: Thu, 25 Mar 2021 18:22:02 -0400 From: John C Klensin To: dcrocker@bbiw.net, emailcore@ietf.org Message-ID: <571E9728D2497ED8F397A32A@PSB> In-Reply-To: <1bfe797a-b0b6-0ed7-c688-c93a508ac584@dcrocker.net> References: <6BCAF72097DD9E309ED3271A@PSB> <1bfe797a-b0b6-0ed7-c688-c93a508ac584@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] Issue #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: Thu, 25 Mar 2021 22:22:15 -0000 --On Thursday, March 25, 2021 07:41 -0700 Dave Crocker wrote: > On 3/18/2021 7:25 AM, John C Klensin wrote: >>> To clarify and make more crisp: >>> >>> This specification does not deal with the >>> verification of a return path. Server efforts to >>> verify a return path are outside the scope of this >>> specification. > > >> Dave, this is at least as reasonable as any of the >> suggestions I made in the note pointing out the problem with >> your earlier text. Unless someone objects or has a >> yet-better suggestion, I'll incorporate it into the working >> version of 5321bis. > > > John, > > Given the exchange we had after in response to the above, it > would be helpful for you to confirm that the draft will > incorporate the above change, as you originally indicated. Dave, TL;DR summary: Your inputs are being treated no differently than anyone else's. ------------- Explanation: As I belief I have said previously, I am very concerned about the possibility of making changes to 5321 that do not have fairly clear community consensus both about the substance of the change and about the risk of inadvertent side effects, including the risk of invalidating existing conforming implementations. That position builds on decisions made in DRUMs, in YAM, and when this WG was chartered to avoid doing a complete rewrite. On the one hand, such a rewrite would undoubtedly improve the readability of the document. On the other, the risks of getting something wrong are considerable and the decision that has been made three times now that the risks outweigh the benefits. In part because I, like many others on this list, have very strong opinions on many of the issues, I have adopted a very conservation approach to making document changes or edits. I will make changes based on editor's discretion only to make editorial improvements (e.g., to improve bad sentences), to add cross references, and to maintain the tracking sections (the Note at the beginning and Appendices G and H). Beyond that, I will made changes I expect to make it through into the IETF Last Call version iff the WG Chairs declare (at least rough) consensus on particular text and either close the relevant ticket(s) or indicate intent to do so as soon as the changes are made. Other changes will either be inserted into the text but clearly identified as proposed changes or will be held in the source version of the working drafts until a consensus call is made (with that choice entirely at my discretion until I get instructions from the WG Chairs). As above, your proposed change has been reflected in the working draft version. And, in case you are wondering, your name has been added to the list of acknowledgments associated with this version. Unless I am instructed to the contrary by the WG or its leadership, it remain there no matter what the WG decided to do with your text because you clearly contributed to the discussion that will lead to however the draft works out. And I would expect to resist such instructions if I received them. best, john From nobody Thu Mar 25 17:08: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 E9C473A10D7 for ; Thu, 25 Mar 2021 17:08:25 -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 iReNugqyyyOs for ; Thu, 25 Mar 2021 17:08:20 -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 BDDBA3A10D3 for ; Thu, 25 Mar 2021 17:08:20 -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 9E603101B60; Fri, 26 Mar 2021 00:08:19 +0000 (UTC) Received: from nl-srv-smtpout4.hostinger.io (100-96-27-144.trex.outbound.svc.cluster.local [100.96.27.144]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id B3202101AC3; Fri, 26 Mar 2021 00:08:17 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout4.hostinger.io ([UNAVAILABLE]. [145.14.159.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.27.144 (trex/6.1.1); Fri, 26 Mar 2021 00:08:19 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Bitter-Drop: 0611d1c15c6e23c8_1616717299401_3499260898 X-MC-Loop-Signature: 1616717299401:3229250459 X-MC-Ingress-Time: 1616717299401 Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout4.hostinger.io (smtp.hostinger.com) with ESMTPSA id 7F8BA3130418; Fri, 26 Mar 2021 00:08:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1616717296; bh=3oF1fir5RnWY8bQqmPsunJQxtbly3d0jGk4KTmaQaF8=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=BhpINlh/6FPCs/H0Nzd6D++mKy4Ftlk4JFjGa8osBoVaA0sUI4rBPpBehx9Ow2hC+ nTHMF/f31eHA0i1zZMqSqTMqGWflMY7M88BTepGIk2v4+B8Vhx/gl9bc5Po6AWsGYF j/CyBGnzBKIooTkzHkVAvrtWXgoZh+b+E9TBwON7PoUUkKumDY8p5fu6crFanzdFG+ H3uMBFycIJOb5+yPbWLswpPpKwb7ewn9Sbe8QMLirsmVU7fZ8YP6UTMZXmOdbUbH1C ricsiVhE6mEKjOMHoz+7FbpqBAm0dI8H6P1jXzUlUmFYBX1IwEE4Kw/HcY9j/135cb YPRVA2s1SWoZA== Reply-To: dcrocker@bbiw.net To: John C Klensin , emailcore@ietf.org References: <6BCAF72097DD9E309ED3271A@PSB> <1bfe797a-b0b6-0ed7-c688-c93a508ac584@dcrocker.net> <571E9728D2497ED8F397A32A@PSB> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Thu, 25 Mar 2021 17:08:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <571E9728D2497ED8F397A32A@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Issue #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, 26 Mar 2021 00:08:26 -0000 On 3/25/2021 3:22 PM, John C Klensin wrote: > As above, your proposed change has been reflected in the working > draft version. Dandy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Mar 25 21:14: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 729DA3A0D2A for ; Thu, 25 Mar 2021 21:14: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 S9l9X4f6v1cD for ; Thu, 25 Mar 2021 21:14: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 32ACF3A0D29 for ; Thu, 25 Mar 2021 21:14:19 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lPdrV-000Ogx-CJ; Fri, 26 Mar 2021 00:14:17 -0400 Date: Fri, 26 Mar 2021 00:14:11 -0400 From: John C Klensin To: hsantos@isdg.net cc: emailcore@ietf.org Message-ID: In-Reply-To: <6054D9E1.6070208@isdg.net> References: <6BCAF72097DD9E309ED3271A@PSB> <6054D9E1.6070208@isdg.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] Issue #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, 26 Mar 2021 04:14:24 -0000 Hector, --On Friday, March 19, 2021 13:05 -0400 Hector Santos wrote: > On 3/17/2021 8:23 PM, Dave Crocker wrote: >> >>>> This specification does not deal with the >>>> verification of return paths for use in delivery >>>> notifications. Server efforts to verify the return path >>>> using it is outside the scope of this specification. >> >> >> To clarify and make more crisp: >> >> >> This specification does not deal with the verification >> of a return path. Server efforts to verify a return >> path are outside the scope of this specification. >... > -1 > > Here is why: > > For the record, since RFC2821 and now RFC5321,while described > as beyond the scope of the document as to how validation can > be done, it does describe the idea for a client/server > protocol negotiation considerations for the acceptability of > the the return path in section: 3.3: > > > https://tools.ietf.org/html/rfc5321#section-3.3 >... More on this below but I, at least, find the reminder about that section helpful if only because it appears (to me) to make it clear that validation (whatever that means) of the reverse-path is in scope for SMTP. The only questions are what, and how much, discussion of validation should occur. >... > (Note: This will save at least X% of return-path validation > when X% of the RCPT fails). > > It has nothing to do with whether it is easily spoofed or not, > the return path MUST be valid for the purposes of returns. It > can't be any "random" address per se. It should be validated. > SPF allows one form of validation. Call Back Verification > (CBV), a concept employed since Caller-ID Modem days, has been > applied to SMTP. It has been the #1 rejection method for > invalid return paths within our wcSMTP package since 2003. > > Due to CBV overhead, I would never recommend it as a IETF > standard. However, empirical data collected daily since 2003 > has solidify the high payoff of a CBV operation. It is a > local policy option in our package. I agree with much of what you say above. I don't have any experience with CBV, but remember a proposal from very long ago for doing something similar (and faster) by having the delivery server send a VRFY to the presumed sending system using the address in the MAIL command that delivery server received [1]. Both seem to me to have the same set of problems: (1) They are, as you point out, expensive, especially if the delivery server is trying to keep the connection over which the message came open so it can use reply codes rather than bounce messages. (2) As far as I can tell, anything like this is going to work badly or not at all in a situation involving multiple relay steps, especially when the MX path back to the presumed sender from the recipient system is different from the MX path from the sender to the recipient system or when the originating and receiving systems are not attached to the network at the same time. (3) From the perspective of avoiding "blowback" and similar problems, one needs to know the the reverse-pointing address (i.e., the MAIL command argument) is both a valid address for which mail will be accepted (for which CBV is at least a partial solution, modulo the issue above) _and_ the actual address to which a bounce message can and should legitimately be sent. It seems to me that CBV provides no help, or almost no help, with the latter. How much help SPF provides against a determined attacker is something we can debate another time, but it may lead into a discussion of the appropriateness and utility of methods that depend on attackers being either lazy or not very smart... e.g., if they start succeeding well enough, do we give the would-be attackers incentives to develop and use more sophisticated techniques or, at Paul Vixie more or less put it in another context some years ago, are we just making the bad guys smarter? But, right now, for 5321bis, we have a problem. That problem, at least as I see it it, is that the current text and its handwaving, "Recent work", reference to SPF (and DKIM) needs to be changed in some way. I don't think I've seen any disagreement about that. One extreme, for which I do not believe I have seen a proposal, would be to update the current language to explain what we know about how effective those approaches are. A slightly less extreme version would be for the WG to agree that a discussion of return-path validity and how it might be determined (possibly along the lines of some of the comments in your message) belongs in the A/S with a sentence or two in 5321bis as a forward pointer. If I understand him, Dave believes that either of those would be out of scope. A counterargument (again at least slightly extreme) would be that, by definition, nothing that is discussed in 5321 can possibly be out of scope for the revision effort. You will also note, fwiw, that the current text in 5321 is strictly about verification for use in delivery notifications. Your comments above (and, actually, Dave's suggested text) do not have that limitation. I don't have an opinion (yet) as to whether that is important or not, even to debates about scope limitations. On the other hand, without that limitation to delivery notifications, there may be a case for moving whatever we want to say about reverse-path and their verification into Section 3.3 and reduce Section 3.6.2 to its first paragraph and a cross-reference. That would have the advantage of being more clear because there are reasons to verify reverse-paths that have nothing to do with either relays or the presence of MX records. Coming back to the text Dave proposed and the comments above leaves us in an odd place. The original proposal in the erratum was to simply drop the second and third sentences of the paragraph which, in 5321 reads: "This specification does not deal with the verification of return paths for use in delivery notifications. Recent work, such as that on SPF [29] and DKIM [30] [31], has been done to provide ways to ascertain that an address is valid or belongs to the person who actually sent the message. 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." That suggestion, unlike Dave's, does not make a specific statement about scope. Both it and Dave's suggestion (if I have correctly recorded it), drop the third sentence which does not depend on SPF or DKIM and which, absent either the argument about the WG's scope or one about handwaving, might reasonably be retained. [2] So, if you like one of the alternatives above (or a variation on one) better than the one Dave suggested, please say so and explain why. Or, if you want to propose a different course of action, please explain, either by sending suggested text or at least explaining your position well enough that someone can take a pass at it. I don't see the above meeting that criterion; if you disagree, please explain so I (and others) can understand you better. > That said: > > I would not recommend editing SPF RFC4405 to remove its > validation statement. Validation is the main purpose for using > the SPF mechanism. Why else would you use it? Again, it has > nothing to do whether it is can be spoofed or not, the return > path MUST always be a valid address per RFC5321. If not, then, > imto, it is easily classifiable as rejectable mail transport > identity. And I don't know where that takes us. There has been no proposal to modify RFC 4405 in the WG. Such a proposal would have nothing to do with 5321bis (or 5321), 5322bis (or 5322), or any possible A/S and would hence be far outside the WG's charter even if it had been made. AFAICT, the only question relevant to this particular issue/ticket is what should be done about the SPF (and DKIM)-referencing text in 5321 as discussed above. best, john [1] I note that the Wikipedia article about CBV, https://en.wikipedia.org/wiki/Callback_verification, mentions the VRFY option. [2] Dave's other argument (again, at least if I have correctly understood it) may be a subset of the comment about handwaving above. If the only issue was that the sentence tried to make something sound normative that was not, that issue could be addressed, especially given RFC 8174, by changing "MAY" to lower case. From nobody Fri Mar 26 05:57: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 157FC3A1DF6 for ; Fri, 26 Mar 2021 05:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=FNQEmpwJ; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=ifBkMUYG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01f-SocGMuUF for ; Fri, 26 Mar 2021 05:57:41 -0700 (PDT) Received: from mail.winserver.com (mail.santronics.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A693A1DFC for ; Fri, 26 Mar 2021 05:57:41 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=15164; t=1616763457; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=23OoznvucQWjohi38zJRvsyD5ydt DVKRKvZL94DABWc=; b=FNQEmpwJCKbBiJRMeI/BacoCM8+C+XrbxgoNXEoU/8RB eJl+IvQBmjplO1nt0PiauhGpS22nqEOj+ccVId2sLOhyJ/dAaR0xMB3NSt4LPsTg C9AW6jkP3xlbxGTDnrVNqaGYdK+zdmCkT2i78j5116c4i1K/PgrDqYJnnDh4NDU= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Fri, 26 Mar 2021 07:57:37 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 796645861.1.2332; Fri, 26 Mar 2021 07:57:36 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=15164; t=1616763460; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=23Ooznv ucQWjohi38zJRvsyD5ydtDVKRKvZL94DABWc=; b=ifBkMUYGzdis2yxkQlQDqoY OS/nEgLOku5Mab1uwctJ2CIIkxnqIeAfqmmn/HQNwAM9/cy3Km/BU3T3kP+XNYYh OaufEqtSNn7gdEHbkGYnP3+lKlIGsHbzJ1CC+3UCXqVRrpvL4aUx7zWY8RVwlnw/ KI+hlOhkZN3IyRnX8OA4= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Fri, 26 Mar 2021 08:57:40 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1480304800.1.43776; Fri, 26 Mar 2021 08:57:39 -0400 Message-ID: <605DDA44.5060008@isdg.net> Date: Fri, 26 Mar 2021 08:57:40 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: John C Klensin CC: emailcore@ietf.org References: <6BCAF72097DD9E309ED3271A@PSB> <6054D9E1.6070208@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Issue #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, 26 Mar 2021 12:57:47 -0000 John, I hope the following clarifies my position and pov. The specific paragraph in section 3.6.2. This specification does not deal with the verification of return paths for use in delivery notifications. Recent work, such as that on SPF [29] and DKIM [30] [31], has been done to provide ways to ascertain that an address is valid or belongs to the person who actually sent the message. 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. This was triggered with discussions I helped initiate during the RFC2821bis work. As I recall, I did not wish for specifics given that SPF was experimental and DKIM (and ADSP was part of DKIM) was still on the drawing board and we still had many IETF cogs on the fence with these then new ideas. Both Crocker and Levine were dead set against SPF and ADSP at the time. Their focus was DKIM + SIGNER TRUST modeling. I was asking for a SMTP protocol model recognition for validation due to the fact there was active work and existence of dynamic validation methods working groups currently within the IETF. So yes, I agree. We should remove SPF and DKIM mentioning in this section and simply generalize the modeling for a modern SMTP validation design where every entity, identity at each SMTP state can be validated. Tomorrow someone can invent a new validation method for SMTP and we should continue to provide the protocol language and guidance to smoothly integrate any new invention. For background ... When we did RFC5321 (RFC2821bis) in circa 2008, I was one of the participants advocating recognition of the then new augmented deterministic technologies dealing with new filtering considerations at the SMTP level above and beyond just plain transport SMTP responsibilities. We had three deterministic protocols at the time: - SPF - SenderID also known as SPF/2, the payload version of SPF. - DKIM + ADSP DKIM and ADSP were Proposed Standards working items in the DKIM WG and SPF/SenderID were already completed MARID WG results as established experimental proposals. SPF was on its way to become a "standard" add-on SMTP feature for domains to have available. In other words, the SMTP developers needed to provide the shims and hooks at the various SMTP state machine point to call the SPF CheckHost() function. Overall, these new deterministic protocol policy modeling concepts helped raise the SMTP bar on the public port 25 SMTP operation. With the discussion, you modified a few sections to indicate the existence and the recognition of new augmented methods that MAY play a role in the SMTP reply codes and the delivery of mail. First, RFC2821 section 7.1 had this: This specification does not further address the authentication issues associated with SMTP other than to advocate that useful functionality not be disabled in the hope of providing some small margin of protection against an ignorant user who is trying to fake mail. I suggested a change to recognize it was no longer a small margin to consider. The word "ignorant" was removed for RFC5321. This specification does not further address the authentication issues associated with SMTP other than to advocate that useful functionality not be disabled in the hope of providing some small margin of protection against a user who is trying to fake mail. And then you added the section in question. I believe a focus in the discussion was to keep as a reminder our responsibility and duty as mail transporters first and 2nd to recognize for the need for bounces when delivery can not be met. We did not want any new augmentations to alter the strong SMTP operational tenet for interoperability. Today, I believe we are rehashing the same thing. Nothing has changed other than SPF won over SenderID and is now a Standard Track item. SenderID/PRA/SUBMITTER were deprecated. DKIM became an STD and we are still haggling over the DKIM POLICY model. DMARC replaced ADSP but it still has the same process design issues. It was also indicated that we had two modes of operation: 1) Receivers that applied SPF at SMTP before DATA maybe at MAIL FROM or delayed until RCPT is known per the guidance in section 3.3. 2) Receivers that applied SPF within DATA in order to gain payload data information for full email recording of rejections. The latter required the need to transfer the payload first which could be a high overhead when the payload is large (and today, my friends, 10mb, 15mb, 25mb transfers are not uncommon, people don't always use links but embedded multi-media). With DMARC in the picture now, it is now putting pressure of systems to delay the SPF check or delay the action taken until DATA is reached, the payload is transferred and DMARC is processed to yield an acceptance or rejection response. This is not an optimal mode for a protocol that still has a low payoff. This was why the SUBMITTER protocol was invented which allowed SMTP to process the SenderID PRA (Purported Responsible Address) domain at MAIL FROM: C: MAIL FROM: [SUBMITTER=pra] DMARC needs the same thing and since SENDERID/PRA/SUBMITTER was deprecated when SPF won, I have been proposing that we leverage PRA/SUBMITTER for DMARC purposes. Anyway, none of this should be in RFC5821bis in my opinion. My whole and only point, is not to have language about these specific protocols but to recognize verification/validation is increasingly a major part of every receiver today. In other words, the old days where most receivers just use simple store and forward drop off points for later post-smtp processing is no longer a desirable way to operation given a huge burden of unsolicited junk and spam. Today, increasingly, receivers are feasibly dynamically processing validation concepts at SMTP before DATA is collection. But both modes of operations SHOULD be recognized. That was all my point then and it remains the same today. Thanks. On 3/26/2021 12:14 AM, John C Klensin wrote: > Hector, > > --On Friday, March 19, 2021 13:05 -0400 Hector Santos > wrote: > >> On 3/17/2021 8:23 PM, Dave Crocker wrote: >>>>> This specification does not deal with the >>>>> verification of return paths for use in delivery >>>>> notifications. Server efforts to verify the return path >>>>> using it is outside the scope of this specification. >>> >>> To clarify and make more crisp: >>> >>> >>> This specification does not deal with the verification >>> of a return path. Server efforts to verify a return >>> path are outside the scope of this specification. >> ... >> -1 >> >> Here is why: >> >> For the record, since RFC2821 and now RFC5321,while described >> as beyond the scope of the document as to how validation can >> be done, it does describe the idea for a client/server >> protocol negotiation considerations for the acceptability of >> the the return path in section: 3.3: >> >> >> https://tools.ietf.org/html/rfc5321#section-3.3 >> ... > More on this below but I, at least, find the reminder about that > section helpful if only because it appears (to me) to make it > clear that validation (whatever that means) of the reverse-path > is in scope for SMTP. The only questions are what, and how > much, discussion of validation should occur. > >> ... >> (Note: This will save at least X% of return-path validation >> when X% of the RCPT fails). >> >> It has nothing to do with whether it is easily spoofed or not, >> the return path MUST be valid for the purposes of returns. It >> can't be any "random" address per se. It should be validated. >> SPF allows one form of validation. Call Back Verification >> (CBV), a concept employed since Caller-ID Modem days, has been >> applied to SMTP. It has been the #1 rejection method for >> invalid return paths within our wcSMTP package since 2003. >> >> Due to CBV overhead, I would never recommend it as a IETF >> standard. However, empirical data collected daily since 2003 >> has solidify the high payoff of a CBV operation. It is a >> local policy option in our package. > I agree with much of what you say above. I don't have any > experience with CBV, but remember a proposal from very long ago > for doing something similar (and faster) by having the delivery > server send a VRFY to the presumed sending system using the > address in the MAIL command that delivery server received [1]. > Both seem to me to have the same set of problems: > > (1) They are, as you point out, expensive, especially if the > delivery server is trying to keep the connection over which the > message came open so it can use reply codes rather than bounce > messages. > > (2) As far as I can tell, anything like this is going to work > badly or not at all in a situation involving multiple relay > steps, especially when the MX path back to the presumed sender > from the recipient system is different from the MX path from the > sender to the recipient system or when the originating and > receiving systems are not attached to the network at the same > time. > > (3) From the perspective of avoiding "blowback" and similar > problems, one needs to know the the reverse-pointing address > (i.e., the MAIL command argument) is both a valid address for > which mail will be accepted (for which CBV is at least a partial > solution, modulo the issue above) _and_ the actual address to > which a bounce message can and should legitimately be sent. It > seems to me that CBV provides no help, or almost no help, with > the latter. How much help SPF provides against a determined > attacker is something we can debate another time, but it may > lead into a discussion of the appropriateness and utility of > methods that depend on attackers being either lazy or not very > smart... e.g., if they start succeeding well enough, do we give > the would-be attackers incentives to develop and use more > sophisticated techniques or, at Paul Vixie more or less put it > in another context some years ago, are we just making the bad > guys smarter? > > But, right now, for 5321bis, we have a problem. That problem, > at least as I see it it, is that the current text and its > handwaving, "Recent work", reference to SPF (and DKIM) needs to > be changed in some way. I don't think I've seen any > disagreement about that. One extreme, for which I do not > believe I have seen a proposal, would be to update the current > language to explain what we know about how effective those > approaches are. A slightly less extreme version would be for > the WG to agree that a discussion of return-path validity and > how it might be determined (possibly along the lines of some of > the comments in your message) belongs in the A/S with a > sentence or two in 5321bis as a forward pointer. If I > understand him, Dave believes that either of those would be out > of scope. A counterargument (again at least slightly extreme) > would be that, by definition, nothing that is discussed in 5321 > can possibly be out of scope for the revision effort. > > You will also note, fwiw, that the current text in 5321 is > strictly about verification for use in delivery notifications. > Your comments above (and, actually, Dave's suggested text) do > not have that limitation. > > I don't have an opinion (yet) as to whether that is important or > not, even to debates about scope limitations. On the other > hand, without that limitation to delivery notifications, there > may be a case for moving whatever we want to say about > reverse-path and their verification into Section 3.3 and reduce > Section 3.6.2 to its first paragraph and a cross-reference. > That would have the advantage of being more clear because there > are reasons to verify reverse-paths that have nothing to do with > either relays or the presence of MX records. > > Coming back to the text Dave proposed and the comments above > leaves us in an odd place. The original proposal in the erratum > was to simply drop the second and third sentences of the > paragraph which, in 5321 reads: > > "This specification does not deal with the verification of > return paths for use in delivery notifications. Recent > work, such as that on SPF [29] and DKIM [30] [31], has > been done to provide ways to ascertain that an address is > valid or belongs to the person who actually sent the > message. 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." > > That suggestion, unlike Dave's, does not make a specific > statement about scope. Both it and Dave's suggestion (if I have > correctly recorded it), drop the third sentence which does not > depend on SPF or DKIM and which, absent either the argument > about the WG's scope or one about handwaving, might reasonably > be retained. [2] > > So, if you like one of the alternatives above (or a variation on > one) better than the one Dave suggested, please say so and > explain why. Or, if you want to propose a different course of > action, please explain, either by sending suggested text or at > least explaining your position well enough that someone can take > a pass at it. I don't see the above meeting that criterion; if > you disagree, please explain so I (and others) can understand > you better. > >> That said: >> >> I would not recommend editing SPF RFC4405 to remove its >> validation statement. Validation is the main purpose for using >> the SPF mechanism. Why else would you use it? Again, it has >> nothing to do whether it is can be spoofed or not, the return >> path MUST always be a valid address per RFC5321. If not, then, >> imto, it is easily classifiable as rejectable mail transport >> identity. > And I don't know where that takes us. There has been no > proposal to modify RFC 4405 in the WG. Such a proposal would > have nothing to do with 5321bis (or 5321), 5322bis (or 5322), or > any possible A/S and would hence be far outside the WG's charter > even if it had been made. AFAICT, the only question relevant to > this particular issue/ticket is what should be done about the > SPF (and DKIM)-referencing text in 5321 as discussed above. > > best, > john > > > [1] I note that the Wikipedia article about CBV, > https://en.wikipedia.org/wiki/Callback_verification, mentions > the VRFY option. > > [2] Dave's other argument (again, at least if I have correctly > understood it) may be a subset of the comment about handwaving > above. If the only issue was that the sentence tried to make > something sound normative that was not, that issue could be > addressed, especially given RFC 8174, by changing "MAY" to lower > case. > -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Sun Mar 28 05:58: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 834963A1B43 for ; Sun, 28 Mar 2021 05:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=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=F4caoYnr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=R4VLVOD8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VtlelnLVc6c for ; Sun, 28 Mar 2021 05:58:27 -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 4737A3A1B41 for ; Sun, 28 Mar 2021 05:58:27 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id EA4AA16CA; Sun, 28 Mar 2021 08:58:23 -0400 (EDT) Received: from imap37 ([10.202.2.87]) by compute1.internal (MEProxy); Sun, 28 Mar 2021 08:58:24 -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; s=fm2; bh=F195zFVOkpAZ0AN7E+RqJFOxLaFRErL LEn5cv23Q9A8=; b=F4caoYnrPnQ2DrO2hEU0Ipqf/V7EmWsnSza8sSQEzap63Fj r3iUtkwSdTFSZ8gDgvRD6ggApjsIBTgNVD2Uj3Vn46BsSReFxs8XXdzC61oUba2P mUvemSXE2mqwWTxUaJClOI0LIkMxMTrthDt5ww22j3eBUIeCVlAbijYVVHu9nokX 7lp0fXvXgLs0grQe5Ca5PGn2QtVE738XkwT5iYfGNVZ8ZqQNWA8JXW2SuZoPvfgX QzJ9SmKv2awzquiu+ehBSB3Tlz/DDk9AJ8n1/CL0gaGt6C5uIB2bRF2lGYja++Ua UNDqtiGbAMDNDyIhgeNIGyYkZ6SY4U8FCfPSRsA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=F195zF VOkpAZ0AN7E+RqJFOxLaFRErLLEn5cv23Q9A8=; b=R4VLVOD8wBYj4TZdvvldT/ Qve2WrDdx8lFuG9W6eKxYKGJvlnurQe4+CV5xg5rHPzk+TAqt4VVtcNSIPrfeYMy Zqm0IvKjcm0/yt9/P9jiCeJShalya1pAUJDqhMxGcfdRvmkj/GwOKRAQrPhSNXy3 kIf3m/Q8NXaNMLX7tXl5s7yjRtQLY9jXY9EAjUEeH74SypdMQ9Ial8MT/XZrrzm5 HJFzx1Ey1TnbqZfwI+hMpZEVLmuUbulX9MwmOfnT+ThMXWRtGkExrGkjr6uislNc nrKC0+Q+m6G1RcSYdlRb3EWoOJwNVp5sfTCpiHIhTNQ2A+ajevqjFrXjFTl/rxlA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudehiedgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedftehlvgigvgihucfovghlnhhikhhovhdfuceorggrmhgv lhhnihhkohhvsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtthgvrhhnpeeffffhhf fffeehgfdtjedvfeettedtheffueehteevvdevkeffuefgveduvddtleenucffohhmrghi nhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D15366B40061; Sun, 28 Mar 2021 08:58:22 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249 Mime-Version: 1.0 Message-Id: In-Reply-To: <9A7BDB22F3A0396EF24BF91D@PSB> References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> Date: Sun, 28 Mar 2021 13:58:02 +0100 From: "Alexey Melnikov" To: "John C Klensin" , "Todd Herr" , emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] =?utf-8?q?Ticket_=235=3A_G=2E5=2E_Remove_or_deprecat?= =?utf-8?q?e_the_work-around_from_code_552_to_452=3F?= X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 28 Mar 2021 12:58:33 -0000 On Thu, Mar 11, 2021, at 9:18 PM, John C Klensin wrote: > > --On Thursday, March 11, 2021 11:52 -0500 Todd Herr > wrote: > > (1) As I have suggested elsewhere, more explanatory > cross-references in this over-complicated document would be a > good idea. So: > > OLD: > If an SMTP server has an implementation limit on the > number of RCPT commands and this limit is exhausted, > > NEW/PROPOSED: > If an SMTP server has an implementation limit on the > number of RCPT commands and this limit is exhausted (See > Section 7.8), This looks like a good idea to me. > Comment: > Section 7.8 ("Resistance to Attacks"), which explicitly mentions > large numbers of recipients, is not quite right for this. More > generally, we've talked informally about flexibility for > "operational necessity" for years (I even used that phrase in > G.1) but it does not appear elsewhere in the document. I think > it would be helpful to clarity to re-title 7.8 to "Resistance to > Attacks and Local Operational Requirements" (or something > similar) and probably to add a sentence or two there that would > indicate that attack resistance is not the only issue that might > justify local restrictions. If people agree, text welcome. > > Alexey, I have tentatively added the above as G.15. Unless no > one agrees that the above is at least worth further discussion, > please make a ticket. https://trac.ietf.org/trac/emailcore/ticket/48 Best Regards, Alexey From nobody Sun Mar 28 06:03: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 AFDBE3A1B60 for ; Sun, 28 Mar 2021 06:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=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=SzleDx3N; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BfUd530R Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgjt9PctfGL0 for ; Sun, 28 Mar 2021 06:03:10 -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 BB42C3A1B58 for ; Sun, 28 Mar 2021 06:03:10 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id A19771706; Sun, 28 Mar 2021 09:03:09 -0400 (EDT) Received: from imap37 ([10.202.2.87]) by compute1.internal (MEProxy); Sun, 28 Mar 2021 09:03:09 -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; s=fm2; bh=2eAvDxtCsfiItwW5TitnswWzrduGiDR xnqJzxeUwAcE=; b=SzleDx3NLOPuvzKu0A4hP8GWIbvnk3K+X6b0il89vTp2sna 72xbR5LMheK936snxs12qVkV0v+nkVu2oJJD8kDILtimBH+bOD3Y+gBTf8wtGNTL JLcZM5O/HvjxDKA/CvVFjeEfZK4K9flLZ/cS8XDSZDaSOuz83Y4+iOy+nDSWCxS8 YjncQm5V1GrOuXwuTcEuArxpAM2ykkW0qX+u8M3ZIus5uwriUrG6NWk/Idzk8VFV iuJ/Zyk5PRBKn3jJU01ioCg83FQbRBMJroQ0BgNpbIZxBdhmRLA3wgcjsyjvGetW jj6smqWtjMP6pk7ybmVyVk+aTUkxR2+FqlsPAQQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=2eAvDx tCsfiItwW5TitnswWzrduGiDRxnqJzxeUwAcE=; b=BfUd530RpHSsJHy3iWsCpz T7YkiisytITAUJSUgWDPjLSgHvXBya/1UnTuR8pfoXzpwx2KN/Dq6R1UECJ6Pkxc JlsLiFdEgUl5MjTM227EwhHv6yA8VeXm7XG2TTuouDBEjxzJyv+4f96M6y/KnKko z4SZ1s2KIgYMfdzGepAmKDi5Ql10RDViygwROEZZ9xZ4+sPuDyDyniCWolXxbg7P k2HaTshkL94MwMHA+yBDXv/LkGseXG3r02kQNaJbGw6a0TDkuX15/rAFQE/uH3dA kvsXvWopyXXwDlcWpJY9P17OgzRS7BpAjilGXBOMtpP1TmKxpynM1bVMsoqj827Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudehiedgiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedftehlvgigvgihucfovghlnhhikhhovhdfuceorggrmhgv lhhnihhkohhvsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtthgvrhhnpeeitdeuhe dthfevvdethfegledufeeugfdvjedvheehfeevuedtgedufeegudfhtdenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovh esfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DBD706B40061; Sun, 28 Mar 2021 09:03:07 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249 Mime-Version: 1.0 Message-Id: <2fd6ac6c-5676-4134-bcce-928145d488b4@www.fastmail.com> In-Reply-To: <420176B328E2416BF3351C95@PSB> References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <397cc52c-5533-12a2-6ca2-e46f5987105c@wizmail.org> <6FC2E8E6-334A-4C4B-9FB6-A0F2805C4A31@dukhovni.org> <420176B328E2416BF3351C95@PSB> Date: Sun, 28 Mar 2021 14:02:46 +0100 From: "Alexey Melnikov" To: "John C Klensin" , emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] =?utf-8?q?Ticket_=235=3A_G=2E5=2E_Remove_or_deprecat?= =?utf-8?q?e_the_work-around_from_code_552_to_452=3F?= X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 28 Mar 2021 13:03:16 -0000 Hi John, Trying to concentrate on the specific text about treating 552 in response to RCPT TO as 452: based on feedback from Victor and Jeremy (and I can confirm that Isode's MTA is doing the same), I don't believe implementations are actually 552 in response to RCPT TO as 452. So I think the SHOULD requirement should be removed, with possibly some note in the document that this has changed. Do you agree? Best Regards, Alexey From nobody Sun Mar 28 06:52: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 10AB13A1CB1 for ; Sun, 28 Mar 2021 06:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=AK/EnMgq; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=UOdF1/A+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TX1yrkZ3nhOb for ; Sun, 28 Mar 2021 06:52:37 -0700 (PDT) Received: from mail.winserver.com (ftp.catinthebox.net [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB913A1CB2 for ; Sun, 28 Mar 2021 06:52:37 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=992; t=1616939550; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=9pRPbqu8+HZGfYMts1ApLLoF6V23 RFZr75+f7NTnC3k=; b=AK/EnMgqw6bdFoE5kX05jJ10174nXlkSeJwK4X3Z7RsP e5nPwVJV/7NSGmwZB+5AHBY66GLbXDa1XMkIT9fEZMk+vA2ogSs/h1scajohPi5g H09ugmrwdX54x58sJPEGGrSmuUkPWqpeiyWY4T8KDNeoWvHpFCEZgChRHNgyATk= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Sun, 28 Mar 2021 08:52:30 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 972737683.952.2272; Sun, 28 Mar 2021 08:52:30 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=992; t=1616939548; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=9pRPbqu 8+HZGfYMts1ApLLoF6V23RFZr75+f7NTnC3k=; b=UOdF1/A+S/gNnacLNRtQEHW 5IxuewbkE2ozSG2Wc1DldeRMDyYaakx6Np53ASnws41KSaOgmS2votbW2zTZgOHE 0yUlQ7b1viyA+2JMkrzwNFOfQChgxMx3qt8HWwYwfz9idPksFnT1L7ealn3J7Az7 kay8kkuyr8Gc2638aqmE= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Sun, 28 Mar 2021 09:52:28 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1656392394.1.46624; Sun, 28 Mar 2021 09:52:27 -0400 Message-ID: <60608A18.6070408@isdg.net> Date: Sun, 28 Mar 2021 09:52:24 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: emailcore@ietf.org References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <397cc52c-5533-12a2-6ca2-e46f5987105c@wizmail.org> <6FC2E8E6-334A-4C4B-9FB6-A0F2805C4A31@dukhovni.org> <420176B328E2416BF3351C95@PSB> <2fd6ac6c-5676-4134-bcce-928145d488b4@www.fastmail.com> In-Reply-To: <2fd6ac6c-5676-4134-bcce-928145d488b4@www.fastmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 28 Mar 2021 13:52:43 -0000 On 3/28/2021 9:02 AM, Alexey Melnikov wrote: > Hi John, > > Trying to concentrate on the specific text about treating 552 in response to RCPT TO as 452: based on feedback from Victor and Jeremy (and I can confirm that Isode's MTA is doing the same), I don't believe implementations are actually 552 in response to RCPT TO as 452. So I think the SHOULD requirement should be removed, with possibly some note in the document that this has changed. Do you agree? > > Since 2003 or so, wcSMTP issues: if ((MaxRecipients > 0) && (TotalRecipients+1 > MaxRecipients)) { Send("552 Maximum (%d) Recipients reached.\r\n",MaxRecipients); smtplog("RCPT: Maximum (%d) Recipients reached.",MaxRecipients); return TRUE; } Where MaxRecipient is by default zero (0). Any defined value would be system wide -- not per AUTHorized user although I should probably add that for the next update. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Sun Mar 28 18:54: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 5452A3A2C92 for ; Sun, 28 Mar 2021 18:54:56 -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 8vntlNXCzn9N for ; Sun, 28 Mar 2021 18:54:52 -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 0CF603A2C91 for ; Sun, 28 Mar 2021 18:54:51 -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 1lQh6X-000P4M-AJ; Sun, 28 Mar 2021 21:54:09 -0400 Date: Sun, 28 Mar 2021 21:53:49 -0400 From: John C Klensin To: Alexey Melnikov , emailcore@ietf.org Message-ID: <4111E5BDAD30FCF10645BB1E@JcK-HP5> In-Reply-To: <2fd6ac6c-5676-4134-bcce-928145d488b4@www.fastmail.com> References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <397cc52c-5533-12a2-6ca2-e46f5987105c@wizmail.org> <6FC2E8E6-334A-4C4B-9FB6-A0F2805C4A31@dukhovni.org> <420176B328E2416BF3351C95@PSB> <2fd6ac6c-5676-4134-bcce-928145d488b4@www.fastmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 29 Mar 2021 01:54:56 -0000 --On Sunday, 28 March, 2021 14:02 +0100 Alexey Melnikov wrote: > Hi John, > > Trying to concentrate on the specific text about treating 552 > in response to RCPT TO as 452: based on feedback from Victor > and Jeremy (and I can confirm that Isode's MTA is doing the > same), I don't believe implementations are actually 552 in > response to RCPT TO as 452. So I think the SHOULD requirement > should be removed, with possibly some note in the document > that this has changed. Do you agree? Yes. But, again, up to the WG. best, john From nobody Sun Mar 28 19:01: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 51EF23A2CAB for ; Sun, 28 Mar 2021 19:01:07 -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 419gG7MZTMex for ; Sun, 28 Mar 2021 19:01:01 -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 C43413A2CA9 for ; Sun, 28 Mar 2021 19:01:01 -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 1lQhCg-000P7R-0f; Sun, 28 Mar 2021 22:00:30 -0400 Date: Sun, 28 Mar 2021 22:00:09 -0400 From: John C Klensin To: hsantos@isdg.net, emailcore@ietf.org Message-ID: <5869470BC20BC71EDB5180AF@JcK-HP5> In-Reply-To: <60608A18.6070408@isdg.net> References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <397cc52c-5533-12a2-6ca2-e46f5987105c@wizmail.org> <6FC2E8E6-334A-4C4B-9FB6-A0F2805C4A31@dukhovni.org> <420176B328E2416BF3351C95@PSB> <2fd6ac6c-5676-4134-bcce-928145d488b4@www.fastmail.com> <60608A18.6070408@isdg.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 Archived-At: Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 29 Mar 2021 02:01:07 -0000 --On Sunday, 28 March, 2021 09:52 -0400 Hector Santos wrote: > On 3/28/2021 9:02 AM, Alexey Melnikov wrote: >> Hi John, >> >> Trying to concentrate on the specific text about treating 552 >> in response to RCPT TO as 452: based on feedback from Victor >> and Jeremy (and I can confirm that Isode's MTA is doing the >> same), I don't believe implementations are actually 552 in >> response to RCPT TO as 452. So I think the SHOULD requirement >> should be removed, with possibly some note in the document >> that this has changed. Do you agree? >> >> > > Since 2003 or so, wcSMTP issues: > > if ((MaxRecipients > 0) && (TotalRecipients+1 > > MaxRecipients)) { > Send("552 Maximum (%d) Recipients > reached.\r\n",MaxRecipients); > smtplog("RCPT: Maximum (%d) Recipients > reached.",MaxRecipients); > return TRUE; > } > > > Where MaxRecipient is by default zero (0). Any defined value > would be system wide -- not per AUTHorized user although I > should probably add that for the next update. Hector, RFC 5321 said, in 2008, to use 452 for this case. The only justification I can see for leaving in the text that Alexey and others have proposed removing would be if leaving it there a bit longer would cause you to bring wcSMTP into compliance. If the reality is that either you know about the change and will get around to it someday regardless of what 5321bis says or that nothing we say (or don't say) in 5321bis will make any difference, then it seems to me that we should eliminate confusing text that no longer applies to a significant number of other MTAs. Which is it? Are you suggesting retaining that text and, if so, why? john From nobody Mon Mar 29 03:51: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 542C73A383B for ; Mon, 29 Mar 2021 03:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fap1l5nGUOLj for ; Mon, 29 Mar 2021 03:50:56 -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 66F3C3A3838 for ; Mon, 29 Mar 2021 03:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1617015048; bh=qD8jlgsJAYp1gJlMEoD24UYHNUd726lrUjkH1ZzOFis=; l=1819; h=To:References:From:Date:In-Reply-To; b=A3ozyk/rZEBx9AXFvzuqFm/6dhF888dokjLpaNbAaVogcMnbcpS56gYV8FkXac9Qm MCKzsvF/x58UhJx71r64CorR5Ra7ZQbIu5MddQ/TBZDK7DX4FH9gSKfRfP2TQzcvU8 5LJvMnJOOzZVL8BzhYNT1bXo5IJyI/TMgZyAs2l7N5NWGUdfkPhQCG7jFCDKr 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 00000000005DC0CC.000000006061B108.00000414; Mon, 29 Mar 2021 12:50:48 +0200 To: emailcore@ietf.org References: <6BCAF72097DD9E309ED3271A@PSB> <6054D9E1.6070208@isdg.net> From: Alessandro Vesely Message-ID: <10e5ac01-26fb-c2fe-b5d4-294231041d29@tana.it> Date: Mon, 29 Mar 2021 12:50:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.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] Issue #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: Mon, 29 Mar 2021 10:51:01 -0000 On Fri 26/Mar/2021 05:14:11 +0100 John C Klensin wrote: > You will also note, fwiw, that the current text in 5321 is > strictly about verification for use in delivery notifications. > Your comments above (and, actually, Dave's suggested text) do > not have that limitation. > > I don't have an opinion (yet) as to whether that is important or > not, even to debates about scope limitations. On the other > hand, without that limitation to delivery notifications, there > may be a case for moving whatever we want to say about > reverse-path and their verification into Section 3.3 and reduce > Section 3.6.2 to its first paragraph and a cross-reference. > That would have the advantage of being more clear because there > are reasons to verify reverse-paths that have nothing to do with > either relays or the presence of MX records. I agree that mentioning DKIM in the context of return-path is wrong. However, rather than moving that text into Section 3.3, I'd create a new section. Then, reducing Section 3.6.2 to its first paragraph and a cross-reference is fine. Please keep in mind that there is a paragraph in Section 4.1.4 that talks about verification. It starts with: An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. There is a proposal to weaken the prohibition to base message refusals on the result of that verification (Ticket #47). Since the EHLO argument is also covered by SPF, a cross-reference from 4.1.4 to the same new section I mentioned above may make sense. The result of DKIM verification can only play after the end of data. Yet, mentioning DKIM and DMARC in such new section may be worth, as another example of the often mentioned "policy reasons". Best Ale -- From nobody Mon Mar 29 05:33: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 2F5B43A1008 for ; Mon, 29 Mar 2021 05:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=HGAMVMej; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=AMz7d4i8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoqL3DTfuEc1 for ; Mon, 29 Mar 2021 05:33:47 -0700 (PDT) Received: from mail.winserver.com (ftp.catinthebox.net [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B743A1009 for ; Mon, 29 Mar 2021 05:33:47 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1880; t=1617021219; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=5moGE/XQWvaq4uO/1LzwRgkEaPMC b7wpeHPpIlWKI9w=; b=HGAMVMej4yy73FR0JMd3GFqOxny71pdenrAfU+8jDUzP 2YBokrtlCWEWCL9Lmn1HPXH2gi5/OGirKl7foXNUJBMpevVeRJJo4H2PS55LMP/v iyeneUTLbo7mBjywO+9h2xoUrepPUIUnOHrIRr8uH7VSM4L1HUpq2TAy25RtslE= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Mon, 29 Mar 2021 07:33:39 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1054404066.7274.612; Mon, 29 Mar 2021 07:33:37 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1880; t=1617019999; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=5moGE/X QWvaq4uO/1LzwRgkEaPMCb7wpeHPpIlWKI9w=; b=AMz7d4i8ifHf8VbcCDYVy9E y8ko9OCFyDo23HCR+F//wfA/FaCwgfltpq3w/fpPx9heNW49POeDtx4Q3/GtRmTU KKTO5WR602n8DbmNsFBCxdfv0O4Pc7XtN4qdkWk/J/9kgDnqQVQGszWYPkTTpHzk lOLbTUXrrQnmWwlPHSZA= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Mon, 29 Mar 2021 08:13:19 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1736843659.1.19848; Mon, 29 Mar 2021 08:13:18 -0400 Message-ID: <6061C45E.8090501@isdg.net> Date: Mon, 29 Mar 2021 08:13:18 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: John C Klensin , emailcore@ietf.org References: <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <9A7BDB22F3A0396EF24BF91D@PSB> <397cc52c-5533-12a2-6ca2-e46f5987105c@wizmail.org> <6FC2E8E6-334A-4C4B-9FB6-A0F2805C4A31@dukhovni.org> <420176B328E2416BF3351C95@PSB> <2fd6ac6c-5676-4134-bcce-928145d488b4@www.fastmail.com> <60608A18.6070408@isdg.net> <5869470BC20BC71EDB5180AF@JcK-HP5> In-Reply-To: <5869470BC20BC71EDB5180AF@JcK-HP5> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452? X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 29 Mar 2021 12:33:53 -0000 On 3/28/2021 10:00 PM, John C Klensin wrote: > Hector, RFC 5321 said, in 2008, to use 452 for this case. The only > justification I can see for leaving in the text that Alexey and > others have proposed removing would be if leaving it there a bit > longer would cause you to bring wcSMTP into compliance. If the > reality is that either you know about the change and will get around > to it someday regardless of what 5321bis says or that nothing we say > (or don't say) in 5321bis will make any difference, then it seems to > me that we should eliminate confusing text that no longer applies to > a significant number of other MTAs. Which is it? Are you suggesting > retaining that text and, if so, why? I agree it would be better to use 452 and keep the expected SMTP state machine working with the 4yz (temporary) and 5yz (permanent) logic. I have no comments regarding the suggested text changes. I probably thought about it back in 2821bis and decided to leave it alone since it was an 821 design. Making it 452 might have created an unknown situation at the time. On the receiver side, for the next update, I will make a change to use 452 with an undocumented (why muddy the h2o) switch option to use 552 just in case a revert is necessary. On the client side, the SMTP client will permanently fail the transaction when a 5yz is seen for RCPT. No special case for 552. For our list server when prepared to go direct to SMTP, a 55z code will make the list member inactive. With 452, an error count is incremented for the member but not made inactive. I need to relax this. The list server should check for 552 and not make the user inactive. As long as no hash treatment to the limited list members is done, I don't see any other impact. Thanks -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Mon Mar 29 09:24: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 C24963A1A06 for ; Mon, 29 Mar 2021 09:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=R+x9iYhg; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=NVnHqNbX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBWXz12f0rPC for ; Mon, 29 Mar 2021 09:24:33 -0700 (PDT) Received: from mail.winserver.com (groups.winserver.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC3F3A1A04 for ; Mon, 29 Mar 2021 09:24:33 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3214; t=1617035068; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=+OzZX2wAQPRpVvDT+K4fIogK8YeQ PYwmyz7xmi31+MU=; b=R+x9iYhgQc5R2Dz8nS4kF6wev/SBkmW33ci34BIbppcR 1jfm9tCVZo2d4zdBzUJkXvj2a/QK+3AyeYboAsUiuMCePujc3M/B/I/jsKNiQhUc UKDMiSRmHMOnZwE6ioZ3CWq78T/uGr47ZJSoQKBd7yte7TiXv7YmM/jKCtpR54I= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Mon, 29 Mar 2021 11:24:28 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1068254662.12156.4060; Mon, 29 Mar 2021 11:24:28 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3214; t=1617035067; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=+OzZX2w AQPRpVvDT+K4fIogK8YeQPYwmyz7xmi31+MU=; b=NVnHqNbXCL6CEMrylZyzFt0 Fn+EILVFwci5dKF/yZvPEzbUIKRexww+lNtmE32+cZQ+jtPpmAy5SBqtVWSuwngV wDhy55/NMGpEGbg9FUiU2kMla7VaE5EtmdcJqtQxGFSzdC5AmhzUdFAWEARB0GHv ccBecjAQ+uyTk2dQKw9E= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Mon, 29 Mar 2021 12:24:27 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1751911347.1.10916; Mon, 29 Mar 2021 12:24:26 -0400 Message-ID: <6061FF3A.30706@isdg.net> Date: Mon, 29 Mar 2021 12:24:26 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: emailcore@ietf.org References: <6BCAF72097DD9E309ED3271A@PSB> <6054D9E1.6070208@isdg.net> <10e5ac01-26fb-c2fe-b5d4-294231041d29@tana.it> In-Reply-To: <10e5ac01-26fb-c2fe-b5d4-294231041d29@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Issue #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: Mon, 29 Mar 2021 16:24:39 -0000 On 3/29/2021 6:50 AM, Alessandro Vesely wrote: > On Fri 26/Mar/2021 05:14:11 +0100 John C Klensin wrote: >> You will also note, fwiw, that the current text in 5321 is >> strictly about verification for use in delivery notifications. >> Your comments above (and, actually, Dave's suggested text) do >> not have that limitation. >> >> I don't have an opinion (yet) as to whether that is important or >> not, even to debates about scope limitations. On the other >> hand, without that limitation to delivery notifications, there >> may be a case for moving whatever we want to say about >> reverse-path and their verification into Section 3.3 and reduce >> Section 3.6.2 to its first paragraph and a cross-reference. >> That would have the advantage of being more clear because there >> are reasons to verify reverse-paths that have nothing to do with >> either relays or the presence of MX records. > > > I agree that mentioning DKIM in the context of return-path is > wrong. However, rather than moving that text into Section 3.3, I'd > create a new section. Then, reducing Section 3.6.2 to its first > paragraph and a cross-reference is fine. > > Please keep in mind that there is a paragraph in Section 4.1.4 that > talks about verification. It starts with: > > An SMTP server MAY verify that the domain name argument in the EHLO > command actually corresponds to the IP address of the client. > > There is a proposal to weaken the prohibition to base message > refusals on the result of that verification (Ticket #47). Since the > EHLO argument is also covered by SPF, a cross-reference from 4.1.4 > to the same new section I mentioned above may make sense. > > The result of DKIM verification can only play after the end of > data. Yet, mentioning DKIM and DMARC in such new section may be > worth, as another example of the often mentioned "policy reasons". I like the idea of a new section dedicated to policy topics. The IP Literal check against the connection IP is something our receiver performs. As a client, it will also issue IP literals when there is no public host domain or a static value is defined. We discovered the ietf.org mail server is rejecting transactions based on the usage of IP literals. They have deemed it a spammer, bad guy behavior attribute. How will be this resolved? DKIM as a base protocol is a STD. DMARC is not. I would like to suggest to mention DKIM and DKIM Policy protocols related to the association of 5322.From identity and possibly 5321.Mail From identity. Lets keep it general. Why? I believe we are not quite done with DKIM Policy protocol solutions such as DMARC. Remember, ADSP was abandoned and replaced with DMARC. But DMARC did not resolve the reason ADSP was abandoned and has caused or rather introduced a "disruption" with a borderline tampering Rewrite 5322.From concept. High potential Last Call conflicts. We don't want to get into mentioning Rewrite to suggest the 5322.From field is unstable. I feel DMARC is protocol incomplete and its going to be a moving target before it is all said and done. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Mon Mar 29 11:14:12 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 379813A1D48; Mon, 29 Mar 2021 11:14:10 -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.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <161704165008.24795.14605481856970741671@ietfa.amsl.com> Date: Mon, 29 Mar 2021 11:14:10 -0700 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5322bis-01.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, 29 Mar 2021 18:14: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 : Internet Message Format Author : Peter W. Resnick Filename : draft-ietf-emailcore-rfc5322bis-01.txt Pages : 56 Date : 2021-03-29 Abstract: This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 5322, itself a revision of Request For Comments (RFC) 2822, all of which supersede Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5322bis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5322bis-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-rfc5322bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 30 11:32: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 EEBDC3A1DA7 for ; Tue, 30 Mar 2021 11:32: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, 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=mU1vSc6g; dkim=pass (2048-bit key) header.d=wizmail.org header.b=Yu2wGW3Z Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPAWG2WIOWWh for ; Tue, 30 Mar 2021 11:32:00 -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 964833A1DDB for ; Tue, 30 Mar 2021 11:31:59 -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=FMxF4ajQWTrLJQVnozYfFA2WWRk992DfkTb3p2GI7ts=; b=mU1vSc6gghR9qjt7aHjU/4yqFP DGi4rKGYJdMdBLvRO4ucRP5Ck0G5PTiEXGuBSmY1e35Z/P95oB8HBcJ3VzCg==; 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=FMxF4ajQWTrLJQVnozYfFA2WWRk992DfkTb3p2GI7ts=; b=Yu2wGW3ZqNnuUut4IWfBx8icgE LWGktdtDwWV/LSQE0dGtzR5mHSdZJU7IJ+s5mL/SDNemigDrzv0880pk+WPfvTdmoYlKW4PA1KHkN /I3IB944FQV/Kpdkt7QDsoSaQP8U0EGKhfsEAP80JwGuzQ2n200zKxLiVCMhBHbHdZAUjmKqxqSUh q/4NxAPFSH/WhjB+Pi68ImZUT/4sLDFnC9poK1zfTKeoabhSENfEi76dX0tKjPBBwbbL0gpG3JXrK kRhIlnDd1ps65yCg8a+7FH3avuBkFYKP9P/jriauNBrKk65/Sk+0nziUlVvtT4rFMk2FBycHBG3SC yI3uJ43g==; 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.121) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1lRJ9g-00AUJw-Or for emailcore@ietf.org (return-path ); Tue, 30 Mar 2021 18:31:56 +0000 To: emailcore@ietf.org References: <161704165008.24795.14605481856970741671@ietfa.amsl.com> From: Jeremy Harris Message-ID: <2524ef2c-15d8-c591-260e-3c649ea3c265@wizmail.org> Date: Tue, 30 Mar 2021 19:31:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <161704165008.24795.14605481856970741671@ietfa.amsl.com> 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] I-D Action: draft-ietf-emailcore-rfc5322bis-01.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 30 Mar 2021 18:32:05 -0000 On 29/03/2021 19:14, internet-drafts@ietf.org wrote: > Title : Internet Message Format > Author : Peter W. Resnick > Filename : draft-ietf-emailcore-rfc5322bis-01.txt > Pages : 56 > Date : 2021-03-29 I suggest it is time that Section 4 was deleted. -- Cheers, Jeremy From nobody Tue Mar 30 11:55: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 DF2D93A1E74 for ; Tue, 30 Mar 2021 11:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 HH7f2RBlVdAZ for ; Tue, 30 Mar 2021 11:55:46 -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 C1D963A1E70 for ; Tue, 30 Mar 2021 11:55:45 -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 44F4770251D; Tue, 30 Mar 2021 18:55:44 +0000 (UTC) Received: from nl-srv-smtpout3.hostinger.io (100-96-16-41.trex.outbound.svc.cluster.local [100.96.16.41]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 3FB01700609; Tue, 30 Mar 2021 18:55:41 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout3.hostinger.io ([UNAVAILABLE]. [145.14.159.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.16.41 (trex/6.1.1); Tue, 30 Mar 2021 18:55:43 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Grain-Versed: 741514f428f51642_1617130543766_1671639761 X-MC-Loop-Signature: 1617130543765:3254470406 X-MC-Ingress-Time: 1617130543765 Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout3.hostinger.io (smtp.hostinger.com) with ESMTPSA id 1035031B8DE2; Tue, 30 Mar 2021 18:55:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1617130539; bh=bGUXcJra7XC/H0Q2k/tnZ9oi44/4pX0DNPkwMqxcb3k=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=du0QXZNOyPZptTfXC7Bq6NsmUGFCyg4o/ZGVqLMS467ACRLan6OuryEUeRn8afOVu SOKBNN/Rm+zrphnq2jiclaf4iVPnUBU1pttP+M80SvUV24dQUtVYM5u8uwtWJvFpJf 9gmvKHjs4gmKgDjJ8zALMEsBjtoiEgvTZClmQ8RnfkWw4sc4XpyfDHKF/Ocx16U14W UPLCMa10pjeUmUT90F5PW+p3jSPFfIf8gEb3ohk77Pt1k2UjqXVm21OMIjvlHN8n+V 3qJBtoDcchwcXA/KNjhM/RVaz2Cte7kRZmmlN5XYOAC/tE7aJKkzMK7eBbbqTTpZ56 MecSAwumMwZ9Q== Reply-To: dcrocker@bbiw.net To: Jeremy Harris , emailcore@ietf.org References: <161704165008.24795.14605481856970741671@ietfa.amsl.com> <2524ef2c-15d8-c591-260e-3c649ea3c265@wizmail.org> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <47b8ef6d-3176-7e24-dbda-1c8971e6a6c9@dcrocker.net> Date: Tue, 30 Mar 2021 11:55:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <2524ef2c-15d8-c591-260e-3c649ea3c265@wizmail.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5322bis-01.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 30 Mar 2021 18:55:51 -0000 On 3/30/2021 11:31 AM, Jeremy Harris wrote: > I suggest it is time that Section 4 was deleted. Presumably, that requires that there be no significant, continuing use of those constructs. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Mar 30 12:00: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 E559D3A1F88 for ; Tue, 30 Mar 2021 12:00:17 -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, HTML_MESSAGE=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 LZwYTTKt_vFX for ; Tue, 30 Mar 2021 12:00:13 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34383A1ED8 for ; Tue, 30 Mar 2021 12:00:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 85771DDFF1C0; Tue, 30 Mar 2021 14:00:09 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 627Lvlk0rlgl; Tue, 30 Mar 2021 14:00:08 -0500 (CDT) Received: from [172.16.1.27] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id B78E7DDFF1B6; Tue, 30 Mar 2021 14:00:08 -0500 (CDT) From: Pete Resnick To: Jeremy Harris Cc: emailcore@ietf.org Date: Tue, 30 Mar 2021 14:00:08 -0500 X-Mailer: MailMate (1.14r5786) Message-ID: In-Reply-To: <2524ef2c-15d8-c591-260e-3c649ea3c265@wizmail.org> References: <161704165008.24795.14605481856970741671@ietfa.amsl.com> <2524ef2c-15d8-c591-260e-3c649ea3c265@wizmail.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_6F2930A1-15B3-4698-8856-065C8AA44D34_=" Embedded-HTML: [{"plain":[233, 762], "uuid":"6DFD817C-32A8-42C1-80D1-5FC2D3F10CC6"}] Archived-At: Subject: Re: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5322bis-01.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 30 Mar 2021 19:00:23 -0000 --=_MailMate_6F2930A1-15B3-4698-8856-065C8AA44D34_= Content-Type: text/plain; format=flowed; markup=markdown On 30 Mar 2021, at 13:31, Jeremy Harris wrote: > I suggest it is time that Section 4 was deleted. Whatever I might think about the merits of that idea, I am pretty sure there is no way to do that within the charter of the WG: --- This working group will conduct a limited review and revision to the base email specifications, and will publish new versions of these documents at Internet Standard status, per RFC 6410. The limited review is restricted to corrections and clarifications only, with a strong emphasis on keeping these minimal and avoiding broader changes to terminology or document organization. In addition to processing existing, verified errata and errata marked as "held for document update", the WG may address newly-offered errata. However, no new protocol extensions or amendments will be considered for inclusion into 5321bis and 5322bis documents, unless they are already published as IETF Stream RFCs and are at sufficient maturity level to move to Internet Standard. --- pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best --=_MailMate_6F2930A1-15B3-4698-8856-065C8AA44D34_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

On 30 Mar 2021, at 13:31, Jeremy Harris wrote:

I suggest it is time that Section 4 was deleted.

Whatever I might think about the merits of that idea, I a= m pretty sure there is no way to do that within the charter of the WG:

This working g= roup will conduct a limited review and revision to the base
email specifications, and will publish new versio= ns of these documents at
Internet St= andard status, per RFC 6410. The limited review is restricted
to corrections and clarifications only, with a = strong emphasis on keeping
these min= imal and avoiding broader changes to terminology or document
organization. In addition to processing existing= , verified errata and
errata marked = as "held for document update", the WG may address
newly-offered errata. However, no new protocol extensions o= r amendments
will be considered for = inclusion into 5321bis and 5322bis documents,
unless they are already published as IETF Stream RFCs and are a= t
sufficient maturity level to move = to Internet Standard.


---

pr

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

--=_MailMate_6F2930A1-15B3-4698-8856-065C8AA44D34_=-- From nobody Tue Mar 30 15:48: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 A05BA3A1229 for ; Tue, 30 Mar 2021 15:48:08 -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.249, 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=d3Yc95v1; dkim=pass (2048-bit key) header.d=taugh.com header.b=W2nrKzrn Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTZ3D09IrSZX for ; Tue, 30 Mar 2021 15:48:03 -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 159A73A122B for ; Tue, 30 Mar 2021 15:48:02 -0700 (PDT) Received: (qmail 44766 invoked from network); 30 Mar 2021 22:48:01 -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=aeda.6063aaa1.k2103; bh=BqYNNi8rm02ofNmbIzrkdBtaH8NSb+XSkp73uSlS6g0=; b=d3Yc95v1accW7kIYa/5B2fyMqrynyfPuNFjWo2o1KTCFSKjXqQrGoakAGJeGAAC5MaPq3h9IQKJlwKAa2VoH/BTlDT2Rl3sei4fDM7QllwahZjHp52QVTNuS79wbICqF5YmtFYgEdVTvNLkrswY/AbaPAfsk7U5tvkbj2+nRCvLjSvg1uPgwq/HVaOELSgr7yOr5KGX1tDrMym66847nc+ovxp8CdA/9haF0YIWJsGH+FoFnsmRo9jxEMMXdXVZerpg9xmZcH7P9MkZMI9cglMhTnMLbEoin0NRNfjlocxm2QIOvRDMH9147AyTgV41iS1kI6KfDygvE67LDVXvv7Q== 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=aeda.6063aaa1.k2103; bh=BqYNNi8rm02ofNmbIzrkdBtaH8NSb+XSkp73uSlS6g0=; b=W2nrKzrnkwt4ef9rdlLTS1gEheh4mZmuyS9S3hpL2TvyIOgNBQxxejb2LYJ3wfZoqTSnjI39zfNXPVeRkzNu7Us4f7G1b1eyJ4gdazU0c4dCZqvXu9doJrbiXX7CCC5721fvgUfF47Ye9z9OwVDaDUpVmZWmeTEtRqNvOupJxlwYo6eCcUUg4xr1Xftf40MO7rsDU7LtuPV1SyYPpszBnLIhAisBnGzB4bIkN199ULy6xGs12jKBcWlI2vHCaRyH2anSwR0QVPyM9/xTl1ilKYIo4RJFefTzaYNVclR0G0Gy6Jjl/RZtQNXuKGTWJCN6OVNJyxppm+y/DX4CdrYsqg== 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; 30 Mar 2021 22:48:00 -0000 Received: by ary.qy (Postfix, from userid 501) id 3D44C71A5512; Tue, 30 Mar 2021 18:47:59 -0400 (EDT) Date: 30 Mar 2021 18:47:59 -0400 Message-Id: <20210330224800.3D44C71A5512@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: resnick@episteme.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] I-D Action: draft-ietf-emailcore-rfc5322bis-01.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 30 Mar 2021 22:48:09 -0000 It appears that Pete Resnick said: >-=-=-=-=-=- > >On 30 Mar 2021, at 13:31, Jeremy Harris wrote: > >> I suggest it is time that Section 4 was deleted. > >Whatever I might think about the merits of that idea, I am pretty sure >there is no way to do that within the charter of the WG: How about saying they MAY be accepted rather than MUST? R's, John From nobody Tue Mar 30 15:54: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 3EB803A126B for ; Tue, 30 Mar 2021 15:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 0DrXcLBF8jqI for ; Tue, 30 Mar 2021 15:54:08 -0700 (PDT) Received: from common.ash.relay.mailchannels.net (common.ash.relay.mailchannels.net [23.83.222.38]) (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 46E993A1267 for ; Tue, 30 Mar 2021 15:54:06 -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 D35BC5415C5; Tue, 30 Mar 2021 22:54:02 +0000 (UTC) Received: from nl-srv-smtpout1.hostinger.io (100-96-18-61.trex.outbound.svc.cluster.local [100.96.18.61]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id DA521541499; Tue, 30 Mar 2021 22:53:59 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout1.hostinger.io ([UNAVAILABLE]. [185.224.136.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.18.61 (trex/6.1.1); Tue, 30 Mar 2021 22:54:02 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Fumbling-Broad: 196e77ee0f703c26_1617144842538_1496590652 X-MC-Loop-Signature: 1617144842538:973968183 X-MC-Ingress-Time: 1617144842538 Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout1.hostinger.io (smtp.hostinger.com) with ESMTPSA id 7F9AC22693B1; Tue, 30 Mar 2021 22:53:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1617144838; bh=sPgIcdbTmsXMQKYYvOng7pz7kdTFhLV4GRVbGwgxqgs=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=G2iF0pAllCThNK6XI30oVTXHh9hX88s6l2I+fzC3ls2ryCu+7YPjiZ6WjThskncb5 Q+VgkSoIVxXPHRxt4L1E4enlGVoJM48dsnyXjF/8HsUjGKQ/dd3zg12jPSNpQNyldt QrtIUqohdl8dE0YTo13WaTQaytyiyK8SC52d4YJPOoaMuYOpnT1MZmG8w5PMtNwrM4 6DcGRsBYUe7o7hHe7m4XkI7dqtsKVhrD9+jBlLMI3gqwuUFHQaUQB5EFUtWZJ4kiYA nkjJmfVLl9ZK+CnXb3t2mcpef3t74tZZ8wRrFIYFaSLg/J+1lI6z2QfW/27aoA9KC0 bt8n3FN35UGqg== Reply-To: dcrocker@bbiw.net To: John Levine , emailcore@ietf.org Cc: resnick@episteme.net References: <20210330224800.3D44C71A5512@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <489708dd-e2a5-1c51-93c3-c061b81f868c@dcrocker.net> Date: Tue, 30 Mar 2021 15:53:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <20210330224800.3D44C71A5512@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5322bis-01.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 30 Mar 2021 22:54:13 -0000 On 3/30/2021 3:47 PM, John Levine wrote: >> Whatever I might think about the merits of that idea, I am pretty sure >> there is no way to do that within the charter of the WG: > How about saying they MAY be accepted rather than MUST? What is the evidence that deployed support for those constructs has reduced enough to mean that a failure to implement them will not significantly injure interoperability? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Mar 30 17:42: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 D4E473A0912 for ; Tue, 30 Mar 2021 17:42:10 -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 (2048-bit key) header.d=iecc.com header.b=mBEXmFjJ; dkim=pass (2048-bit key) header.d=taugh.com header.b=D7ocl+WI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0K_S_OGTlVX for ; Tue, 30 Mar 2021 17:42: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 3DA7A3A0907 for ; Tue, 30 Mar 2021 17:42:05 -0700 (PDT) Received: (qmail 69554 invoked from network); 31 Mar 2021 00:42:02 -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=10fb0.6063c55a.k2103; bh=+dw2+SmjfL8lEItklqjRhi0PlIgN9GMGF47zVp9vmOs=; b=mBEXmFjJ1WG0Jv0Npz+0gmZG3JUaQSJf4nUN4Lgc757J1shf+tTsHNVDo8906lXAfgkI+aGIMmXY69AkFfY80D2u4K0NQEZfgEG6xr7qvQn3ZlK/98R93Ra+K6Dhw8APcNC30luxmPSdL0FngMy7QjiQYDFKwmk6meYPtRCFX8a1cr+bJ3kxhYbXvfx5TnwcQFbGxYd3D/HNKgQ3RvqNickBjN9IjWeiKY0r74sfDnjN3GgK4V8jZoKRE/7tR/4PrgN/ges2R9xcSDHtk6gU3czSn+yyL+tBGGibL+K4o1FvhGepy5ZP27zxUV61kSivopeNJPGjFhkMIhnftHRnig== 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=10fb0.6063c55a.k2103; bh=+dw2+SmjfL8lEItklqjRhi0PlIgN9GMGF47zVp9vmOs=; b=D7ocl+WIOqdN4o3wJPXZbdCK/H3kXjA/I5K8dKU6aJG82UfJBJa2LMBm54vc0kWFpnawHlF67uI6lX/nNjJVoZDruuY2XXQ4COxZpFH/LSli2bwlH6FTujoEuMAVSdg4AlMGYAGoeMoeuL1s3ob/XDDjryC4gWHO9nrCkzMNIQ3jn+JbwcT2W5jM9HvgGCOx/0ZG2oJsgtN63jxLqVxfWQbbqot9WeToceIiowMqq615nYBqzl4fMiwnfaKdEyUwczStKuwJAjvyNKedKX+SCxHrE35dxYA3fhudtSeUG9n77y7WDoQhw9f+54uLBrYxNGoggGVOp/3KmXsvHpF1Vw== 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; 31 Mar 2021 00:42:02 -0000 Received: by ary.qy (Postfix, from userid 501) id D062971A62CF; Tue, 30 Mar 2021 20:42:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 7D70A71A62B1; Tue, 30 Mar 2021 20:42:00 -0400 (EDT) Date: 30 Mar 2021 20:42:00 -0400 Message-ID: <6f698bf2-7849-39a2-35d5-c49a41ae5b9@taugh.com> From: "John R Levine" To: "Dave Crocker" , emailcore@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: <489708dd-e2a5-1c51-93c3-c061b81f868c@dcrocker.net> References: <20210330224800.3D44C71A5512@ary.qy> <489708dd-e2a5-1c51-93c3-c061b81f868c@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5322bis-01.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 31 Mar 2021 00:42:11 -0000 > What is the evidence that deployed support for those constructs has reduced > enough to mean that a failure to implement them will not significantly injure > interoperability? Good question. I've looked at the relatively small amount of mail I receive and don't see things like text tiem zones or spaces before the colon in a header but I would be nice if someone bigger had some data. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Mar 31 07:36: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 3D2E13A2A8A for ; Wed, 31 Mar 2021 07:36:20 -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=isdg.net header.b=hrtA+o+8; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=D39z1nYp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5O_3jsIk5Op7 for ; Wed, 31 Mar 2021 07:36:14 -0700 (PDT) Received: from mail.winserver.com (secure.winserver.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1133A2A85 for ; Wed, 31 Mar 2021 07:36:14 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3206; t=1617201367; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=GSG4nbJjmSd7LhIaqbGrdFnsHODk t/ZgPMuPNOqnetg=; b=hrtA+o+8+B5+JE4LGmyJPV8jNi/BjIQRqrImiqV8pSIz DloLEcHLvtOTQXQc6Sc8OMDa8O7L+oTjS8kBv6phLUa3/j2L433YT1moXCRVd+Qk ifPkRC/FNhtuR3ZR04n9zrqSPwhrOdxzRoLr0RUwRx/bSsVwN7jGFSw4V7OR2jk= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Wed, 31 Mar 2021 09:36:07 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1234551229.16729.576; Wed, 31 Mar 2021 09:36:06 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3206; t=1617201363; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=GSG4nbJ jmSd7LhIaqbGrdFnsHODkt/ZgPMuPNOqnetg=; b=D39z1nYpaTZ6s/asFh5Y20N 9bAgUEAS1AxUpr8Ckoqsf/j9O7wDNGUCfmDBhpgyN1D9hevbVygdX0ITjBeokhH6 XCs2+rmbSxZZM2ql74ODdZWBbX+FbmGcungnBUsywsr8PkAS/5N7GEoQlotK1sSA iipV4/GP3M2r9dYIFOaQ= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Wed, 31 Mar 2021 10:36:03 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1918207409.1.8632; Wed, 31 Mar 2021 10:36:02 -0400 Message-ID: <606488D9.3060003@isdg.net> Date: Wed, 31 Mar 2021 10:36:09 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: emailcore@ietf.org References: <161704165008.24795.14605481856970741671@ietfa.amsl.com> In-Reply-To: <161704165008.24795.14605481856970741671@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] Unstructured and Structured Header Fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2021 14:36:20 -0000 On 3/29/2021 2:14 PM, internet-drafts@ietf.org wrote: > 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 : Internet Message Format > Author : Peter W. Resnick > Filename : draft-ietf-emailcore-rfc5322bis-01.txt > Pages : 56 > Date : 2021-03-29 > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5322bis-01.html > > Hi Peter, thanks for your work. I don't see anything outstanding from the diff that stood out. A fresh reading of this draft, I found myself stopping at 2.2.1 and 2.2.2, wasting time trying to find examples of an unstructured and structured header field. I think it would really go "easier" (smoother flow) on the reader (especially for new mail engineer) if there was a simple example shown for an unstructured and a structured header field for section 2.2.1 and 2.2.2 respectively. There is an example for a Long Header Field in section 2.2.3. So perhaps the idea of a simple example of the two sections preceded it would not be out of line. It will better help to understand the subtle difference between unstructured and structured header fields and also provide a heads up on the finer details for structured header fields for the rest of the document. Is the "Subject" header field of an unstructured or structured header field? Is it unstructured because its data is taken "as is" without additional parsing? Do optional header field comments only applied to structured header fields? For example, the subject line: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5322bis-01.txt (comment, treat as meta?) Mail apps, i.e. perhaps a gateway, importer or even an MUA, could potentially be doing some parsing of the Subject field. To me, the bottom line, the key difference is that structured header fields require additional parsing of the header field body before it can used. I know many of the cogs will say "Nahh, its fine. No examples needed." I suggest consider the new reader, the newer SMTP developer. This is big document with many subtle details. So in my tech reading opinion, "Being Specific Is Terrific" always helps to provide readers a faster understanding of key tech concepts. The suggestion is to simple examples in these sections, 2.2.1 and 2.2.2, trying to avoid getting into lengthy details about the examples. 2.2.1 Unstructured Header Field Bodies ... Example of an unstructured header field bodies: Subject: support-case-id: 20210401.120011.003 While this may appear structured to the application developer, it is not for SMTP operations. 2.2.2 Structured Header Field Bodies ... Examples of a structured header field bodies: Date: Mon, 29 Mar 2021 11:14:10 -0700 Message-id: <161704165008.24795.14605481856970741671@example.com> Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for hsantos@isdg.net; Mon, 29 Mar 2021 13:14:16 -0500 Thanks -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Wed Mar 31 09:56: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 CAFBE3A2E65 for ; Wed, 31 Mar 2021 09:56:00 -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, 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 qM7n0Zhz3zIK for ; Wed, 31 Mar 2021 09:55:55 -0700 (PDT) Received: from crocodile.elm.relay.mailchannels.net (crocodile.elm.relay.mailchannels.net [23.83.212.45]) (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 AEBC13A2E67 for ; Wed, 31 Mar 2021 09:55:55 -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 BC4496416F8 for ; Wed, 31 Mar 2021 16:55:53 +0000 (UTC) Received: from nl-srv-smtpout4.hostinger.io (100-96-27-144.trex.outbound.svc.cluster.local [100.96.27.144]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 3271E641C7F for ; Wed, 31 Mar 2021 16:55:51 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout4.hostinger.io ([UNAVAILABLE]. [145.14.159.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.27.144 (trex/6.1.1); Wed, 31 Mar 2021 16:55:53 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Wide-Eyed-Robust: 668e0cc6355a8038_1617209753520_2090932941 X-MC-Loop-Signature: 1617209753520:421123762 X-MC-Ingress-Time: 1617209753520 Received: from [192.168.0.109] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout4.hostinger.io (smtp.hostinger.com) with ESMTPSA id 455A73130412 for ; Wed, 31 Mar 2021 16:55:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1617209749; bh=O/zCJwaQjo2PIk4PETXUM5L5sD0wZeNi6rVCjANK2pI=; h=Reply-To:To:From:Subject:Date; b=hCn6kYlsMgvFhPYb8f0gElfroaeDbtV6IL9Hzqz3B4mot7Dh2q/WrPi8xxwxICo8u YhmTo0mdBJuHqaQhSf+x6hYhsN2qHMifaqkFa1MZcQHZy+caS4SdFcf3eU1OSepurE q4pNAhMMdpPOoeS0AwsMRFHuJlMAZzmYkeJEQ7w3uht9NhMOWUK6SPutlKItLa0Ini /cCd/dPzeE//8v3vdAPb+SUkOBpxLt283nVpcNHh2fLIp5HEi5vyI5NC43/j0o8XdK 2MbslKsMoFEvYaozI3tmQFbP+44a7Rnlr6YTI6lB2wpt4YcUfLbyNy7zwytn1VKF2J p9fNp0R0vh+iA== Reply-To: dcrocker@bbiw.net To: "emailcore@ietf.org" From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <2bde4fd6-70df-6251-d45c-32eca1d5df58@dcrocker.net> Date: Wed, 31 Mar 2021 09:55:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] WG scope X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 31 Mar 2021 16:56:01 -0000 We keep having efforts to pursue entirely worthy topics that unfortunately appear to be outside the scope of this working group's charter. The core text I see in the charter is: > The limited review is restricted > to corrections and clarifications only, with a strong emphasis on keeping > these minimal and avoiding broader changes to terminology or document > organization. I read "corrections and clarifications" as meaning that the text either must be in error -- text that is wrong or text that is missing and is deemed to be essential -- or must reasonably be subject to misinterpretation. Perhaps it will help, when someone suggests a change to a wg document, for them to explain whether the change is a correction or clarification (or both) and why it is needed? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Mar 31 13:59: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 D43C63A3721 for ; Wed, 31 Mar 2021 13:59:44 -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, HTML_MESSAGE=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 da1hjXw5X680 for ; Wed, 31 Mar 2021 13:59:40 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A21E23A371E for ; Wed, 31 Mar 2021 13:59:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id C1BA6DE335D5; Wed, 31 Mar 2021 15:59:38 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VuxMOjW4eD5; Wed, 31 Mar 2021 15:59:38 -0500 (CDT) Received: from [172.16.1.27] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id DD572DE335C5; Wed, 31 Mar 2021 15:59:37 -0500 (CDT) From: Pete Resnick To: Hector Santos Cc: emailcore@ietf.org Date: Wed, 31 Mar 2021 15:59:36 -0500 X-Mailer: MailMate (1.14r5786) Message-ID: In-Reply-To: <606488D9.3060003@isdg.net> References: <161704165008.24795.14605481856970741671@ietfa.amsl.com> <606488D9.3060003@isdg.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_D2F0C59C-B770-4110-9387-773A5ED313C9_=" Archived-At: Subject: Re: [Emailcore] Unstructured and Structured Header Fields X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2021 20:59:45 -0000 --=_MailMate_D2F0C59C-B770-4110-9387-773A5ED313C9_= Content-Type: text/plain; format=flowed; markup=markdown On 31 Mar 2021, at 9:36, Hector Santos wrote: > On 3/29/2021 2:14 PM, internet-drafts@ietf.org wrote: >> 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 : Internet Message Format >> Author : Peter W. Resnick >> Filename : draft-ietf-emailcore-rfc5322bis-01.txt >> Pages : 56 >> Date : 2021-03-29 >> >> There is also an HTML version available at: >> https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5322bis-01.html >> >> > > Hi Peter, thanks for your work. > > I don't see anything outstanding from the diff that stood out. Excellent. Thanks. > A fresh reading of this draft, I found myself stopping at 2.2.1 and > 2.2.2, wasting time trying to find examples of an unstructured and > structured header field. Do note that this is the explanatory section of the document, so I think this falls into the category of "nice to have", but as I stated to the previous comment, I don't think this is really in scope for this limited update. FWIW, I don't think there would be any harm in adding additional examples in the AS document. But as always, if the chairs make the call that this falls within scope and there is WG consensus to do so, glad to come up with an example or two (or steal yours). pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best --=_MailMate_D2F0C59C-B770-4110-9387-773A5ED313C9_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

On 31 Mar 2021, at 9:36, Hector Santos wrote:

On 3/29/2021 2:14 PM, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Intern= et-Drafts directories.
This draft is a work item of the Revision of core Email specifications WG= of the IETF.

     Title       =
    : Internet Message Format
     Author          : Peter W. Resnick

Filename : draft-ietf-emailcore-rfc5322bis-01.txt<= br> Pages : 56
Date : 2021-03-29

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-iet= f-emailcore-rfc5322bis-01.html

Hi Peter, thanks for your work.

I don't see anything outstanding from the diff that stood= out.

Excellent. Thanks.

A fresh reading of this draft, I found myself stopping at= 2.2.1 and 2.2.2, wasting time trying to find examples of an unstructured= and structured header field.

Do note that this is the explanatory section of the docum= ent, so I think this falls into the category of "nice to have", but as I = stated to the previous comment, I don't think this is really in scope for= this limited update. FWIW, I don't think there would be any harm in addi= ng additional examples in the AS document. But as always, if the chairs m= ake the call that this falls within scope and there is WG consensus to do= so, glad to come up with an example or two (or steal yours).

pr

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

--=_MailMate_D2F0C59C-B770-4110-9387-773A5ED313C9_=--