From nobody Tue Feb 1 06:35:55 2022 Return-Path: X-Original-To: emailcore@ietf.org Delivered-To: emailcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8C63A1071; Tue, 1 Feb 2022 06:35:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emailcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <164372613923.28086.14316292176457903078@ietfa.amsl.com> Date: Tue, 01 Feb 2022 06:35:39 -0800 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5321bis-09.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: Tue, 01 Feb 2022 14:35:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Revision of core Email specifications WG of the IETF. Title : Simple Mail Transfer Protocol Author : John C. Klensin Filename : draft-ietf-emailcore-rfc5321bis-09.txt Pages : 123 Date : 2022-02-01 Abstract: This document is a specification of the basic protocol for Internet electronic mail transport. It (including text carried forward from RFC 5321) consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. The document also provides information about use of SMTP for other than strict mail transport and delivery. This document replaces RFC 5321, the earlier version with the same title. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5321bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-rfc5321bis-09 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Tue Feb 1 06:42:03 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91A63A10AA for ; Tue, 1 Feb 2022 06:42:01 -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 vlHCYwIGATsb for ; Tue, 1 Feb 2022 06:41:57 -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 6557D3A10A9 for ; Tue, 1 Feb 2022 06:41:56 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nEuLz-000BAb-Dv for emailcore@ietf.org; Tue, 01 Feb 2022 09:41:55 -0500 Date: Tue, 01 Feb 2022 09:41:49 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: <5B4FF4243EF288A6C893B452@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] draft-ietf-emailcore-rfc5321bis-09 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2022 14:42:02 -0000 As you will all have seen from the tracker notice, draft-ietf-emailcore-rfc5321bis-09 has been posted. This version contains changes tentatively agreed upon during the Interim (there have been substantially no on-list comments about those agreements as they affect rfc5321bis since that time) and some steps toward getting the document cleaned up. Careful reading, at least of diffs, would be appreciated. Details of changes in Appendix H.3.13. enjoy! john From nobody Tue Feb 1 09:24:03 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AAD3A1710 for ; Tue, 1 Feb 2022 09:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.813 X-Spam-Level: X-Spam-Status: No, score=-7.813 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=CZme5bZ2; dkim=pass (1152-bit key) header.d=tana.it header.b=Cy761kaJ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWcR9biiimfg for ; Tue, 1 Feb 2022 09:23:54 -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 9FEDC3A170D for ; Tue, 1 Feb 2022 09:23:52 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1643736227; bh=gN8R/5bkQJdwGf9e+G9rJVpA4vc0NPSjr+fXE8zqh2M=; h=Subject:To:References:From:Date:In-Reply-To; b=CZme5bZ26pYEDPCmBGgCTPC9+wMtLWnJPSZKRaDYVyPoSWPe+TEiAt/7iF0TpNc2E 0bbMF9CLr85z37RSqMIDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1643736227; bh=gN8R/5bkQJdwGf9e+G9rJVpA4vc0NPSjr+fXE8zqh2M=; h=To:References:From:Date:In-Reply-To; b=Cy761kaJptL3SW8GpF6MC8v4pBo478PM0gfGgL+hFC2uie/UMPa+sG+bkgJ1KO1BA lpSLbII5TqOEUbfqZIVZWNDLWvztw3CQDDJjz3aJVTQK0pXWm2WeFwPHXjCyGYN3US WBRIMupDiagRIYUUzd3FE/0d+EcX521Zm8dQ2ioakE8fXDq4BDHJUTxAFftu1 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 00000000005DC09F.0000000061F96CA3.00005C9D; Tue, 01 Feb 2022 18:23:47 +0100 To: emailcore@ietf.org References: <20220201033347.7931D35D1ADE@ary.qy> From: Alessandro Vesely Message-ID: <50ec8a20-6565-1f5e-6ad8-4ea68006fbbf@tana.it> Date: Tue, 1 Feb 2022 18:23:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20220201033347.7931D35D1ADE@ary.qy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 3 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2022 17:24:01 -0000 On Tue 01/Feb/2022 04:33:46 +0100 John Levine wrote: > It appears that Alessandro Vesely said: >>> Note: With typical email use of TLS, authentication only is performed >>> by the sending client of the target receiving server. That is, it >>> serves to validate that the connection has been made to the intended >>> server, but does not validate who initiated it. >> >>To be even more clear, I'd add something like "Sending client >>authentication is usually done on the first hop only, see Section 5.4". > > I'm not sure whether you are referring to authentication OF the sending client > or BY the sending client, but either way, it seems wrong. Oh well, I meant OF, but since the phrase was intended to clarify (in a somewhat tutorial manner) the note quoted above, its being not clear itself is enough to bar it. Best Ale -- From nobody Tue Feb 1 09:53:08 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AA23A181C for ; Tue, 1 Feb 2022 09:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=aDnMkxmk; dkim=pass (1152-bit key) header.d=tana.it header.b=DCS5QDjz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvN56AkEYmNa for ; Tue, 1 Feb 2022 09:52:59 -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 B843A3A1819 for ; Tue, 1 Feb 2022 09:52:57 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1643737973; bh=o3IDSoraNH6+ye8y/S4Sw9VbXRGm1IIggsfTvsfDtO0=; h=Subject:To:References:From:Date:In-Reply-To; b=aDnMkxmkEK1U/oGuFBMePbYdb7gewHeq1zXbntd4IcUwdJJD16RomMWVCiYmDcIq4 He4iSGDfMOuveoz4M5CDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1643737973; bh=o3IDSoraNH6+ye8y/S4Sw9VbXRGm1IIggsfTvsfDtO0=; h=To:References:From:Date:In-Reply-To; b=DCS5QDjzgyIDOKIv46sAknnuhaFHMMcMxFIHwE7vb0soHFDCEeXuciN/37eojNTKW LXC/IifAiIhRiOqF6W2aZzRKo96kQKcvFa7W39MZW723Cy73Y40mcC2o0G+Rmsp5Qz 5RJIsUagxg7BU9YoGhTgEB1lOVx71ok1j0vkIqYlxfRaaqvSWgDca7sMohS06 Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC026.0000000061F97375.00005FFD; Tue, 01 Feb 2022 18:52:53 +0100 To: emailcore@ietf.org References: <164364401410.15844.7642839719540036536@ietfa.amsl.com> From: Alessandro Vesely Message-ID: <44a39323-fcc0-c646-7e81-a08effa05b31@tana.it> Date: Tue, 1 Feb 2022 18:52:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <164364401410.15844.7642839719540036536@ietfa.amsl.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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, 01 Feb 2022 17:53:06 -0000 On Mon 31/Jan/2022 16:46:54 +0100 internet-drafts wrote: > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-as-04 Section *Use of SMTP Extensions* is the most noticeable addition. I'd question one extension: * Enhanced Mail System Status Codes [RFC5248] The implementation I use, Courier-MTA, does not implement it. The argument I heard about not having it is that, in fact, only the first byte of the response is needed to interoperate. How is that "MUST be supported by SMTP senders and receivers" going to affect usage practice of that software? Best Ale -- From nobody Tue Feb 1 18:13:28 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1803A1CB6 for ; Tue, 1 Feb 2022 18:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=MS8BEEhv; dkim=pass (2048-bit key) header.d=taugh.com header.b=2SOxXiUX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xikyv9d89xbz for ; Tue, 1 Feb 2022 18:13:20 -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 9B3463A1CB5 for ; Tue, 1 Feb 2022 18:13:20 -0800 (PST) Received: (qmail 98323 invoked from network); 2 Feb 2022 02:13:18 -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=1800f.61f9e8be.k2202; bh=SNXTEdBjr7oO4NI/tcpK+ayYwTu9Y9iXUUYXd3SCAsA=; b=MS8BEEhveMwXbjPezciKGEZkwIRkHW6KiduBFgshNChRsWPYAmg/Q2vO79D0qrP+L6P+r2WUNLRRmYzqJ1kgeze1ELO+FR80UujMCnnEhEyx6fnTqgglDo36p+emqVEYn/V/zIBgVUKKweN3eiaQGoesDwCqHqrVJRFJINnC6+bAWk0Od2aFw3TZ0R+Zlk9bPtKjwbmkuknv5XEr3/YrrSUklikoRwKKqdUsd2YUIrhdB12YH0S+Aun/QRRkjIBr9unYh76OU7wmUBoDYQNYrcB2QN7hMjk9Q61ZQYy9r7vwhfgH5PFldS9ZFWwRSaB8Hi0LUlHtl76XMA0UQLNZiw== 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=1800f.61f9e8be.k2202; bh=SNXTEdBjr7oO4NI/tcpK+ayYwTu9Y9iXUUYXd3SCAsA=; b=2SOxXiUXQYrcOkT8TbWTsOMEvjyfyxfVNf5Um2g+WD3cCC80aKCi+f5ZkFmO8GtJ95iIykXUDAgc0D0I8JfXW7DNYlNEuiVKDKnsTDg3HVRgokeeCf2dAugZRl1oCz3EI7qd2gHfdRFXj2ioIOFm6GnR3dP66LRAWWYjL2vxMIetds2iTFE4SaGe/Sishdw1MKHQJQmr0zEfj29roidJXSYzbLjiX03LPUfPA9kOHoxrJvfjZsJL5v5MCMfWFgs6y6GdPzpRg+s370PPMtk6w68clnVDCN9WVAz1StUOmXojR7mpd9mBNxQHqfKe1dev2HG0vKF6D0cXK/JRXz5uuQ== 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; 02 Feb 2022 02:13:17 -0000 Received: by ary.qy (Postfix, from userid 501) id 1D965362298F; Tue, 1 Feb 2022 21:13:16 -0500 (EST) Date: 1 Feb 2022 21:13:16 -0500 Message-Id: <20220202021317.1D965362298F@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: vesely@tana.it In-Reply-To: <44a39323-fcc0-c646-7e81-a08effa05b31@tana.it> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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, 02 Feb 2022 02:13:26 -0000 It appears that Alessandro Vesely said: >On Mon 31/Jan/2022 16:46:54 +0100 internet-drafts wrote: >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-as-04 > >Section *Use of SMTP Extensions* is the most noticeable addition. > >I'd question one extension: > > * Enhanced Mail System Status Codes [RFC5248] > >The implementation I use, Courier-MTA, does not implement it. The argument I >heard about not having it is that, in fact, only the first byte of the response >is needed to interoperate. I think you're confusing the three digit status codes like 250 that are at the beginning of a response, and the three part enhanced status codes like 2.1.5 that go at the start of the text portion, e.g. 250 2.1.5 Address accepted >How is that "MUST be supported by SMTP senders and receivers" going to affect >usage practice of that software? Probably not at all. When you asked Sam, what did he say? R's, John xs From nobody Wed Feb 2 01:22:24 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5A23A2AF1 for ; Wed, 2 Feb 2022 01:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=xQOmmcoG; dkim=pass (1152-bit key) header.d=tana.it header.b=C45gweDE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZsVE864QGbm for ; Wed, 2 Feb 2022 01:22:16 -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 04C6A3A2A9F for ; Wed, 2 Feb 2022 01:22:14 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1643793728; bh=hoiy4tXX6TA4tlqJ2TULvf3fD9VGXjfUK26Bk0xpkJY=; h=Subject:To:References:From:Date:In-Reply-To; b=xQOmmcoGoEAZCZiZJdtHtPg/M5RCHYXxjoE9/Ih89LWpCEiNFiaFB1/IY3mo6vUDn 4xGiayW5GXlbscooauCBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1643793728; bh=hoiy4tXX6TA4tlqJ2TULvf3fD9VGXjfUK26Bk0xpkJY=; h=To:References:From:Date:In-Reply-To; b=C45gweDENwd1675X7XbJq2/X9YUDsDVTL7orJBEMG1j8BvmDOBMw4FvSZ0oDHyCod oC7CtmdIf9DsOkVQnQztmMDK8J+mgrb69HyUMhWsC5W1pT8xSm2ghVyBFIlhHpOofz qAqgC5NG4EXScJFkjDEkePfZnzmUsa9WwT9z0HbaaTMW4fQiHZGCuy8qvR2ZG 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 00000000005DC09F.0000000061FA4D40.00001847; Wed, 02 Feb 2022 10:22:08 +0100 To: John Levine , emailcore@ietf.org References: <20220202021317.1D965362298F@ary.qy> From: Alessandro Vesely Message-ID: <8701e4b1-18d3-23aa-4387-267a268b8900@tana.it> Date: Wed, 2 Feb 2022 10:22:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20220202021317.1D965362298F@ary.qy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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, 02 Feb 2022 09:22:23 -0000 On Wed 02/Feb/2022 03:13:16 +0100 John Levine wrote: > It appears that Alessandro Vesely said: >>On Mon 31/Jan/2022 16:46:54 +0100 internet-drafts wrote: >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-as-04 >> >>Section *Use of SMTP Extensions* is the most noticeable addition. >> >>I'd question one extension: >> >> * Enhanced Mail System Status Codes [RFC5248] >> >>The implementation I use, Courier-MTA, does not implement it. The argument I >>heard about not having it is that, in fact, only the first byte of the response >>is needed to interoperate. > > I think you're confusing the three digit status codes like 250 that are at > the beginning of a response, and the three part enhanced status codes like 2.1.5 > that go at the start of the text portion, e.g. > > 250 2.1.5 Address accepted > >>How is that "MUST be supported by SMTP senders and receivers" going to affect >>usage practice of that software? > > Probably not at all. When you asked Sam, what did he say? When the topic appeared on courier-users, he replied as quoted above. That is, saying that of "250 2.1.5 Address accepted" only the leading "2" is needed to interoperate. I'm asking this list about the intended effect of that MUST before notifying Sam. IME, I collect 4xx and 5xx responses from mail logs. Gathering data from 1186 reports, I find 8107 lines with a number after [45]xx response and 2021 with a non-number. So there seems to be a majority of receivers using extended status codes. However, when I glance at those reports I notice better prominent multi-line responses, URLs (since they are colored in the mailed report), and extremely short responses. The enhanced status codes are not much helpful. Are they actually used when gathering data? Best Ale -- From nobody Wed Feb 2 01:28:57 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E453A2B29 for ; Wed, 2 Feb 2022 01:28:56 -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 ZflZEi6Ih72J for ; Wed, 2 Feb 2022 01:28:51 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 39ECD3A2B28 for ; Wed, 2 Feb 2022 01:28:51 -0800 (PST) Received: from smtpclient.apple (unknown [37.228.236.130]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 171709F149 for ; Wed, 2 Feb 2022 01:28:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1643794130; bh=Zacl6IIC+mvXEEjkcWMWsU4w73i5mczcGHmM6kX191I=; h=From:Subject:Date:References:To:In-Reply-To:From; b=ozEke43VUv4euWdHr9UHfc57JWyG2hXnis00cqxnmifNQlQG0QwTUpqnQ9sWw56EY BkcFFiDgNnHnO/6oudA3uUjwdrvSsLhF93W7HWVzu7YQp+csGbKTBCxwOU8Y0o6rca d6F/bGjS/mF+CK0cS/BhqMdN87v7+zFtIVLqPMr0= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_9803D8F0-51C8-48EE-87A0-EBB601E3AB63" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.0.1.1.23\)) Date: Wed, 2 Feb 2022 09:28:48 +0000 References: <20220202021317.1D965362298F@ary.qy> To: emailcore@ietf.org In-Reply-To: <20220202021317.1D965362298F@ary.qy> Message-Id: X-Mailer: Apple Mail (2.3693.0.1.1.23) Archived-At: Subject: Re: [Emailcore] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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, 02 Feb 2022 09:28:56 -0000 --Apple-Mail=_9803D8F0-51C8-48EE-87A0-EBB601E3AB63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just as a FYI: Yahoo is not currently supporting RFC5248 Enhanced Status = Codes. 220 mtaproxy308.free.mail.ne1.yahoo.com ESMTP ready EHLO 250-mtaproxy308.free.mail.ne1.yahoo.com 250-PIPELINING 250-SIZE 41943040 250-8BITMIME 250 STARTTLS laura=20 > On 2 Feb 2022, at 02:13, John Levine wrote: >=20 > It appears that Alessandro Vesely said: >> On Mon 31/Jan/2022 16:46:54 +0100 internet-drafts wrote: >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-emailcore-as-04 >>=20 >> Section *Use of SMTP Extensions* is the most noticeable addition. >>=20 >> I'd question one extension: >>=20 >> * Enhanced Mail System Status Codes [RFC5248] >>=20 >> The implementation I use, Courier-MTA, does not implement it. The = argument I=20 >> heard about not having it is that, in fact, only the first byte of = the response=20 >> is needed to interoperate. >=20 > I think you're confusing the three digit status codes like 250 that = are at > the beginning of a response, and the three part enhanced status codes = like 2.1.5 > that go at the start of the text portion, e.g. >=20 > 250 2.1.5 Address accepted >=20 >> How is that "MUST be supported by SMTP senders and receivers" going = to affect=20 >> usage practice of that software? >=20 > Probably not at all. When you asked Sam, what did he say? >=20 > R's, > John > xs >=20 > --=20 > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore --=20 The Delivery Experts Laura Atkins Word to the Wise laura@wordtothewise.com =09 Email Delivery Blog: http://wordtothewise.com/blog=09 --Apple-Mail=_9803D8F0-51C8-48EE-87A0-EBB601E3AB63 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Just as a FYI: Yahoo is not currently supporting RFC5248 = Enhanced Status Codes.

220 mtaproxy308.free.mail.ne1.yahoo.com ESMTP ready
EHLO
250-mtaproxy308.free.mail.ne1.yahoo.com
250-PIPELINING
250-SIZE = 41943040
250-8BITMIME
250 = STARTTLS

laura 

On 2 Feb 2022, at 02:13, John Levine <johnl@taugh.com> = wrote:

It appears that Alessandro Vesely  <vesely@tana.it> = said:
On Mon = 31/Jan/2022 16:46:54 +0100 internet-drafts wrote:

A diff = from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-emailcore-as-04<= /a>

Section *Use of SMTP = Extensions* is the most noticeable addition.

I'd question one extension:

* =  Enhanced Mail System Status Codes [RFC5248]

The implementation I use, Courier-MTA, does not implement it. =  The argument I
heard about not having it is that, = in fact, only the first byte of the response
is needed to = interoperate.

I think you're = confusing the three digit status codes like 250 that are at
the beginning of a response, and the three part enhanced = status codes like 2.1.5
that go at the start of the text = portion, e.g.

250 2.1.5 Address = accepted

How is that "MUST be supported by SMTP senders and receivers" = going to affect
usage practice of that software?

Probably not at all.  When = you asked Sam, what did he say?

R's,
John
xs

--
Emailcore mailing list
Emailcore@ietf.org
https://www.ietf.org/mailman/listinfo/emailcore

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
laura@wordtothewise.com

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






= --Apple-Mail=_9803D8F0-51C8-48EE-87A0-EBB601E3AB63-- From nobody Wed Feb 2 07:15:44 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3265F3A11B7 for ; Wed, 2 Feb 2022 07:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=WJzImhFA; dkim=pass (2048-bit key) header.d=taugh.com header.b=Al0qG314 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AmbKR6DdEsT for ; Wed, 2 Feb 2022 07:15:37 -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 284333A11B0 for ; Wed, 2 Feb 2022 07:15:29 -0800 (PST) Received: (qmail 66654 invoked from network); 2 Feb 2022 15:15:26 -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=1045c.61faa00e.k2202; bh=lcp2aNC5uI+ZMttPUYA34nsRIdAqNY0Zn2EA7yHArNo=; b=WJzImhFANym+fW73/c2Srh/Z0CnaRdMSFvtYwa8ozFHxk4+rg0NZ/Dq3ukXwhtAn5y73aLnGX2g2QQDdy49z3+VNx8sqHJrkZMqmBtRcr34YIgiuaixMHU2HZd41EZmLDH7xEn54VNVJuv4xKyneKDe4kEw2caX0D4Q6gwr6OAko6T+QaOURAbwlRpddNvg+j38DbqGmUcmwrolulrINP0b6NSxBaTZE/Qd0fck3vD3g6KUnLrEyx2CChb7id5w8v0zkwYA80JNeWiZPBEYRdDIsYqfGBZLxuokZrICnG0htS0qsWpQjn4Fp9RNoMsyfTbovZHVfs5llK40SpOqRjQ== 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=1045c.61faa00e.k2202; bh=lcp2aNC5uI+ZMttPUYA34nsRIdAqNY0Zn2EA7yHArNo=; b=Al0qG314oY/0+r1/6y92KpECtGZPPSqbeZzO2vrHcGDhk1VdwELkMVE02wWuXRMkV0serkgs4cINcQ1hblQxi+x8zSbDWbZrdT3l7lPQ005j+gzuFAhdWetJCW6IpbaLV0QITAXxtaR0QAJbYR0SaohBrXPL3LAzZAAuSIqPPsQwEB5U0NzF7epxxfRxA5nteuMCyBq1HJyUVs+5w1O4hIEXetI2mWj4Fp8Va9BfTKjF83UVtv4OiaomOZc5ptFpqehh53H/gWFIwqntMnpa5kELKMlq0lZgg0LZAaKWc3+15RM2+gVvkFidCXlnNnfPl5HGKS//iOgCYWCeInWQfw== 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; 02 Feb 2022 15:15:26 -0000 Received: by ary.qy (Postfix, from userid 501) id D49D93636DE1; Wed, 2 Feb 2022 10:15:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 435D73636DC2; Wed, 2 Feb 2022 10:15:25 -0500 (EST) Date: 2 Feb 2022 10:15:25 -0500 Message-ID: <6f97d303-d4e7-6c54-7746-ac90d177967d@taugh.com> From: "John R Levine" To: "Alessandro Vesely" , emailcore@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: <8701e4b1-18d3-23aa-4387-267a268b8900@tana.it> References: <20220202021317.1D965362298F@ary.qy> <8701e4b1-18d3-23aa-4387-267a268b8900@tana.it> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Emailcore] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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, 02 Feb 2022 15:15:42 -0000 On Wed, 2 Feb 2022, Alessandro Vesely wrote: > When the topic appeared on courier-users, he replied as quoted above. That > is, saying that of "250 2.1.5 Address accepted" only the leading "2" is > needed to interoperate. He's right. Now I'm scratching my head and wondering what it means to support extended codes. Have some way for servers to add them? Clients Log them on incoming messages? Bulk mailers look at the extended codes trying to tease out every possible hint about why their mail is or isn't getting delivered but in my experience their main use is that when something odd happens, you look at the logs and see if the codes tell you anything surprising. 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 Feb 2 08:39:35 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F062B3A1590 for ; Wed, 2 Feb 2022 08:39:33 -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 XPZ9KDNLytG5 for ; Wed, 2 Feb 2022 08:39:29 -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 A72283A158F for ; Wed, 2 Feb 2022 08:39:28 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nFIfB-000EVh-KV; Wed, 02 Feb 2022 11:39:21 -0500 Date: Wed, 02 Feb 2022 11:39:16 -0500 From: John C Klensin To: Alessandro Vesely cc: John Levine , emailcore@ietf.org Message-ID: <3D56AB62412A1280D8E27CA4@PSB> In-Reply-To: <8701e4b1-18d3-23aa-4387-267a268b8900@tana.it> References: <20220202021317.1D965362298F@ary.qy> <8701e4b1-18d3-23aa-4387-267a268b8900@tana.it> 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] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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, 02 Feb 2022 16:39:34 -0000 --On Wednesday, February 2, 2022 10:22 +0100 Alessandro Vesely wrote: > On Wed 02/Feb/2022 03:13:16 +0100 John Levine wrote: >> It appears that Alessandro Vesely said: >>> On Mon 31/Jan/2022 16:46:54 +0100 internet-drafts wrote: >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-as-04 >>> >>> Section *Use of SMTP Extensions* is the most noticeable >>> addition. >>> >>> I'd question one extension: >>> >>> * Enhanced Mail System Status Codes [RFC5248] >>> >>> The implementation I use, Courier-MTA, does not implement >>> it. The argument I heard about not having it is that, in >>> fact, only the first byte of the response is needed to >>> interoperate. >> >> I think you're confusing the three digit status codes like >> 250 that are at the beginning of a response, and the three >> part enhanced status codes like 2.1.5 that go at the start of >> the text portion, e.g. >> >> 250 2.1.5 Address accepted >> >>> How is that "MUST be supported by SMTP senders and >>> receivers" going to affect usage practice of that software? >> >> Probably not at all. When you asked Sam, what did he say? > > > When the topic appeared on courier-users, he replied as quoted > above. That is, saying that of "250 2.1.5 Address accepted" > only the leading "2" is needed to interoperate. > > I'm asking this list about the intended effect of that MUST > before notifying Sam. > > IME, I collect 4xx and 5xx responses from mail logs. > Gathering data from 1186 reports, I find 8107 lines with a > number after [45]xx response and 2021 with a non-number. So > there seems to be a majority of receivers using extended > status codes. > > However, when I glance at those reports I notice better > prominent multi-line responses, URLs (since they are colored > in the mailed report), and extremely short responses. The > enhanced status codes are not much helpful. Are they actually > used when gathering data? Ale, I think several different things are getting confused in your questions, at least as I understand them. First, those original three-digit status codes, as generated by an SMTP-receiver, were intended to serve three separate purposes: (i) To tell the SMTP-sender whether the message (or its elements) were acceptable for further processing. For that role, "ok", "continue", "try later", and "no, fatal error" is sufficient information and the SMTP-sender paying attention only to the first digit is sufficient. RFC5321 more or less says that and, as usual, if you have suggestions as to how to better explain it, text or specific suggestions would be welcome. Whatever the SMTP-sender might want to do about logging is a largely separate issue, at least until the day that someone writes a spec about what MTAs are required to log and gets it through the system. (ii) Even then, some of the more differentiated information is important if the SMTP-sender chooses to pay attention to it. To take an example from part of a different recent discussion, there really is a difference among {500, 501, 502, 503, 504, 555} and 550: the first group indicates that the server thinks the client messed up and is not following the specs, while 550 represents a specific problem with the address. If I were maintaining SMTP-sender software, I'd certainly want to know about that even though the action I might take on that particular message might still depend only on that first digit. It is probably not a bug if the SMTP-sender ignores that information, but it shows a certain level of indifference and would not be, IMO, good programming practice. (iii) To give the SMTP-sender (which might be a Submission server or even an MUA) sufficient information to deliver meaningful "delivery failed or delayed" information to the sending human. Now SMTP says nothing about those messages and their presentation and the DSN/NDN specs go only a bit further. One of those end systems would be conforming if all 5yz codes were explained to the sending user as "you lose" with no additional information but I would not expect users to be happy about that. I don't know if it was on the minds of Jon or others when RFC 821 was written but, in more recent years, we've found it very helpful to be able to have most of the information in the text rather than depending on delivering the English-language explanatory strings to users, something that 5321 calls out. However, the three-letter codes turned out to be seriously insufficient for the originating system (and/or DSN-generating one) to produce explanations to the user about what went wrong that would contain a satisfactory amount of information and, in "multlingual" contexts, to permit presentation of that information in the user's language. And _that_ is at least part of the reason for the extended status coded. Does software acting as an SMTP-sender need the additional information to figure out what to do? No, and, if it does, we are messed up significantly. Should an SMTP-receiver be supplying the additional information so that whatever those message-origination user see makes sense to them? I certainly hope so... and I think that "SHOULD generate" is entirely sensible if the mail system, as seen by those users, is going to do much better than "you lose". Now, my personal guess is that the proposed text in the A/S could use improvement to explain at least a bit of that. But the recommendation, if interpreted as "SMTP-servers should provide both meaningful three-digit codes and extended codes", is probably correct. On the other hand, one implication of the analysis above if that, if one wanted to split hairs, extended status codes are much more important for failure or delay cases than for successful message transfers so one might limit the SHOULD to those cases... but my guess is that it wouldn't make much difference in practice. john From nobody Wed Feb 2 08:52:19 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576433A15E8 for ; Wed, 2 Feb 2022 08:52: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 k29Y04KL-cJG for ; Wed, 2 Feb 2022 08:52:01 -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 ABDF93A15E4 for ; Wed, 2 Feb 2022 08:52:01 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nFIrP-000Enx-3q; Wed, 02 Feb 2022 11:51:59 -0500 Date: Wed, 02 Feb 2022 11:51:53 -0500 From: John C Klensin To: Laura Atkins , emailcore@ietf.org Message-ID: In-Reply-To: References: <20220202021317.1D965362298F@ary.qy> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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, 02 Feb 2022 16:52:18 -0000 --On Wednesday, February 2, 2022 09:28 +0000 Laura Atkins wrote: > Just as a FYI: Yahoo is not currently supporting RFC5248 > Enhanced Status Codes. > > 220 mtaproxy308.free.mail.ne1.yahoo.com ESMTP ready > EHLO > 250-mtaproxy308.free.mail.ne1.yahoo.com > 250-PIPELINING > 250-SIZE 41943040 > 250-8BITMIME > 250 STARTTLS Laura, This may be an argument for somewhat more differentiation in what the A/S has to say on the subject (and maybe some clarification in 5321bis is needed), but the example above does not provide useful information, because... RFC5321 (and 5321bis) specify the (all lines of the response after the initial one with the domain information) as ehlo-line = ehlo-keyword *( SP ehlo-param ) and the is required to be consistent with the extension name. If that is not clear enough in 5321bis, open a ticket. And, if it is not clear enough in the extended status code specs, at least an erratum, and probably an explicit update from the A/S, would be in order. So, as I read it, no extended reply codes are allowed in the EHLO reply and anything that puts them in is non-conforming. I don't know what Yahoo does, but I think one would have to run a test against commands in a mail transaction to determine whether or not they are available. john From nobody Wed Feb 2 09:07:28 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C033A15DF for ; Wed, 2 Feb 2022 09:07:26 -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 CwjM_kEFalHS for ; Wed, 2 Feb 2022 09:07:24 -0800 (PST) Received: from veps.esmtp.org (veps.esmtp.org [155.138.203.148]) (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 9AAF03A14A8 for ; Wed, 2 Feb 2022 09:07:22 -0800 (PST) Received: from veps.esmtp.org (localhost. [127.0.0.1]) by veps.esmtp.org (MeTA1-1.1.Alpha16.1) with ESMTPS (TLS=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256, verify=OK) id S000000000001D1B000; Wed, 2 Feb 2022 17:07:22 +0000 Received: (from ca@localhost) by veps.esmtp.org (8.16.1/8.12.10.Beta0/Submit) id 212H7Lk5029049 for emailcore@ietf.org; Wed, 2 Feb 2022 17:07:21 GMT Date: Wed, 2 Feb 2022 17:07:21 +0000 From: Claus Assmann To: emailcore@ietf.org Message-ID: <20220202170721.GA74780@veps.esmtp.org> Reply-To: emailcore@ietf.org Mail-Followup-To: emailcore@ietf.org References: <20220202021317.1D965362298F@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Emailcore] ENHANCEDSTATUSCODES (was: Use of SMTP Extensions: ...) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 02 Feb 2022 17:07:27 -0000 On Wed, Feb 02, 2022, John C Klensin wrote: > --On Wednesday, February 2, 2022 09:28 +0000 Laura Atkins > > Just as a FYI: Yahoo is not currently supporting RFC5248 > > Enhanced Status Codes. > > 220 mtaproxy308.free.mail.ne1.yahoo.com ESMTP ready > > EHLO > > 250-mtaproxy308.free.mail.ne1.yahoo.com > > 250-PIPELINING > > 250-SIZE 41943040 > > 250-8BITMIME > > 250 STARTTLS > clarification in 5321bis is needed), but the example above does > not provide useful information, because... Really? Shouldn't 250-ENHANCEDSTATUSCODES be in the list if Enhanced Status Codes were supported? -- Address is valid for this mailing list only, please do not reply to it directly, but to the list. From nobody Wed Feb 2 09:12:00 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5203A1646 for ; Wed, 2 Feb 2022 09:11:47 -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 4ClGo1puVFtO for ; Wed, 2 Feb 2022 09:11:43 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id ECB643A1637 for ; Wed, 2 Feb 2022 09:11:42 -0800 (PST) Received: from smtpclient.apple (unknown [37.228.236.130]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 65A689F149; Wed, 2 Feb 2022 09:11:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1643821902; bh=P+qPdLOvP6TCrTysVHAQtJfhktm/fTdCNUCC4N7Bkyw=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=AFb6K9I7aM7uHG2mQqRmlqOzqvQS6ggoN8W2721YaWjFRZAbCuLsKDYFUomvGSygE e3kmg21nnzNMU7Tc3IjoMIubDcLSl/pymK7GUkkbWxz9tB3ibxxiONb9H0//EHtMjP AhnJXhzH+jLza2ioj2A4Z8nRpBoS638Opj4w0foE= From: Laura Atkins Message-Id: <798F430E-1577-46C3-9615-1AF2396951A4@wordtothewise.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_55745830-47F6-434D-A225-2FC83A73FD39" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.0.1.1.23\)) Date: Wed, 2 Feb 2022 17:11:37 +0000 In-Reply-To: Cc: emailcore@ietf.org To: John C Klensin References: <20220202021317.1D965362298F@ary.qy> X-Mailer: Apple Mail (2.3693.0.1.1.23) Archived-At: Subject: Re: [Emailcore] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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, 02 Feb 2022 17:11:58 -0000 --Apple-Mail=_55745830-47F6-434D-A225-2FC83A73FD39 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 2 Feb 2022, at 16:51, John C Klensin wrote: >=20 >=20 >=20 > --On Wednesday, February 2, 2022 09:28 +0000 Laura Atkins > wrote: >=20 >> Just as a FYI: Yahoo is not currently supporting RFC5248 >> Enhanced Status Codes. >>=20 >> 220 mtaproxy308.free.mail.ne1.yahoo.com ESMTP ready >> EHLO >> 250-mtaproxy308.free.mail.ne1.yahoo.com >> 250-PIPELINING >> 250-SIZE 41943040 >> 250-8BITMIME >> 250 STARTTLS >=20 > Laura, >=20 > This may be an argument for somewhat more differentiation in > what the A/S has to say on the subject (and maybe some > clarification in 5321bis is needed), but the example above does > not provide useful information, because... >=20 > RFC5321 (and 5321bis) specify the (all lines of the > response after the initial one with the domain information) as=20 > ehlo-line =3D ehlo-keyword *( SP ehlo-param ) > and the is required to be consistent with the > extension name. >=20 > If that is not clear enough in 5321bis, open a ticket. And, if > it is not clear enough in the extended status code specs, at > least an erratum, and probably an explicit update from the A/S, > would be in order. >=20 > So, as I read it, no extended reply codes are allowed in the > EHLO reply and anything that puts them in is non-conforming. >=20 > I don't know what Yahoo does, but I think one would have to run > a test against commands in a mail transaction to determine > whether or not they are available. Yahoo is not providing RFC5248 Enhanced Status Codes in their SMTP = service. I use Yahoo specifically as an example of a large provider not = using enhanced SMTP responses in my class for delivery folks who want a = more technical understanding of email.=20 Yahoo isn=E2=80=99t the only MTA not giving out enhanced status codes = when they reject a mail. There are a lot of MTAs that don=E2=80=99t = provide them. Today I was processing logs for a customer. Out of 870 = entries, only 149 of them contain enhanced status codes.=20 In terms of the filters / MTAs involved here:=20 mimecast: 544 office 365: 121 ironport: 26 proofpoint: 19 google apps: 17 Even more that have them but don=E2=80=99t actually follow the spec. = This was from an entry last week:=20 550 5.7.1 Connection refused We could not accept your email because the = message was sent to a non-existent customer/user. These errors should be = treated as an =E2=80=9Cunsubscribe=E2=80=9D by the sender, if a bulk = mailer. User unknown is specifically defined in 5248 and 5.7.1 is not it.=20 I didn=E2=80=99t see any discussion on the list about the wording of = section 2.4. I think, at a minimum, it should be a SHOULD and not a = MUST. I think there should also be some wording about how the enhanced = status codes are to be used. I say this as someone who is doing a lot of = work reading SMTP logs to deal with email delivery issues. Receiving = MTAs are the status codes and enhanced status codes are so all over the = place, I just ignore them and go to the text string to figure out what = they=E2=80=99re trying to tell me.=20 I do understand where Sam is coming from in terms of Courier - the first = number gives you almost all the data you need to handle that transaction = (2, you=E2=80=99re good to go; 4 - stop and come back later; 5 - stop = and don=E2=80=99t come back with this email again). The challenge is = that we=E2=80=99re using SMTP response codes for bulk mail handling (do = you try a new email to this address in the future?) or when we=E2=80=99re = trying to identify a spam block.=20 laura=20 --=20 The Delivery Experts Laura Atkins Word to the Wise laura@wordtothewise.com =09 Email Delivery Blog: http://wordtothewise.com/blog=09 --Apple-Mail=_55745830-47F6-434D-A225-2FC83A73FD39 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 2 Feb 2022, at 16:51, John C Klensin <john-ietf@jck.com> = wrote:



--On Wednesday, February 2, = 2022 09:28 +0000 Laura Atkins
<laura@wordtothewise.com> wrote:

Just as a FYI: Yahoo is = not currently supporting RFC5248
Enhanced Status Codes.

220 mtaproxy308.free.mail.ne1.yahoo.com ESMTP ready
EHLO
250-mtaproxy308.free.mail.ne1.yahoo.com
250-PIPELINING
250-SIZE 41943040
250-8BITMIME
250 = STARTTLS

Laura,

This may be an argument for somewhat more = differentiation in
what the A/S has to say on the subject = (and maybe some
clarification in 5321bis is needed), but = the example above does
not provide useful information, = because...

RFC5321 (and 5321bis) specify = the <ehlo-line> (all lines of the
response after the = initial one with the domain information) as
=   ehlo-line =3D   ehlo-keyword *( SP ehlo-param )
and the <ehlo-keyword> is required to be consistent = with the
extension name.

If = that is not clear enough in 5321bis, open a ticket.  And, if
it is not clear enough in the extended status code specs, = at
least an erratum, and probably an explicit update from = the A/S,
would be in order.

So,= as I read it, no extended reply codes are allowed in the
EHLO reply and anything that puts them in is = non-conforming.

I don't know what Yahoo = does, but I think one would have to run
a test against = commands in a mail transaction to determine
whether or not = they are available.

Yahoo is not providing RFC5248 Enhanced Status = Codes in their SMTP service. I use Yahoo specifically as an example of a = large provider not using enhanced SMTP responses in my class for = delivery folks who want a more technical understanding of = email. 

Yahoo isn=E2=80=99t the = only MTA not giving out enhanced status codes when they reject a mail. = There are a lot of MTAs that don=E2=80=99t provide them. Today I was = processing logs for a customer. Out of 870 entries, only 149 of them = contain enhanced status codes. 

In terms of the filters / MTAs involved = here: 

mimecast:  544
office 365: 121
ironport:  26
proofpoint: 19
google apps:  17

Even more that have them but don=E2=80=99t = actually follow the spec. This was from an entry last = week: 

550 5.7.1 = Connection refused We could not accept your email because the message = was sent to a non-existent customer/user. These errors should be treated = as an =E2=80=9Cunsubscribe=E2=80=9D by the sender, if a bulk = mailer.

User unknown is = specifically defined in 5248 and 5.7.1 is not it. 

I didn=E2=80=99t see any discussion on the list = about the wording of section 2.4. I think, at a minimum, it should be a = SHOULD and not a MUST. I think there should also be some wording about = how the enhanced status codes are to be used. I say this as someone who = is doing a lot of work reading SMTP logs to deal with email delivery = issues. Receiving MTAs are the status codes and enhanced status codes = are so all over the place, I just ignore them and go to the text string = to figure out what they=E2=80=99re trying to tell = me. 

I do understand where Sam = is coming from in terms of Courier - the first number gives you almost = all the data you need to handle that transaction (2, you=E2=80=99re good = to go; 4 - stop and come back later; 5 - stop and don=E2=80=99t come = back with this email again). The challenge is that we=E2=80=99re using = SMTP response codes for bulk mail handling (do you try a new email to = this address in the future?) or when we=E2=80=99re trying to identify a = spam block. 

laura 



-- 
The Delivery Experts

Laura Atkins
Word = to the Wise
laura@wordtothewise.com

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






= --Apple-Mail=_55745830-47F6-434D-A225-2FC83A73FD39-- From nobody Wed Feb 2 10:51:09 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F6A3A1A3F for ; Wed, 2 Feb 2022 10:51:07 -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 fvGY2XKwnSHV for ; Wed, 2 Feb 2022 10:51:02 -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 6CA3E3A1A46 for ; Wed, 2 Feb 2022 10:51:01 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nFKia-000FKr-1t; Wed, 02 Feb 2022 13:51:00 -0500 Date: Wed, 02 Feb 2022 13:50:54 -0500 From: John C Klensin To: Laura Atkins cc: emailcore@ietf.org Message-ID: <63A85DB56EF53CDF75DDC353@PSB> In-Reply-To: <798F430E-1577-46C3-9615-1AF2396951A4@wordtothewise.com> References: <20220202021317.1D965362298F@ary.qy> <798F430E-1577-46C3-9615-1AF2396951A4@wordtothewise.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] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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, 02 Feb 2022 18:51:08 -0000 --On Wednesday, February 2, 2022 17:11 +0000 Laura Atkins wrote: > > >> On 2 Feb 2022, at 16:51, John C Klensin >> wrote: >> >> >> >> --On Wednesday, February 2, 2022 09:28 +0000 Laura Atkins >> wrote: >> >>> Just as a FYI: Yahoo is not currently supporting RFC5248 >>> Enhanced Status Codes. >>> >>> 220 mtaproxy308.free.mail.ne1.yahoo.com ESMTP ready >>> EHLO >>> 250-mtaproxy308.free.mail.ne1.yahoo.com >>> 250-PIPELINING >>> 250-SIZE 41943040 >>> 250-8BITMIME >>> 250 STARTTLS >> >> Laura, >> >> This may be an argument for somewhat more differentiation in >> what the A/S has to say on the subject (and maybe some >> clarification in 5321bis is needed), but the example above >> does not provide useful information, because... >> >> RFC5321 (and 5321bis) specify the (all lines of >> the response after the initial one with the domain >> information) as ehlo-line = ehlo-keyword *( SP ehlo-param ) >> and the is required to be consistent with the >> extension name. >> >> If that is not clear enough in 5321bis, open a ticket. And, >> if it is not clear enough in the extended status code specs, >> at least an erratum, and probably an explicit update from the >> A/S, would be in order. >> >> So, as I read it, no extended reply codes are allowed in the >> EHLO reply and anything that puts them in is non-conforming. >> >> I don't know what Yahoo does, but I think one would have to >> run a test against commands in a mail transaction to determine >> whether or not they are available. > > > Yahoo is not providing RFC5248 Enhanced Status Codes in their > SMTP service. I use Yahoo specifically as an example of a > large provider not using enhanced SMTP responses in my class > for delivery folks who want a more technical understanding of > email. > > Yahoo isn't the only MTA not giving out enhanced status > codes when they reject a mail. There are a lot of MTAs that > don't provide them. Today I was processing logs for a > customer. Out of 870 entries, only 149 of them contain > enhanced status codes. > > In terms of the filters / MTAs involved here: > > mimecast: 544 > office 365: 121 > ironport: 26 > proofpoint: 19 > google apps: 17 > > Even more that have them but don't actually follow the spec. > This was from an entry last week: > > 550 5.7.1 Connection refused We could not accept your email > because the message was sent to a non-existent customer/user. > These errors should be treated as an "unsubscribe" by the > sender, if a bulk mailer. > > User unknown is specifically defined in 5248 and 5.7.1 is not > it. > > I didn't see any discussion on the list about the wording of > section 2.4. I think, at a minimum, it should be a SHOULD and > not a MUST. I think there should also be some wording about > how the enhanced status codes are to be used. I say this as > someone who is doing a lot of work reading SMTP logs to deal > with email delivery issues. Receiving MTAs are the status > codes and enhanced status codes are so all over the place, I > just ignore them and go to the text string to figure out what > they're trying to tell me. > > I do understand where Sam is coming from in terms of Courier - > the first number gives you almost all the data you need to > handle that transaction (2, you're good to go; 4 - stop and > come back later; 5 - stop and don't come back with this > email again). The challenge is that we're using SMTP > response codes for bulk mail handling (do you try a new email > to this address in the future?) or when we're trying to > identify a spam block. Laura, I was not commenting on what Yahoo was doing, only on the example in your note. I am completely confident that your experience and analysis is accurate. That said... I think the A/S probably should say something about enhanced status codes. What it could say (carefully avoiding 2119/8174 terminology for the moment) could be anything from "these seemed like a good idea at the time but they are not being widely enough supported to be useful" to "good idea and anyone not supporting them ought to be explaining their reasons" to "anything not supporting these is as non-conforming to modern Internet email norms as they would be if they were still sending 'HELO'". Which would you pick and why? I do note that at least one of the systems you list has, historically, been notoriously indifferent to what the email standards say. So, at minimum, it is unlikely that anything we do or do not say will change their behavior. And, as I have said about other things, if we make a provision that requires existing implementations to change their behavior, it would be very helpful to explain why we think that change is important, not just lay down a requirement and expect everyone to salute. best, john From nobody Wed Feb 2 11:15:14 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A043A1C8A for ; Wed, 2 Feb 2022 11:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icPVFUQh3OJW for ; Wed, 2 Feb 2022 11:15:07 -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 A2E3E3A1C87 for ; Wed, 2 Feb 2022 11:15:07 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nFL5u-000FOu-7E for emailcore@ietf.org; Wed, 02 Feb 2022 14:15:06 -0500 Date: Wed, 02 Feb 2022 14:15:00 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: <8281208968F8A68A61753E59@PSB> In-Reply-To: <20220202170721.GA74780@veps.esmtp.org> References: <20220202021317.1D965362298F@ary.qy> <20220202170721.GA74780@veps.esmtp.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] ENHANCEDSTATUSCODES (was: Use of SMTP Extensions: ...) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 02 Feb 2022 19:15:12 -0000 --On Wednesday, February 2, 2022 17:07 +0000 Claus Assmann wrote: > On Wed, Feb 02, 2022, John C Klensin wrote: > >> --On Wednesday, February 2, 2022 09:28 +0000 Laura Atkins >> > Just as a FYI: Yahoo is not currently supporting RFC5248 >> > Enhanced Status Codes. > >> > 220 mtaproxy308.free.mail.ne1.yahoo.com ESMTP ready >> > EHLO >> > 250-mtaproxy308.free.mail.ne1.yahoo.com >> > 250-PIPELINING >> > 250-SIZE 41943040 >> > 250-8BITMIME >> > 250 STARTTLS > >> clarification in 5321bis is needed), but the example above >> does not provide useful information, because... > > Really? Shouldn't > 250-ENHANCEDSTATUSCODES > be in the list if Enhanced Status Codes were supported? Maybe. Definitely so if there were a firm requirement that, if enhanced status codes are used, that extension must be advertised and accepted. However, neither RFC 1893 nor RFC 3463 imposes such a requirement (the latter does not even reference RFC 2034). While RFC 2034 specifies the ENHANCEDSTATUSCODES extension, I can find nothing there that _requires_ a server returning such codes to advertise that fact and its Section 5 is very clear that there is no way for the client to insist that such codes be sent or not sent. In addition to the reasons that RFC gives, such requirements would be very tricky given the very flexible language in RFC 5321 about text following the three-digit code (and space or hyphen). So, AFAICT, a server that returned the enhanced codes without advertising that extension would still be conformant to RFC 3463. I won't go as far as to suggest what it "SHOULD" be doing, but I think I stand by my assertion that the only way one can tell reliably whether a server is providing enhanced status codes would be to look at responses within the mail transaction. Probably it would be worth opening a ticket to see if the A/S should clarify that situation and relationship and, if so, in what way. best, john From nobody Wed Feb 2 12:01:19 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534CB3A1EBB for ; Wed, 2 Feb 2022 12:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=uZBeFki4; dkim=pass (2048-bit key) header.d=taugh.com header.b=4rq01VGq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qOaweDMk7e0 for ; Wed, 2 Feb 2022 12:01:05 -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 99AF03A1E3A for ; Wed, 2 Feb 2022 12:00:57 -0800 (PST) Received: (qmail 5068 invoked from network); 2 Feb 2022 20:00:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=13c7.61fae2f7.k2202; bh=XOjek4St2+fgQLybrhxwJsPuVK+1kxmWxn9v+birWJc=; b=uZBeFki4vUpL0N32giY08UjmoNDiE6tKcNf67W45f+EX2nVbcoWE7i9eHE7DUF7V84Ugdkzjga0rTIJlagEvXs5twPwb7gRY2leuFO5wRWSoLWBEKjaTS17l8LpWYGDNSbHOMPd6SQCL1jw/4NypRYEwVAf0/g5oGNGY7h/yG7Wv94J9aYgg0SRrR9Cb0i+4fFQH7FtFuw9Jgr+D3oO3l87odQM1uGF+gB9Se4w/hm4/4Cq3Qw7TOrK20+hqk7eycgP+STMObQk2RJ3S27WYm7yoo1XoJjOWKMREIFyUzDZIWOnTo2Db2un4GDskpk35AcqgtyCxIag55Y/TFc37dg== 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=13c7.61fae2f7.k2202; bh=XOjek4St2+fgQLybrhxwJsPuVK+1kxmWxn9v+birWJc=; b=4rq01VGqJ4TAOLcGSf+naEy3jWcBnPVuA2rSTYx5jT2x+Nh+miTcaRHFJJTwMeqM/NML9/gGHSMNCRbDnYC62Io/TwSZ1FwkRMih3yNxEgkhAx5D3VDzgCy6tvxVjCg+lVXlGNsZ6/0gnduQuMivEV5bMoCfg7bO//ZZDeRfz4cVFIB4FwNFjUYfZ2ZhsZ8bUfWBs2bNlqb4n8r39LppGHGFdSwB0CvtzpkicrXkAHUJybqrMsmJRYIcQyALnfNwqj81NKoq/3xp6K202zIACrqlnb7e+Z1Fa+nW/rf584EgOp+QcLiYSGEqxdzo6dfg/Mygn9o9aZ6v+fH+Za82PQ== 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; 02 Feb 2022 20:00:54 -0000 Received: by ary.qy (Postfix, from userid 501) id 5DF37363A162; Wed, 2 Feb 2022 15:00:53 -0500 (EST) Date: 2 Feb 2022 15:00:53 -0500 Message-Id: <20220202200054.5DF37363A162@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: john-ietf@jck.com In-Reply-To: <63A85DB56EF53CDF75DDC353@PSB> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Enhanced status codes, was Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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, 02 Feb 2022 20:01:18 -0000 It appears that John C Klensin said: >status codes. What it could say (carefully avoiding 2119/8174 >terminology for the moment) could be anything from "these seemed >like a good idea at the time but they are not being widely >enough supported to be useful" to "good idea and anyone not >supporting them ought to be explaining their reasons" to >"anything not supporting these is as non-conforming to modern >Internet email norms as they would be if they were still sending >'HELO'". Which would you pick and why? I'd pick the middle one, implement them unless you have a good reason not to (which might be, our code is a twisty maze with poor documentation, so we're not changing anything we don't have to.) Adding the codes is generally pretty easy, put them in the strings you are already using for the status messages, and they can be useful for diagnosing problems, particularly for people not fluent in the language in which the text messages are written. This is sort of crossing wires, but I would make the advice stronger for submission than for SMTP, since there is more likely to be a live user getting the report back. My opinion about the ENHANCEDSTATUSCODES keyword is considerably more sceptical. The three numbers are either there or they aren't, and I don't see any benefit of an assertion or non-assertion about them which might be wrong. R's, John From nobody Wed Feb 2 13:36:33 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B333A2192 for ; Wed, 2 Feb 2022 13:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_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=9fPVjAnR; dkim=pass (2048-bit key) header.d=wizmail.org header.b=iqHeBbKw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDqNTQr_5GZF for ; Wed, 2 Feb 2022 13:36:27 -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 133AB3A2197 for ; Wed, 2 Feb 2022 13:36:26 -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:From:References:To:Subject:MIME-Version:Date:Message-ID: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=lRWq/NQo6DRKpDYYPFpGSad/z10eG1CRq8AhdH95vrI=; b=9fPVjAnR+VkNOQPdWcfhGwiL+R wXdoZo+1fwVsLsLGSc+TRguS44RzOR7LnYGrej7yOpcefC7q5RRgYyjUENDw==; 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:From: References:To:Subject:MIME-Version:Date:Message-ID: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=lRWq/NQo6DRKpDYYPFpGSad/z10eG1CRq8AhdH95vrI=; b=iqHeBbKwi5n/5BUU7+jH0CU8D6 6K69jHNx+36UrvIo/cVIvO69cki3/XVj9bfC1LIotp1fF0+ppojyGOEdtZ9Z6mZPxzopQKbSU8RYw ClzeeY/GHa/737jt7PkupZXSd7jxSGN0VJ4RJ7jMvdPEyfUpUr47ggy3AcHflM1CFKWfEllkjPoNT +M954KIMsbHHqxewesWDL5z4Xy87e0lNb6XqYg71vz5eAtNPOA04PQp8uZwQxbBHuES3XLxxY12oT r7An1Ol6Ay0JzDJJYQkbW3e6jBLItoHvC8TxR1fIsC5hQTlgqL0Kdh5Y0JrH+xCdvC0Sw+hgtGgyw JtP75cyQ==; 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=[IPV6:2a00:1940:107:1194::1000]) by wizmail.org (Exim 4.95.110) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1nFNIc-001pep-2g for emailcore@ietf.org (return-path ); Wed, 02 Feb 2022 21:36:22 +0000 Message-ID: Date: Wed, 2 Feb 2022 21:36:22 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-GB To: emailcore@ietf.org References: <20220202021317.1D965362298F@ary.qy> From: Jeremy Harris In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=[IPV6:2a00:1940:107:1194::1000]) with esmtpsa Archived-At: Subject: Re: [Emailcore] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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, 02 Feb 2022 21:36:33 -0000 On 02/02/2022 16:51, John C Klensin wrote: > --On Wednesday, February 2, 2022 09:28 +0000 Laura Atkins > wrote: > >> Just as a FYI: Yahoo is not currently supporting RFC5248 >> Enhanced Status Codes. >> >> 220 mtaproxy308.free.mail.ne1.yahoo.com ESMTP ready >> EHLO >> 250-mtaproxy308.free.mail.ne1.yahoo.com >> 250-PIPELINING >> 250-SIZE 41943040 >> 250-8BITMIME >> 250 STARTTLS > > So, as I read it, no extended reply codes are allowed in the > EHLO reply and anything that puts them in is non-conforming. I suspect what Laura is pointing out is the lack of an rfc2034 "ENHANCEDSTATUSCODES" EHLO keyword, not that the EHLO response has/has-not an extended response. -- Cheers, Jeremy From nobody Wed Feb 2 13:37:26 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89ECD3A219F for ; Wed, 2 Feb 2022 13:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_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=vJ6kF7n6; dkim=pass (2048-bit key) header.d=wizmail.org header.b=B45Tb2nC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaMqq3YGj1aK for ; Wed, 2 Feb 2022 13:37:19 -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 7E9743A2197 for ; Wed, 2 Feb 2022 13:37:18 -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:Subject:From:References:To:MIME-Version:Date:Message-ID: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=soT0Mm6axKrOJgQPl86XBnp76kLw3tSAiMcD8gIE7D0=; b=vJ6kF7n6daGRokPtMBmvcWQ3Q1 OG5otpaybDTfCqfmLeAwM062ZN6ZVBlp7NME1xd2qSrxuKDN7duNk6I2TXAA==; 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:Subject: From:References:To:MIME-Version:Date:Message-ID: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=soT0Mm6axKrOJgQPl86XBnp76kLw3tSAiMcD8gIE7D0=; b=B45Tb2nC09ARMp8 CIUwbFea3z4Epg7eTmfzKH5t4o7f+cN+seIkpVcR8zd3oYmBJ4crIGwugVG7sL0wlneT0AE4jzY3q +dZX7nBDOtyVXfMp98QpXHa+SeeQkNKS0DFCTZPl6qTS1VRUeLmTTFKFAxFg3ZGudZiPQvZ3HSB5W 2Vt/6kAMBzG5hPXxOnrjlEtt/wFG/85tU5IAiiU70mKA5xJrRg0JsYLO86eAYOg2581Y/cHzfzn7V FTIo8JBgzSulXAO2OEj6GgjnH8WuXNjpfYacRqF/X+KLsW/PBrWwsf1AJw+Gqk9v+27fMqzgbqLOj 69eWu33qlXIbjPizfgg==; 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=[IPV6:2a00:1940:107:1194::1000]) by wizmail.org (Exim 4.95.110) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1nFNJU-001pg8-0e for emailcore@ietf.org (return-path ); Wed, 02 Feb 2022 21:37:16 +0000 Message-ID: Date: Wed, 2 Feb 2022 21:37:15 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-GB To: emailcore@ietf.org References: <164364401410.15844.7642839719540036536@ietfa.amsl.com> <44a39323-fcc0-c646-7e81-a08effa05b31@tana.it> From: Jeremy Harris In-Reply-To: <44a39323-fcc0-c646-7e81-a08effa05b31@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=[IPV6:2a00:1940:107:1194::1000]) with esmtpsa Archived-At: Subject: Re: [Emailcore] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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, 02 Feb 2022 21:37:25 -0000 On 01/02/2022 17:52, Alessandro Vesely wrote: > I'd question one extension: > >  *  Enhanced Mail System Status Codes [RFC5248] > > > The implementation I use, Courier-MTA, does not implement it. Exim, likewise, takes no notice of RFC 5248 extended codes supplied to it in responses, and generates none (in its hard-coded source; a configuration can supply customised messages and those could include them). And, I think, nobody has ever requested that it do so. Certainly I don't recall a bug recording such. My initial reaction to a standard requiring implementation would likely be "we don't support that standard" (or rfc 2034). -- Cheers, Jeremy From nobody Wed Feb 2 14:12:09 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941C33A230E for ; Wed, 2 Feb 2022 14:12:07 -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 0KYdZhJjkO6g for ; Wed, 2 Feb 2022 14:12:03 -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 3B8EE3A2301 for ; Wed, 2 Feb 2022 14:12:01 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nFNr4-000Fsv-99; Wed, 02 Feb 2022 17:11:58 -0500 Date: Wed, 02 Feb 2022 17:11:52 -0500 From: John C Klensin To: Jeremy Harris , emailcore@ietf.org Message-ID: In-Reply-To: References: <164364401410.15844.7642839719540036536@ietfa.amsl.com> <44a39323-fcc0-c646-7e81-a08effa05b31@tana.it> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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, 02 Feb 2022 22:12:08 -0000 --On Wednesday, February 2, 2022 21:37 +0000 Jeremy Harris wrote: > On 01/02/2022 17:52, Alessandro Vesely wrote: >> I'd=C2=A0question=C2=A0one=C2=A0extension: >>=20 >> = =C2=A0*=C2=A0=C2=A0Enhanced=C2=A0Mail=C2=A0System=C2=A0Status=C2=A0= Codes=C2=A0[RFC5248] >>=20 >>=20 >> The implementation I use, Courier-MTA, does not implement it. = >=20 > Exim, likewise, takes no notice of RFC 5248 extended codes > supplied to it in responses, and generates none (in its > hard-coded > source; a configuration can supply customised messages and > those > could include them). >=20 > And, I think, nobody has ever requested that it do so. > Certainly I don't recall a bug recording such. >=20 > My initial reaction to a standard requiring implementation > would likely be "we don't support that standard" (or rfc = 2034). So, Jeremy, let me ask you a variation on the same question I asked Laura. If the reality is that few significant implementations or email providers are supporting the extended codes and/or the SMTP extension, should the A/S say "this looked like a really good idea but there has been little support in the last quarter-century; implementations MAY support the codes and MAY (or SHOULD ?) support the SMTP extension if they do? And should anyone proposing anything stronger (like a SHOULD or MUST implement) be required to provide a convincing explanation for you, your users, Ale, and the MSPs Laura deals with as to why this is actually important enough that they should press for support? john =20 From nobody Wed Feb 2 14:21:49 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB95E3A231B for ; Wed, 2 Feb 2022 14:21:47 -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 O_oGJj-yuEyf for ; Wed, 2 Feb 2022 14:21:43 -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 2CB263A2324 for ; Wed, 2 Feb 2022 14:21:42 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nFO0T-000Ftz-0W; Wed, 02 Feb 2022 17:21:41 -0500 Date: Wed, 02 Feb 2022 17:21:35 -0500 From: John C Klensin To: John Levine , emailcore@ietf.org Message-ID: In-Reply-To: <20220202200054.5DF37363A162@ary.qy> References: <20220202200054.5DF37363A162@ary.qy> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Enhanced status codes, was Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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, 02 Feb 2022 22:21:48 -0000 --On Wednesday, February 2, 2022 15:00 -0500 John Levine wrote: > It appears that John C Klensin said: >> status codes. What it could say (carefully avoiding 2119/8174 >> terminology for the moment) could be anything from "these >> seemed like a good idea at the time but they are not being >> widely enough supported to be useful" to "good idea and >> anyone not supporting them ought to be explaining their >> reasons" to "anything not supporting these is as >> non-conforming to modern Internet email norms as they would >> be if they were still sending 'HELO'". Which would you pick >> and why? > I'd pick the middle one, implement them unless you have a good > reason not to (which might be, our code is a twisty maze with > poor documentation, so we're not changing anything we don't > have to.) FWIW, me too, but I have very little personal skin it this particular game other than a desire that, since the issues have been brought up, we clarify a bit. > Adding the codes is generally pretty easy, put them in the > strings you are already using for the status messages, and > they can be useful for diagnosing problems, particularly for > people not fluent in the language in which the text messages > are written. > This is sort of crossing wires, but I would make the advice > stronger for submission than for SMTP, since there is more > likely to be a live user getting the report back. Unless these things go into DSNs and NDNs if they are available, in which case there may be live users either way. I would also make it stronger for any SMTP system that had, or expected to have, any significant amount of traffic involving users who are not fluent in English (or, with some qualifications about what conforms, any language in which the text portions of the replies are written). Indeed, I could see a rather strong requirement for the codes when SMTPUTF8 is in use so as to cut down on the translation problems for free text. >... john From nobody Wed Feb 2 14:56:32 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446943A07EB for ; Wed, 2 Feb 2022 14:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_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=qOXUMkYq; dkim=pass (2048-bit key) header.d=wizmail.org header.b=SNOe25i0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2hEoiQPieMo for ; Wed, 2 Feb 2022 14:56:25 -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 E02FE3A07E8 for ; Wed, 2 Feb 2022 14:56:24 -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:Subject:From:References:To:MIME-Version:Date:Message-ID: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=u4QKMu3tSw3ipxpQTTqj0T+ob+KSN0jmUBPjanMPbNU=; b=qOXUMkYqSE2kvQasTIQPFoeUNU 6h+FnHGEHqbRqkWW+u2CPM60LCEeBsQvVDPe71nkIUOMXnT5SJYYajq3C1BQ==; 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:Subject: From:References:To:MIME-Version:Date:Message-ID: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=u4QKMu3tSw3ipxpQTTqj0T+ob+KSN0jmUBPjanMPbNU=; b=SNOe25i0s1i2PKK 2MmPaU6yFum/TBii8u/c8Crs6tTeBkRuNO47ykG/1q2o8uWBokTVJuvaGwYwJ92y864eHQ5Os4927 q9ZE9QwDqGYN+8sWQOXbtocthNVFNVI0cQyc7fx9yDu7LKOkQZNbJwnyTv2XYZg7DkE4R1K0t7dOo S3raWArQl/qaWzF6jVn2g7EtgUr4bZIch+ElfHpOB2j1Oi8B/NyxNTcroR6FmqtySHA2GWpbvrS2c XAFtWmse80BAuGNoYshBEYIojrEp4MOlmFCEGtGsl2Ynfip4VSiUYlOyJuQKTW8anQH4qzAP8Z4Eh xA/fBnGQ8MNykM1kv0w==; 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=[IPV6:2a00:1940:107:1194::1000]) by wizmail.org (Exim 4.95.110) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1nFOY0-001rjK-2W for emailcore@ietf.org (return-path ); Wed, 02 Feb 2022 22:56:20 +0000 Message-ID: Date: Wed, 2 Feb 2022 22:56:19 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-GB To: emailcore@ietf.org References: <164364401410.15844.7642839719540036536@ietfa.amsl.com> <44a39323-fcc0-c646-7e81-a08effa05b31@tana.it> From: Jeremy Harris In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=[IPV6:2a00:1940:107:1194::1000]) with esmtpsa Archived-At: Subject: Re: [Emailcore] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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, 02 Feb 2022 22:56:30 -0000 On 02/02/2022 22:11, John C Klensin wrote: > So, Jeremy, let me ask you a variation on the same question I > asked Laura. If the reality is that few significant > implementations or email providers are supporting the extended > codes and/or the SMTP extension, should the A/S say "this looked > like a really good idea but there has been little support in the > last quarter-century; implementations MAY support the codes and > MAY (or SHOULD ?) support the SMTP extension if they do? If that "few" holds: - saying "MAY support the codes" seems pointless but would do no harm. If present, I'd say some exposition of what support means is needed. - re MAY/SHOULD "support the SMTP extension": I'd assumed the extension was inextricably bound to the use of the codes. I see you pointing out there's no particular logical reason. I'd expect others to be as confused as me by them being disconnected, but I guess if there were a document one could refer to saying that then it's not a long-term disaster. So I'm ambivalent on this one. > And should anyone proposing anything stronger (like a SHOULD or > MUST implement) be required to provide a convincing explanation > for you, your users, Ale, and the MSPs Laura deals with as to > why this is actually important enough that they should press for > support? Yes. -- Cheers, Jeremy From nobody Wed Feb 2 18:50:16 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3478C3A154C for ; Wed, 2 Feb 2022 18:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=RTZIw1Nq; dkim=pass (2048-bit key) header.d=taugh.com header.b=P/u1ca9f Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_4G0NeoULhf for ; Wed, 2 Feb 2022 18:50:08 -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 209413A154E for ; Wed, 2 Feb 2022 18:50:07 -0800 (PST) Received: (qmail 92679 invoked from network); 3 Feb 2022 02:50:05 -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=169fd.61fb42dd.k2202; bh=ugqXqLOYZMgVp67T81iEtfP6fXG5ORj66/SQ44htmX0=; b=RTZIw1Nq2W+2TAV1KX6ZgHNLHNiVqu+6P0CzuI7U3kS8CL4qMpcgqSjk7NmjXbWE/cvu3BTQpfaJWKMk5FPaV33VKQRPcTFnp5WtbxAYWuSr6fa51AT+Wd1JMQJazd+KvRRa1rBfjUHL4AXx2ZmIx4c+WoTl1pUOqXo3IFvLQ7hOhhVVYq15pG0WjH4Y8o6LyjXqG1Fa1Wa5v+N5YEY6kdhyBbFIZG7iXfdnokt4YB6nQofOV6edrKxBjJZuJsGYz7AMgwLOVZr2MUygNTXA2j2QGZwHqxHtRmyrg9RxBg5fAW4w2i9+fMNTfuWkumO9zoz18c3Fu/qVNPVDQMsYlg== 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=169fd.61fb42dd.k2202; bh=ugqXqLOYZMgVp67T81iEtfP6fXG5ORj66/SQ44htmX0=; b=P/u1ca9fk/y46CFgO8X8Bzzdu77DwzOeIG8gfbSRh8RPHfCr1p26GzAOOSoPEREIQxXAE4bHkCtZizvoFwwXCpwsUaet9y0SY2d12p5xZJDrEHfgr3e0WPkrjFFnEXy0Sh6e1XhLWYuj9eomm7+7rxpNk/550KHq/0IIuEg2gO98naUtQVg3QU+BwL72wrmhYFiNCf/3bXFhChr4goCo2qLFJyEItrJjeYrMxtHvPr/ARQ5jns55fQUG16Yz7xYEKoAbuLFgT2JYTEVKlt6jts4EPqXvWnO23TyLEaYsuStnR6U9heTk+uuaMtoWzrzyxILluieE5BKsS7kLFueDsw== 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; 03 Feb 2022 02:50:04 -0000 Received: by ary.qy (Postfix, from userid 501) id 43BF5363EAAF; Wed, 2 Feb 2022 21:50:03 -0500 (EST) Date: 2 Feb 2022 21:50:03 -0500 Message-Id: <20220203025004.43BF5363EAAF@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: john-ietf@jck.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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: Thu, 03 Feb 2022 02:50:13 -0000 It appears that John C Klensin said: >If the reality is that few significant >implementations or email providers are supporting the extended >codes and/or the SMTP extension, ... Big gorillas Google and Microsoft support both the code and the extension. Tucows, who provides white label support for large companies as hostedemail.com does, too. But GMX, which is mail.com and a large European mail operator doesn't. I think Laura's point was that while support is widespread, it is not universal. R's, John From nobody Wed Feb 2 18:55:29 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D017F3A157C for ; Wed, 2 Feb 2022 18:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=PgnVW5ge; dkim=pass (2048-bit key) header.d=taugh.com header.b=z8f9Vvnk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taQP-QM-hgu3 for ; Wed, 2 Feb 2022 18:55:22 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958EC3A1580 for ; Wed, 2 Feb 2022 18:55:21 -0800 (PST) Received: (qmail 94974 invoked from network); 3 Feb 2022 02:55:19 -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=172fb.61fb4417.k2202; bh=if8PO1tra8gq0PBB3xClBHXk4mgtcoiYrUbd59qxcpQ=; b=PgnVW5geZV6gRD8/LNbTBLGnPKCi+nhNFB5gIdGTBguTNVAa+B1DTZmft3l7kuEi/jppalIt4hintnk9XWVNcE9FyveBcbvmCwQudeVLRl5wR8xrYu/qyOKzzCkz8TT7ur7SR0Cym2BhSVKTfFX5LBKSbagba/SdNM/7dm2crMBdb4khbx0LXEpd9/AuxPAHovKHq4K7fdXUzh0JXj2uhjjl47MVjJQlfjYGfvgZlEKv48cVRfmWYUuFIvuyHyS/SxgRCZFsT8dtUy3Ih2SXabifZenFfoPKuuK/OP5lY2dm+0A0qmBU+fxyBgse4Piu/qVKevh9yIfAK8cg+SGL7g== 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=172fb.61fb4417.k2202; bh=if8PO1tra8gq0PBB3xClBHXk4mgtcoiYrUbd59qxcpQ=; b=z8f9VvnkVa51ndDWO+zfYlnzDbod4ZHfPkl4oFll7S4nGFpoKsYRdtKvaWUz79Z+nd7R8j6WISwE/e7sa/QDyg+ugE0PovItue/HKcSZCTpifSiS+18YtocwntC4/FISR50iyQGAI+ESisX3DCyr4MJW5nhYaGVuxiencT9gMuhxOsjnQ+2RCsa5VdvOen+OMO/Nc+JPvHTSzxPF9MdbCB2EfaSzh3EammGuCwOXR/EWfEX11WNsQQ8uAJc34QZVEuqzuizbC7m9oBxzD2UhKapEIDDMLLFnUs3anptyLqn3eW2rwdAIjmu+Rr0z99hpeLXbpg4tc/EK6P8nHjeZdA== 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; 03 Feb 2022 02:55:19 -0000 Received: by ary.qy (Postfix, from userid 501) id 8C859363EB5D; Wed, 2 Feb 2022 21:55:18 -0500 (EST) Date: 2 Feb 2022 21:55:18 -0500 Message-Id: <20220203025518.8C859363EB5D@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: jgh@wizmail.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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: Thu, 03 Feb 2022 02:55:27 -0000 It appears that Jeremy Harris said: >- re MAY/SHOULD "support the SMTP extension": I'd assumed >the extension was inextricably bound to the use of the codes. >I see you pointing out there's no particular logical reason. The codes were defined in RFC 1893 in January 1996, while the SMTP extension was in RFC 2034 in October 1996. Ned Freed wrote the latter document so maybe he remembers what the plan was. R's, John From nobody Thu Feb 3 01:26:01 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDDD3A0A81 for ; Thu, 3 Feb 2022 01:25:59 -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 wS7-sNd7H_bI for ; Thu, 3 Feb 2022 01:25:54 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id B4DCB3A0A80 for ; Thu, 3 Feb 2022 01:25:54 -0800 (PST) Received: from smtpclient.apple (unknown [37.228.236.130]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 9A0869F149; Thu, 3 Feb 2022 01:25:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1643880353; bh=63bJet2ZD75Ex/C4zCybcCEmVnQg1cJrJm3oe6Q7axY=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=HPB3ucLIarLophl5bRaiE9cfMiAuE7MHrcJgMGFGVglxta7J++fTlHVgaU2MWa26A oi4cDMZjEsbgCMwsPmQUbV5BEGT6DhO/jy7A1ZHWpijT6YkCu613elkZM/02jSSmm2 5/Zte9y1wuGG9KDaX1BEibT/l3pyXBnXJcO8XnSk= From: Laura Atkins Message-Id: <3D2E5DAB-22EE-4A35-B37F-7A50CBAD1C31@wordtothewise.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_80D89BDC-1B7B-4DCD-8925-B7D3539322A1" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.0.1.1.23\)) Date: Thu, 3 Feb 2022 09:25:50 +0000 In-Reply-To: <63A85DB56EF53CDF75DDC353@PSB> Cc: emailcore@ietf.org To: John C Klensin References: <20220202021317.1D965362298F@ary.qy> <798F430E-1577-46C3-9615-1AF2396951A4@wordtothewise.com> <63A85DB56EF53CDF75DDC353@PSB> X-Mailer: Apple Mail (2.3693.0.1.1.23) Archived-At: Subject: Re: [Emailcore] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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: Thu, 03 Feb 2022 09:26:00 -0000 --Apple-Mail=_80D89BDC-1B7B-4DCD-8925-B7D3539322A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 =20 >> I didn't see any discussion on the list about the wording of >> section 2.4. I think, at a minimum, it should be a SHOULD and >> not a MUST. I think there should also be some wording about >> how the enhanced status codes are to be used. I say this as >> someone who is doing a lot of work reading SMTP logs to deal >> with email delivery issues. Receiving MTAs are the status >> codes and enhanced status codes are so all over the place, I >> just ignore them and go to the text string to figure out what >> they're trying to tell me.=20 >>=20 >> I do understand where Sam is coming from in terms of Courier - >> the first number gives you almost all the data you need to >> handle that transaction (2, you're good to go; 4 - stop and >> come back later; 5 - stop and don't come back with this >> email again). The challenge is that we're using SMTP >> response codes for bulk mail handling (do you try a new email >> to this address in the future?) or when we're trying to >> identify a spam block.=20 >=20 > Laura, >=20 > I was not commenting on what Yahoo was doing, only on the > example in your note. I am completely confident that your > experience and analysis is accurate.=20 >=20 > That said... >=20 > I think the A/S probably should say something about enhanced > status codes. What it could say (carefully avoiding 2119/8174 > terminology for the moment) could be anything from "these seemed > like a good idea at the time but they are not being widely > enough supported to be useful" to "good idea and anyone not > supporting them ought to be explaining their reasons" to > "anything not supporting these is as non-conforming to modern > Internet email norms as they would be if they were still sending > 'HELO'". Which would you pick and why? Not being widely enough supported to be useful, to be quite honest. = Every system using them picks codes that, to me as an observer, seem to = be random. The choices are often in contradiction to the RFC text. I=E2=80= =99d be thrilled if we could encourage people to correctly report = enhanced codes, but I really think that ship has sailed. =20 > I do note that at least one of the systems you list has, > historically, been notoriously indifferent to what the email > standards say. So, at minimum, it is unlikely that anything we > do or do not say will change their behavior. And, as I have > said about other things, if we make a provision that requires > existing implementations to change their behavior, it would be > very helpful to explain why we think that change is important, > not just lay down a requirement and expect everyone to salute. That was my point as well. If this goes out as is, then we=E2=80=99ve = published a protocol that will be unsupported by the majority of mail = providers. Language added to this newest draft in 2.4 says =E2=80=9CEnhanc= ed status codes MUST be supported=E2=80=9D without any underlying = guidance or justification. If we=E2=80=99re going to endorse using = enhanced codes, I think the language needs to be worked on for that = section.=20 I can take a look at it.=20 laura=20 --=20 The Delivery Experts Laura Atkins Word to the Wise laura@wordtothewise.com =09 Email Delivery Blog: http://wordtothewise.com/blog=09 --Apple-Mail=_80D89BDC-1B7B-4DCD-8925-B7D3539322A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
<snip a bunch of discussion> 

I didn't see any = discussion on the list about the wording of
section 2.4. I = think, at a minimum, it should be a SHOULD and
not a MUST. = I think there should also be some wording about
how the = enhanced status codes are to be used. I say this as
someone = who is doing a lot of work reading SMTP logs to deal
with = email delivery issues. Receiving MTAs are the status
codes = and enhanced status codes are so all over the place, I
just = ignore them and go to the text string to figure out what
they're trying to tell me.

I do = understand where Sam is coming from in terms of Courier -
the first number gives you almost all the data you need to
handle that transaction (2, you're good to go; 4 - stop = and
come back later; 5 - stop and don't come back with = this
email again). The challenge is that we're using = SMTP
response codes for bulk mail handling (do you try a = new email
to this address in the future?) or when we're = trying to
identify a spam block.

Laura,

I was not commenting on what Yahoo was doing, only on the
example in your note.  I am completely confident that = your
experience and analysis is = accurate. 

That = said...

I think the A/S probably should say = something about enhanced
status codes.  What it could = say (carefully avoiding 2119/8174
terminology for the = moment) could be anything from "these seemed
like a good = idea at the time but they are not being widely
enough = supported to be useful" to "good idea and anyone not
supporting them ought to be explaining their reasons" to
"anything not supporting these is as non-conforming to = modern
Internet email norms as they would be if they were = still sending
'HELO'".   Which would you pick = and why?

Not being widely enough supported to be useful, to = be quite honest. Every system using them picks codes that, to me as an = observer, seem to be random. The choices are often in contradiction to = the RFC text. I=E2=80=99d be thrilled if we could encourage people to = correctly report enhanced codes, but I really think that ship has = sailed.  

I do note that at least one = of the systems you list has,
historically, been = notoriously indifferent to what the email
standards say. =  So, at minimum, it is unlikely that anything we
do = or do not say will change their behavior.  And, as I have
said about other things, if we make a provision that = requires
existing implementations to change their = behavior, it would be
very helpful to explain why we think = that change is important,
not just lay down a requirement = and expect everyone to salute.

That was my point as well. If this goes out as is, = then we=E2=80=99ve published a protocol that will be unsupported by the = majority of mail providers. Language added to this newest draft in 2.4 = says =E2=80=9CEnhanced status codes MUST be supported=E2=80=9D without = any underlying guidance or justification. If we=E2=80=99re going to = endorse using enhanced codes, I think the language needs to be worked on = for that section. 

I can take a look at it. 

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
laura@wordtothewise.com

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






= --Apple-Mail=_80D89BDC-1B7B-4DCD-8925-B7D3539322A1-- From nobody Thu Feb 3 01:41:26 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6373A0BAA for ; Thu, 3 Feb 2022 01:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=pL6S4hTr; dkim=pass (1152-bit key) header.d=tana.it header.b=DDfojkQS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVygz310w7LN for ; Thu, 3 Feb 2022 01:41:17 -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 0DB363A0BB8 for ; Thu, 3 Feb 2022 01:41:14 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1643881269; bh=VbnbpLHQ8ASMkrZqtqiuyZHSUoEJBjRU6SMmRUF/uqE=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=pL6S4hTr1MlLfEKoHo7ilghNxwibsPVrfUMVdUp6ZIs66KlD3so+6Q6tO74UDBR2x N/oCZx5NGT7WjscZTjhDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1643881269; bh=VbnbpLHQ8ASMkrZqtqiuyZHSUoEJBjRU6SMmRUF/uqE=; h=Date:To:Cc:References:From:In-Reply-To; b=DDfojkQSP6ugqlkeNZe5fgHOYkZHLqO5R1+oIgfV2CGw8jZk+ZvKn3bh8cdjvUW3B mHhv7cahqclD8RtYcP20LeT5OFJ2JLxvwlpx1h3AfmK01esOcRUs0fknZtOuXYnBbU 2bOltJwSgKRjTVA9nr+TgdsSBo+7TY7ht37YODETAy9EQoXexrHUK0v0cJ8Ft Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Original-Cc: emailcore@ietf.org, John Levine Received: from [192.168.1.108] (host-95-249-175-244.retail.telecomitalia.it [95.249.175.244]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC09F.0000000061FBA335.00001EF3; Thu, 03 Feb 2022 10:41:09 +0100 Message-ID: Date: Thu, 3 Feb 2022 10:41:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: John C Klensin Cc: emailcore@ietf.org, John Levine References: <20220202021317.1D965362298F@ary.qy> <8701e4b1-18d3-23aa-4387-267a268b8900@tana.it> <3D56AB62412A1280D8E27CA4@PSB> From: Alessandro Vesely In-Reply-To: <3D56AB62412A1280D8E27CA4@PSB> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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: Thu, 03 Feb 2022 09:41:24 -0000 On Wed 02/Feb/2022 17:39:16 +0100 John C Klensin wrote: > --On Wednesday, February 2, 2022 10:22 +0100 Alessandro Vesely wrote: >> On Wed 02/Feb/2022 03:13:16 +0100 John Levine wrote: >>> It appears that Alessandro Vesely said: >>>> >>>> I'd question one extension: >>>> >>>> * Enhanced Mail System Status Codes [RFC5248] >>>> >>>> How is that "MUST be supported by SMTP senders and >>>> receivers" going to affect usage practice of that software? >>> >>> Probably not at all. When you asked Sam, what did he say? >> >> When the topic appeared on courier-users, he replied as quoted >> above. That is, saying that of "250 2.1.5 Address accepted" >> only the leading "2" is needed to interoperate. >> >> I'm asking this list about the intended effect of that MUST >> before notifying Sam. >> >> IME, I collect 4xx and 5xx responses from mail logs. >> Gathering data from 1186 reports, I find 8107 lines with a >> number after [45]xx response and 2021 with a non-number. So >> there seems to be a majority of receivers using extended >> status codes. >> >> However, when I glance at those reports I notice better >> prominent multi-line responses, URLs (since they are colored >> in the mailed report), and extremely short responses. The >> enhanced status codes are not much helpful. Are they actually >> used when gathering data? > > Ale, > > I think several different things are getting confused in your > questions, at least as I understand them. > > First, those original three-digit status codes, as generated by > an SMTP-receiver, were intended to serve three separate purposes: > > (i) To tell the SMTP-sender whether the message (or its > elements) were acceptable for further processing. For that > role, "ok", "continue", "try later", and "no, fatal error" is > sufficient information and the SMTP-sender paying attention only > to the first digit is sufficient. RFC5321 more or less says > that and, as usual, if you have suggestions as to how to better > explain it, text or specific suggestions would be welcome. > Whatever the SMTP-sender might want to do about logging is a > largely separate issue, at least until the day that someone > writes a spec about what MTAs are required to log and gets it > through the system. And that works remarkably well. > (ii) Even then, some of the more differentiated information is > important if the SMTP-sender chooses to pay attention to it. > To take an example from part of a different recent discussion, > there really is a difference among {500, 501, 502, 503, 504, > 555} and 550: the first group indicates that the server thinks > the client messed up and is not following the specs, while 550 > represents a specific problem with the address. If I were > maintaining SMTP-sender software, I'd certainly want to know > about that even though the action I might take on that > particular message might still depend only on that first digit. > It is probably not a bug if the SMTP-sender ignores that > information, but it shows a certain level of indifference and > would not be, IMO, good programming practice. As I said, I sort and count unique messages, getting lines like these: 3 421 Offline: HELO/CC 3 421 mcc-ibgw-token.ext.cloudfilter.net cmsmtp Connection refused, too many sessions from 62.94.243.226 AUP#POL 2 550 Mailbox is full / Blocks limit exceeded / Inode limit exceeded 2 550-5.1.1 The email account that you tried to reach does not exist. Please try 550-5.1.1 double-checking the recipient's email address for typos or 550-5.1.1 unnecessary spaces. Learn more at 550 5.1.1 https://support.google.com/mail/?p=NoSuchUser - gsmtp (The /token/ above replaces unmeaningful random data.) The number of mail servers is sufficiently low that collecting a catalogue of all such strings doesn't seem to be a daunting project. IME, most end users only experience misspelled addresses, otherwise they ask for support. I think Laura described well how extended codes are used by mass mailers. In fact, 550 is used for no such user as well as for any policy reason determining not to accept that message. Although careful analysis and comparison to other cases may lead to educated guesses, she says mass mailers use extended status codes. Privacy can be a reason not to produce them. > (iii) To give the SMTP-sender (which might be a Submission > server or even an MUA) sufficient information to deliver > meaningful "delivery failed or delayed" information to the > sending human. Now SMTP says nothing about those messages and > their presentation and the DSN/NDN specs go only a bit further. > One of those end systems would be conforming if all 5yz codes > were explained to the sending user as "you lose" with no > additional information but I would not expect users to be happy > about that. I don't know if it was on the minds of Jon or > others when RFC 821 was written but, in more recent years, we've > found it very helpful to be able to have most of the information > in the text rather than depending on delivering the > English-language explanatory strings to users, something that > 5321 calls out. However, the three-letter codes turned out to > be seriously insufficient for the originating system (and/or > DSN-generating one) to produce explanations to the user about > what went wrong that would contain a satisfactory amount of > information and, in "multlingual" contexts, to permit > presentation of that information in the user's language. And > _that_ is at least part of the reason for the extended status > coded. Does software acting as an SMTP-sender need the > additional information to figure out what to do? No, and, if it > does, we are messed up significantly. Should an SMTP-receiver > be supplying the additional information so that whatever those > message-origination user see makes sense to them? I certainly > hope so... and I think that "SHOULD generate" is entirely > sensible if the mail system, as seen by those users, is going to > do much better than "you lose". Yes, some systems produce very long winded bounce messages (in English). To me they look confusing. I don't know how they are perceived by unaware, naive users. Certainly, the topic of how to present bounces, especially on submission, needs advanced skills, extraneous to SMTP. > Now, my personal guess is that the proposed text in the A/S > could use improvement to explain at least a bit of that. But > the recommendation, if interpreted as "SMTP-servers should > provide both meaningful three-digit codes and extended codes", > is probably correct. On the other hand, one implication of the > analysis above if that, if one wanted to split hairs, extended > status codes are much more important for failure or delay cases > than for successful message transfers so one might limit the > SHOULD to those cases... but my guess is that it wouldn't make > much difference in practice. A MUST sounds excessive. Perhaps even a SHOULD. Best Ale -- From nobody Thu Feb 3 01:56:25 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728123A0CC0 for ; Thu, 3 Feb 2022 01:56:24 -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 SlVM6cdHfecE for ; Thu, 3 Feb 2022 01:56:19 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 899013A0CBC for ; Thu, 3 Feb 2022 01:56:19 -0800 (PST) Received: from smtpclient.apple (unknown [37.228.236.130]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 73BA69F149 for ; Thu, 3 Feb 2022 01:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1643882178; bh=TbSeQ0JqFVasTpWuqe6MZVzDhQFUFCJ88x8+efnW+TU=; h=From:Subject:Date:References:To:In-Reply-To:From; b=e5VafoFsH0jrnNZ1rq7Kx9Npkk96eEGenteqN4DFHClnk5H4ASLQk4wRrZHc+Nk6X YqY7MHXddL8OAFojD1Z9tOlMY2tZXukLsYtq7EmKafh8KWGl7CQlI2F4uUh/N2mRXu b/U0zaNRnWDsQZwO3SaJSRBo1WoL6S3Yr3UHgzeo= From: Laura Atkins Content-Type: multipart/alternative; boundary="Apple-Mail=_52E16E1F-728E-4040-B3F6-353B923F5852" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.0.1.1.23\)) Date: Thu, 3 Feb 2022 09:56:14 +0000 References: <20220202021317.1D965362298F@ary.qy> <8701e4b1-18d3-23aa-4387-267a268b8900@tana.it> <3D56AB62412A1280D8E27CA4@PSB> To: emailcore@ietf.org In-Reply-To: Message-Id: <004790D3-309F-4A0B-A270-9A1449FCD643@wordtothewise.com> X-Mailer: Apple Mail (2.3693.0.1.1.23) Archived-At: Subject: Re: [Emailcore] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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: Thu, 03 Feb 2022 09:56:25 -0000 --Apple-Mail=_52E16E1F-728E-4040-B3F6-353B923F5852 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> (ii) Even then, some of the more differentiated information is >> important if the SMTP-sender chooses to pay attention to it. >> To take an example from part of a different recent discussion, >> there really is a difference among {500, 501, 502, 503, 504, >> 555} and 550: the first group indicates that the server thinks >> the client messed up and is not following the specs, while 550 >> represents a specific problem with the address. If I were >> maintaining SMTP-sender software, I'd certainly want to know >> about that even though the action I might take on that >> particular message might still depend only on that first digit. >> It is probably not a bug if the SMTP-sender ignores that >> information, but it shows a certain level of indifference and >> would not be, IMO, good programming practice. >=20 >=20 > As I said, I sort and count unique messages, getting lines like these: >=20 > 3 421 Offline: HELO/CC > 3 421 mcc-ibgw-token.ext.cloudfilter.net cmsmtp Connection = refused, too many sessions from 62.94.243.226 AUP#POL > 2 550 Mailbox is full / Blocks limit exceeded / Inode limit = exceeded > 2 550-5.1.1 The email account that you tried to reach does not = exist. Please try > 550-5.1.1 double-checking the recipient's email address for = typos or > 550-5.1.1 unnecessary spaces. Learn more at > 550 5.1.1 https://support.google.com/mail/?p=3DNoSuchUser = - gsmtp >=20 > (The /token/ above replaces unmeaningful random data.) >=20 > The number of mail servers is sufficiently low that collecting a = catalogue of all such strings doesn't seem to be a daunting project. That has not been my experience. = https://wordtothewise.com/wp-content/uploads/2019/11/BouncesFrustrationBlo= g-1.png = was something I did for a client who wanted to handle bounces = from three different outbound systems.=20 > IME, most end users only experience misspelled addresses, otherwise = they ask for support. >=20 > I think Laura described well how extended codes are used by mass = mailers. In fact, 550 is used for no such user as well as for any = policy reason determining not to accept that message. Although careful = analysis and comparison to other cases may lead to educated guesses, she = says mass mailers use extended status codes. Privacy can be a reason = not to produce them. I don=E2=80=99t think that is actually what I said.=20 My experience is that the extended status codes aren=E2=80=99t very = useful in terms of handling subscribers.=20 However, in the bulk space we=E2=80=99re overlaying a lot of context = onto rejections that our completely outside of the spec. The RFCs are = about what to do with that message. A lot of the practical usage is what = to do with the next message and how to handle large bulk mail = operations.=20 >> (iii) To give the SMTP-sender (which might be a Submission >> server or even an MUA) sufficient information to deliver >> meaningful "delivery failed or delayed" information to the >> sending human. Now SMTP says nothing about those messages and >> their presentation and the DSN/NDN specs go only a bit further. >> One of those end systems would be conforming if all 5yz codes >> were explained to the sending user as "you lose" with no >> additional information but I would not expect users to be happy >> about that. I don't know if it was on the minds of Jon or >> others when RFC 821 was written but, in more recent years, we've >> found it very helpful to be able to have most of the information >> in the text rather than depending on delivering the >> English-language explanatory strings to users, something that >> 5321 calls out. However, the three-letter codes turned out to >> be seriously insufficient for the originating system (and/or >> DSN-generating one) to produce explanations to the user about >> what went wrong that would contain a satisfactory amount of >> information and, in "multlingual" contexts, to permit >> presentation of that information in the user's language. And >> _that_ is at least part of the reason for the extended status >> coded. Does software acting as an SMTP-sender need the >> additional information to figure out what to do? No, and, if it >> does, we are messed up significantly. Should an SMTP-receiver >> be supplying the additional information so that whatever those >> message-origination user see makes sense to them? I certainly >> hope so... and I think that "SHOULD generate" is entirely >> sensible if the mail system, as seen by those users, is going to >> do much better than "you lose". >=20 > Yes, some systems produce very long winded bounce messages (in = English). To me they look confusing. I don't know how they are = perceived by unaware, naive users. Certainly, the topic of how to = present bounces, especially on submission, needs advanced skills, = extraneous to SMTP. They are long winded, and the often contradict the SMTP and the extended = SMTP codes in use.=20 >> Now, my personal guess is that the proposed text in the A/S >> could use improvement to explain at least a bit of that. But >> the recommendation, if interpreted as "SMTP-servers should >> provide both meaningful three-digit codes and extended codes", >> is probably correct. On the other hand, one implication of the >> analysis above if that, if one wanted to split hairs, extended >> status codes are much more important for failure or delay cases >> than for successful message transfers so one might limit the >> SHOULD to those cases... but my guess is that it wouldn't make >> much difference in practice. >=20 > A MUST sounds excessive. Perhaps even a SHOULD. I agree here.=20 laura=20 --=20 The Delivery Experts Laura Atkins Word to the Wise laura@wordtothewise.com =09 Email Delivery Blog: http://wordtothewise.com/blog=09 --Apple-Mail=_52E16E1F-728E-4040-B3F6-353B923F5852 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
(ii) Even then, some of = the more differentiated information is
important if the = SMTP-sender chooses to pay attention to it.
To take an = example from part of a different recent discussion,
there = really is a difference among {500, 501, 502, 503, 504,
555} = and 550: the first group indicates that the server thinks
the client messed up and is not following the specs, while = 550
represents a specific problem with the address. =  If I were
maintaining SMTP-sender software, I'd = certainly want to know
about that even though the action I = might take on that
particular message might still depend = only on that first digit.
It is probably not a bug if the = SMTP-sender ignores that
information, but it shows a = certain level of indifference and
would not be, IMO, good = programming practice.


As I said, I sort and count unique messages, getting lines = like these:

=      3  421 Offline: HELO/CC
=      3  421 mcc-ibgw-token.ext.cloudfilter.net cmsmtp Connection = refused, too many sessions from 62.94.243.226 AUP#POL
=      2  550 Mailbox is full / Blocks limit = exceeded / Inode limit exceeded
=      2  550-5.1.1 The email account that = you tried to reach does not exist. Please try
=         550-5.1.1 = double-checking the recipient's email address for typos or
=         550-5.1.1 unnecessary = spaces. Learn more at
=         550 5.1.1  https://support.google.com/mail/?p=3DNoSuchUser = <token> - gsmtp

(The /token/ above = replaces unmeaningful random data.)

The = number of mail servers is sufficiently low that collecting a catalogue = of all such strings doesn't seem to be a daunting project.

That has = not been my experience. https://wordtothewise.com/wp-content/uploads/2019/11/BouncesFru= strationBlog-1.png was something I did for a client who wanted = to handle bounces from three different outbound systems. 

IME, most end users only = experience misspelled addresses, otherwise they ask for support.

I think Laura described well how extended = codes are used by mass mailers.  In fact, 550 is used for no such = user as well as for any policy reason determining not to accept that = message.  Although careful analysis and comparison to other cases = may lead to educated guesses, she says mass mailers use extended status = codes.  Privacy can be a reason not to produce them.

I = don=E2=80=99t think that is actually what I said. 

My experience is that the extended status codes = aren=E2=80=99t very useful in terms of handling = subscribers. 

However, in the = bulk space we=E2=80=99re overlaying a lot of context onto rejections = that our completely outside of the spec. The RFCs are about what to do = with that message. A lot of the practical usage is what to do with the = next message and how to handle large bulk mail = operations. 

(iii) To give the SMTP-sender (which might be a Submission
server or even an MUA) sufficient information to deliver
meaningful "delivery failed or delayed" information to the
sending human.  Now SMTP says nothing about those = messages and
their presentation and the DSN/NDN specs go = only a bit further.
One of those end systems would be = conforming if all 5yz codes
were explained to the sending = user as "you lose" with no
additional information but I = would not expect users to be happy
about that. =   I don't know if it was on the minds of Jon or
others when RFC 821 was written but, in more recent years, = we've
found it very helpful to be able to have most of the = information
in the text rather than depending on = delivering the
English-language explanatory strings to = users, something that
5321 calls out. =    However, the three-letter codes turned out to
be seriously insufficient for the originating system = (and/or
DSN-generating one) to produce explanations to the = user about
what went wrong that would contain a = satisfactory amount of
information and, in "multlingual" = contexts, to permit
presentation of that information in = the user's language.  And
_that_ is at least part of = the reason for the extended status
coded.  Does = software acting as an SMTP-sender need the
additional = information to figure out what to do?  No, and, if it
does, we are messed up significantly.  Should an = SMTP-receiver
be supplying the additional information so = that whatever those
message-origination user see makes = sense to them?  I certainly
hope so... and I think = that "SHOULD generate" is entirely
sensible if the mail = system, as seen by those users, is going to
do much better = than "you lose".

Yes, some = systems produce very long winded bounce messages (in English).  To = me they look confusing.  I don't know how they are perceived by = unaware, naive users.  Certainly, the topic of how to present = bounces, especially on submission, needs advanced skills, extraneous to = SMTP.

They are long winded, and the often contradict the = SMTP and the extended SMTP codes in use. 

Now, my personal guess = is that the proposed text in the A/S
could use improvement = to explain at least a bit of that.  But
the = recommendation, if interpreted as "SMTP-servers should
provide both meaningful three-digit codes and extended = codes",
is probably correct.  On the other hand, one = implication of the
analysis above if that, if one wanted = to split hairs, extended
status codes are much more = important for failure or delay cases
than for successful = message transfers so one might limit the
SHOULD to those = cases... but my guess is that it wouldn't make
much = difference in practice.

A MUST = sounds excessive.   Perhaps even a SHOULD.

I = agree here. 

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
laura@wordtothewise.com

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






= --Apple-Mail=_52E16E1F-728E-4040-B3F6-353B923F5852-- From nobody Fri Feb 4 02:27:34 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB9B3A1528 for ; Fri, 4 Feb 2022 02:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=2dGDpAlx; dkim=pass (1152-bit key) header.d=tana.it header.b=C1TwcphW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4f1ri-i2tJf for ; Fri, 4 Feb 2022 02:27:14 -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 204813A14C9 for ; Fri, 4 Feb 2022 02:27:08 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1643970425; bh=N91nC7S32KnxcxImf/cRtE2XL1SsWpvT9EwGfZc8fbQ=; h=Date:Subject:To:References:From:In-Reply-To; b=2dGDpAlxp0oHAd/vuzBEBqmcprktfNDSpWPMl5CzLycU4wzWhbnBKIHuPMOHtzoUp /t4Um29ZNF5yNPBuoawBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1643970425; bh=N91nC7S32KnxcxImf/cRtE2XL1SsWpvT9EwGfZc8fbQ=; h=Date:To:References:From:In-Reply-To; b=C1TwcphWDDItAvLctF+fOuVqszVdosY+7l/qRRWjl98cgT/Dylkx9XXUW1f0xnuSG +z+M/uqpejKjYee/vJcVo7WW8Ekjl5nb5aoMOCnYacNASNy1LV6xQT3U4b2vPh/BhX aUNCBC6k68CWXKnnqU7R8BSB0mOPYHJbmKxgOm5WX7Oj5GQZhveiH+2Rv7DjX Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [192.168.1.108] (host-95-249-175-244.retail.telecomitalia.it [95.249.175.244]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0F6.0000000061FCFF79.00003833; Fri, 04 Feb 2022 11:27:05 +0100 Message-ID: Date: Fri, 4 Feb 2022 11:27:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: emailcore@ietf.org References: <20220202021317.1D965362298F@ary.qy> <8701e4b1-18d3-23aa-4387-267a268b8900@tana.it> <3D56AB62412A1280D8E27CA4@PSB> <004790D3-309F-4A0B-A270-9A1449FCD643@wordtothewise.com> From: Alessandro Vesely In-Reply-To: <004790D3-309F-4A0B-A270-9A1449FCD643@wordtothewise.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Use of SMTP Extensions, was I-D Action: draft-ietf-emailcore-as-04.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: Fri, 04 Feb 2022 10:27:32 -0000 On Thu 03/Feb/2022 10:56:14 +0100 Laura Atkins wrote: > >>> (ii) Even then, some of the more differentiated information is >>> important if the SMTP-sender chooses to pay attention to it. >>> To take an example from part of a different recent discussion, >>> there really is a difference among {500, 501, 502, 503, 504, >>> 555} and 550: the first group indicates that the server thinks >>> the client messed up and is not following the specs, while 550 >>> represents a specific problem with the address. If I were >>> maintaining SMTP-sender software, I'd certainly want to know >>> about that even though the action I might take on that >>> particular message might still depend only on that first digit. >>> It is probably not a bug if the SMTP-sender ignores that >>> information, but it shows a certain level of indifference and >>> would not be, IMO, good programming practice. >> >> As I said, I sort and count unique messages, getting lines like these: >> >> 3 421 Offline: HELO/CC >> 3 421 mcc-ibgw-token.ext.cloudfilter.net cmsmtp Connection refused, too many sessions from 62.94.243.226 AUP#POL >> 2 550 Mailbox is full / Blocks limit exceeded / Inode limit exceeded >> 2 550-5.1.1 The email account that you tried to reach does not exist. Please try >> 550-5.1.1 double-checking the recipient's email address for typos or >> 550-5.1.1 unnecessary spaces. Learn more at >> 550 5.1.1 https://support.google.com/mail/?p=NoSuchUser - gsmtp >> >> (The /token/ above replaces unmeaningful random data.) >> >> The number of mail servers is sufficiently low that collecting a catalogue of all such strings doesn't seem to be a daunting project. > > That has not been my experience. https://wordtothewise.com/wp-content/uploads/2019/11/BouncesFrustrationBlog-1.png was something I did for a client who wanted to handle bounces from three different outbound systems. Nice diagram. I didn't attempt a taxonomy. I just try and eliminate (some) "tokens" as they ruin response aggregation. (What's their usage?) >> IME, most end users only experience misspelled addresses, otherwise they ask for support. >> >> I think Laura described well how extended codes are used by mass mailers. In fact, 550 is used for no such user as well as for any policy reason determining not to accept that message. Although careful analysis and comparison to other cases may lead to educated guesses, she says mass mailers use extended status codes. Privacy can be a reason not to produce them. > > I don’t think that is actually what I said. Sorry, I obviously misread your post. > My experience is that the extended status codes aren’t very useful in terms of handling subscribers. Yes, my conclusion is the same. > However, in the bulk space we’re overlaying a lot of context onto rejections that our completely outside of the spec. The RFCs are about what to do with that message. A lot of the practical usage is what to do with the next message and how to handle large bulk mail operations. The only kind of bulk sending I do is for abuse reports. Since my firewall differentiates offenders whose IPs are managed by a team which has a real abuse mailbox from those who can act without mitigation, I try to detect invalid addresses. In that respect, invalid domain fingers a non-real abuse mailbox, while mailbox full does not. Trying to recognize NDN's (and autoresponder's) templates seems more promising than discriminating mere responses, for that task. The reason I look at bare responses is to spot possible SMTP-sender misconfigurations, which is more or less the reason John K exposes in the quote above. Best Ale -- From nobody Fri Feb 4 11:42:19 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F483A20E9 for ; Fri, 4 Feb 2022 11:42:17 -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 EmoGdX-E0ZlO for ; Fri, 4 Feb 2022 11:42:15 -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 0A2D73A20F3 for ; Fri, 4 Feb 2022 11:42:13 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nG4TC-000KkU-Ll for emailcore@ietf.org; Fri, 04 Feb 2022 14:42:10 -0500 Date: Fri, 04 Feb 2022 14:42:04 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Emailcore] The RDATA of a DNS record with RRTYPE=MX X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 04 Feb 2022 19:42:18 -0000 Hi. I have recently had it drawn to my attention that the rule established as "This can be avoided" in RFC 974, and stated very clearly in RFC 1123, that the domain in the RDATA for an MX record MUST resolve to an address record and not a CNAME is not crystal clear in RFC 5321 or in anything I/we have done so far in 5321bis. The current discussion in Section 2.3.5 of the latter talks about what domain names are allowed to be but is really about domain names in addresses, e.g., MAIL, RCPT and, in principle, EHLO and VRFY, arguments, not in MX targets. It says "For example, a domain may refer to a host alias (label of a CNAME RR) or the label of Mail eXchanger records" I believe we thought that and the surrounding text was clear but it may have been a tad too subtle. To save someone else doing the research I just did, primary host names are explicitly required in domain names used in EHLO commands (See Section 2.3.5 of rfc5321bis). We reviewed the prohibition on CNAMEs in MX RDATA in DRUMS and again in YAM and decided to leave that prohibition unchanged. I hope we do not have to go through that discussion again. Assuming we do not, I propose that, for the avoidance of any doubt, we make things clear by making a small change in the (revised in -09) Section 5.1: Old: When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name that conforms to the specifications of Section 2.3.5. New: When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name that conforms to the specifications of Section 2.3.5. That domain name also MUST resolve to a primary host name, i.e., it is not allowed to be an alias. If anyone has strong objections to that change (which, again, is a clarification, not a substantive change to what SMTP allows), please speak up and explain your reasons. john From nobody Fri Feb 4 12:26:04 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C5C3A2221 for ; Fri, 4 Feb 2022 12:26:02 -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 7etgqc6U4s2E for ; Fri, 4 Feb 2022 12:25:57 -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 246893A2220 for ; Fri, 4 Feb 2022 12:25:56 -0800 (PST) Received: by rorschach.hjp.at (Postfix, from userid 1000) id CA88A63D8; Fri, 4 Feb 2022 21:25:52 +0100 (CET) Date: Fri, 4 Feb 2022 21:25:52 +0100 From: "Peter J. Holzer" To: emailcore@ietf.org Message-ID: <20220204202552.7xygqwpobyl7nfgm@hjp.at> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zfmwpyiqrjwsovhs" Content-Disposition: inline In-Reply-To: Autocrypt: addr=hjp@hjp.at; prefer-encrypt=mutual; keydata= mDMEYZAfcBYJKwYBBAHaRw8BAQdAXKDp3VtUDNCoavz8e64LY57nUgLb87BIWKKVeiYyrKG0Cmh qcEBoanAuYXSIkAQTFggAOBYhBGlL9LrG4q2XPF4D32wA7r0ipP8fBQJhkB9wAhsDBQsJCAcCBh UKCQgLAgQWAgMBAh4BAheAAAoJEGwA7r0ipP8fSrgBAO0eJbb9Mm9wQ7a3/h6yGdb3wf2tN5V3R 9ZHBFU3lKdSAQDHmNxTvO4MWk0nn3Glmv02Ee0u6pZheZ7zAOszklwAC7g4BGGQH3ASCisGAQQB l1UBBQEBB0ArGG3CcWNFMfqtBJP6NQX6XRoOdJNyrI7lj2a1S07HdgMBCAeIeAQYFggAIBYhBGl L9LrG4q2XPF4D32wA7r0ipP8fBQJhkB9wAhsMAAoJEGwA7r0ipP8fEf4A/3hc6JbvSGyXV9HMi5 NpXKQSqQeVReugknyhEM4xMd4mAP9mjwJArc3ZAyV33xKpnQ+TKUdshYrhjo3xPZWiaK4MAQ== Archived-At: Subject: Re: [Emailcore] The RDATA of a DNS record with RRTYPE=MX X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 04 Feb 2022 20:26:02 -0000 --zfmwpyiqrjwsovhs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2022-02-04 14:42:04 -0500, John C Klensin wrote: > New: > When a domain name associated with an MX RR is looked up > and the associated data field obtained, the data field > of that response MUST contain a domain name that > conforms to the specifications of Section 2.3.5. That > domain name also MUST resolve to a primary host name, > i.e., it is not allowed to be an alias. I would prefer "... also MUST be a primary host name ..." as in the penultimate paragraph of section 2.3.5. "Resolve to a primary host name" for me implies that a DNS lookup would be necessary to get the primary host name. hp --=20 _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" --zfmwpyiqrjwsovhs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmH9i8sACgkQ8g5IURL+ KF3l8xAAjv18ClSYsSieuZFpiy78u5wox7XDeFljwIjF3WcMjVY2MwocEGajbnkj x5NtruaWymnfeWddEJueMO/7C24AJNWv3rqzmjQIMkXQtAUthHnrHSMAFkjRt3Kf APenXO7UUGCnixZFbroYQnGBl5QoU/I+mq0pR/zXcDbip36ZDW5tWBcV4+O3ruMi dLuoj2GyZWcCH26oGgXqbY7rfUT9hSNCC5ztDps3uANXbzPJTwf6JmXAZlpGYcuj +imaqOFGb73jyQua9Cv+vDlVU0PAgtMcdnXRUM3c1eXE+h/iaD54e4s9FwffpqcS +w4ynHbZ/V6HRgDoqiBEOZ9jdRE4+BiE5Yw4aexlfGlVrsJYCO9U4kVqBkN+bOUz rFxBJqM5yPt+oMefx/oBIATGl2h6Xz1BdJ0c71Iyo/W+ETJaeqkBsUloZiX6Joy+ YeYuNE0RN1WglO0hDX+ri4Ks6eTrbn6NlTL5f6VS4vUyGD5Y7TUGBXaT8tpnbxh0 6fSKuRtx7g1YjBKXHRDhqahk+ssbFhPGdRmqnZHYHjKAVhnITN95y2XKkgq0+N9E Qyh8LvB4bSiP0NNzm4qr7CfRS/+L4Wi0yCVcLH+peLYmnbmJX2Uz0DNRkuEgE88J gL21c5rnl+TZQ5erqok32MnxV/IMPAfT+Eu2EwLJifB+YGVqhGg= =xHga -----END PGP SIGNATURE----- --zfmwpyiqrjwsovhs-- From nobody Fri Feb 4 13:07:54 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD8D3A2363 for ; Fri, 4 Feb 2022 13:07:52 -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 ZhHuuLpFGoTO for ; Fri, 4 Feb 2022 13:07: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 DC8253A235E for ; Fri, 4 Feb 2022 13:07:44 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nG5nx-000KqO-Er; Fri, 04 Feb 2022 16:07:41 -0500 Date: Fri, 04 Feb 2022 16:07:35 -0500 From: John C Klensin To: "Peter J. Holzer" , emailcore@ietf.org Message-ID: In-Reply-To: <20220204202552.7xygqwpobyl7nfgm@hjp.at> References: <20220204202552.7xygqwpobyl7nfgm@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] The RDATA of a DNS record with RRTYPE=MX X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 04 Feb 2022 21:07:53 -0000 --On Friday, February 4, 2022 21:25 +0100 "Peter J. Holzer" wrote: > On 2022-02-04 14:42:04 -0500, John C Klensin wrote: >> New: >> When a domain name associated with an MX RR is looked up >> and the associated data field obtained, the data field >> of that response MUST contain a domain name that >> conforms to the specifications of Section 2.3.5. That >> domain name also MUST resolve to a primary host name, >> i.e., it is not allowed to be an alias. > > I would prefer "... also MUST be a primary host name ..." as > in the penultimate paragraph of section 2.3.5. > > "Resolve to a primary host name" for me implies that a DNS > lookup would be necessary to get the primary host name. Definite improvement. Thanks. However, I had not read the subsequent paragraph (the one starting "When a domain name associated...") closely enough (this is why I ask the WG before making this sort of change). It already asks that the domain name be queried (the DNS lookup to which you object) and then handwaves the CNAME issue ("Any other response, specifically including a value that will return a CNAME record when queried, lies outside the scope of this Standard." and then points to RFC 2181. I don't know whether the several updates to 2181 clouds that advice. More important, continuing to reference it from 5321bis will take us into downref territory. So, I'm not going to try to write text right now and would appreciate input and advice from you and others. However, given recent pushback on another spec that said "MUST do this but, if you don't then...", I'm inclined to see if we can clean things up considerably. In particular, if "MUST be a primary host name" is good enough, I wonder if we can eliminate most or all of that subsequent paragraph rather than dragging things out. thanks, john From nobody Sat Feb 5 20:14:02 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819EB3A2068 for ; Sat, 5 Feb 2022 20:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=a3vmdiB2; dkim=pass (2048-bit key) header.d=taugh.com header.b=O6iXCcM+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ywy3H7ORMDL4 for ; Sat, 5 Feb 2022 20:13:55 -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 6DD323A2013 for ; Sat, 5 Feb 2022 20:13:55 -0800 (PST) Received: (qmail 78522 invoked from network); 6 Feb 2022 04:13:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type; s=132b6.61ff4b01.k2202; bh=tXjD9Uy0MtQjqTuHzWfnkNWX7I50lH6imBsN8lROzLw=; b=a3vmdiB21OiU4Bs9I9i92KaUPPVV972mj4Fyw5qK/ieGKAn0OL2az4rRdGzjyjV50mB9eg1CUpcl4xFakgd6QGFlE7lx3Hy/yF2KXIQhw9aJHV+cIJafzx7VOBnmuOEDaiEXhu5F+3XNWsmE4Uai1GKqRHkVHIkGMRypBSVQDRkjniUImA4r1khRZC8WjeiF1EYhPIrfelZybAr4vPsmhJioXDJZVEcaqLv0DVYpHlRH8JVDTbIvHdwOW3dAe8nw5YlmQ5NzaqsxqVIl5tObPmeW00sOfou6DroNZExpsATmUbjbp3d9D0HKfcuJt0l9B1wfKFE6aRBaLEGHxiADyw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type; s=132b6.61ff4b01.k2202; bh=tXjD9Uy0MtQjqTuHzWfnkNWX7I50lH6imBsN8lROzLw=; b=O6iXCcM+Muw/gL0hjs1WEzsMlgFxGSKnLCcxe39rRlk15r+WHTKHmsBWqO+0CeP5XvPcsNGNH3ywI85hIRlecTZK5I4SNBS4pQp3lOjwHG7wyYE8Ayz+2vEi0VBLpFS+md8DOUL9zrQAA2Y0skV8YVwOrXhS7HIL1vLwCOuWzUaDwMFQhNrEBOc5P8KgzXDyjh4iGg6gNVUqTVg85v9pafSyyqwRp0PDRPn4wXmZwpYnkPGRO0aZ/IkSPAtHHlDk6FYDfadI61XNL+UUuChYtiqVNtg4xr4VgvhtlEkQaL4I1rjjbkJ75YMvmsyD/C+jVrC4Y68nTKUjE3ytsgnKug== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 06 Feb 2022 04:13:52 -0000 Received: by ary.qy (Postfix, from userid 501) id 3340B366102F; Sat, 5 Feb 2022 23:13:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 968473661011 for ; Sat, 5 Feb 2022 23:13:51 -0500 (EST) Date: 5 Feb 2022 23:13:51 -0500 Message-ID: <3bfc25ff-b074-0894-f28d-fc24864b22f8@taugh.com> From: "John R Levine" To: emailcore@ietf.org X-X-Sender: johnl@ary.qy MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [Emailcore] Comments on -09 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2022 04:14:01 -0000 In 2.4: A few SMTP servers, in violation of this specification (and RFC 821) require that command verbs be encoded by clients in upper case. Implementations MAY wish to employ this encoding to accommodate those servers. Is this still true? It seems harmless but I cannot recall seeing an MTA that cared about command case in this millenium. In 3.3: Restricted-capability clients MUST NOT assume that any SMTP server on the Internet can be used as their mail processing (relaying) site. I would take that out. I assume that what it meant by restricted-capability is what we now call submission. In 3.4.2: Now that I look at it again, I'm inclined to rip out almost the entire section and just say (perhaps as part of 3.4.1) that it is possible to forward one address to several, known as expanding or exploding, and that broadcast and discussion lists are typically managed by mailing list software that is beyond the scope of this spec. The A/S can say something about when you change the bounce address while forwarding, with the advice that the goal is to get the bounces to someone or something that can act on them. In 3.6.1: A relay SMTP server is usually the target of a DNS MX record that designates it, rather than the final delivery system. I can't tell whether this is talking about a secondary MX or a large mail provider which uses separate gateway and delivery servers or what. In 4.2.4.2 on Null MX: If, despite publishing the DNS entry, the server domain chooses to respond on the SMTP port, it SHOULD respond with the 556 code as well. If I publish a null MX, what could have an SMTP port? The DNS root doesn't have an A record. The only part of 7505 not covered here is the enhanced codes to use, not sure what to do about that. In 4.5.1: Does it still make sense to include VRFY in the minimal list of commands? Nobody responds with anything other than 252 (or 502 if you're Yahoo) any more. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Feb 6 02:22:59 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E79A3A167A for ; Sun, 6 Feb 2022 02:22:45 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=HIo+7okX; dkim=pass (1152-bit key) header.d=tana.it header.b=BdlYRtyD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9t8q-hZnOAtD for ; Sun, 6 Feb 2022 02:22:37 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 167C33A22FD for ; Sun, 6 Feb 2022 02:22:34 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1644142948; bh=dilBbjdE65SMDN9I24TaSKTfLEOP8khs2H+xG+T+TVc=; h=Date:Subject:To:References:From:In-Reply-To; b=HIo+7okXomujfd06NEl89lg1vOBQ5rPUJBTAm4h+Df6EBjKEhjGYht71UoAVL8N+c WhyaBiz8g1uUufnISrhDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1644142948; bh=dilBbjdE65SMDN9I24TaSKTfLEOP8khs2H+xG+T+TVc=; h=Date:To:References:From:In-Reply-To; b=BdlYRtyDI9MRW8qZ4Puxa1h6PqkgZRWeNMAtFfccuXX3xSrES8puI9H9w+m+D/Jmh Xv8r6acue8X+MFv4s/8lQjA7VyQndP2aD+vsVMqhv1BFBRbaAxwwWivWr2gV9Kwah9 OkJYzXHr6wUQFirrMwZ1bhMusESleM3NnBhXGtbMeZJ8YhO0SsD4IwrncJAlH Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [192.168.1.108] (host-95-249-175-244.retail.telecomitalia.it [95.249.175.244]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC09F.0000000061FFA163.00001D88; Sun, 06 Feb 2022 11:22:27 +0100 Message-ID: <26186a20-5189-fd98-91c8-5aaf41a8763d@tana.it> Date: Sun, 6 Feb 2022 11:22:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: John R Levine , emailcore@ietf.org References: <3bfc25ff-b074-0894-f28d-fc24864b22f8@taugh.com> From: Alessandro Vesely In-Reply-To: <3bfc25ff-b074-0894-f28d-fc24864b22f8@taugh.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] Aliases and Mailing Lists, was Comments on -09 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2022 10:22:46 -0000 Hi, On Sun 06/Feb/2022 05:13:51 +0100 John Levine wrote: > In 3.4.2: > > Now that I look at it again, I'm inclined to rip out almost the entire > section and just say (perhaps as part of 3.4.1) that it is possible to > forward one address to several, known as expanding or exploding, and > that broadcast and discussion lists are typically managed by mailing > list software that is beyond the scope of this spec. I think a distinction between /internal/ aliasing and forwarding to the public Internet can be worth. > The A/S can say something about when you change the bounce address > while forwarding, with the advice that the goal is to get the bounces > to someone or something that can act on them. Agreed, except that this actionability advice is such an important principle that deserves being published in 5321bis. Rather than developing a minimal taxonomy of forwarding cases, the spec could state important principles like the above, which govern envelope data, and just mention some of the possible semantics of forwarding that determine their different handling. For example, role aliases, secret addresses, vanity addresses, trash addresses, as well as discussion lists, newsletters, graymail and spam. Best Ale -- From nobody Sun Feb 6 04:58:09 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893F13A003C for ; Sun, 6 Feb 2022 04:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.811 X-Spam-Level: X-Spam-Status: No, score=-7.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_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=7JbA4qID; dkim=pass (2048-bit key) header.d=wizmail.org header.b=rO8kXhvv Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tOtTxvxm_N5 for ; Sun, 6 Feb 2022 04:58:02 -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 CF74F3A0033 for ; Sun, 6 Feb 2022 04:58:01 -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:From:References:To:Subject:MIME-Version:Date:Message-ID: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=e293v2dQ8bqqimY+XL//FNMMMKd9KrzjDYlcuIHyM6g=; b=7JbA4qIDiOJuGzuUwoSn2IsNEF uYTEPdC+ef6wZMGdUTgiHMrLgOZSmcdtduu3DmbbBG3BiXcjVxy6ytpW3dAw==; 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:From: References:To:Subject:MIME-Version:Date:Message-ID: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=e293v2dQ8bqqimY+XL//FNMMMKd9KrzjDYlcuIHyM6g=; b=rO8kXhvvKxRr5eGIZa/s7OgnLL 4y5XHV3yC42m71Xrq/QqzPRD7RbAbaAPhNjgC1erIe1YQ0LQD2CCveUCspLgv2oioMLtjVHiMeGAt erJMHE9LLOPyhdkZ9FsTKolLqIx8y9L57C41sRkzqjGmpCRVDTajNb0smpdFy/Kipi0BgQ9U9w/iy ZGqCrrydsPkVMp47iSibmRWYfltICg4Fv1DORuQ6jmqHPnRubvvzdUrntCsVt9miJXiiEN1GPDoUS IvzM9PxOubfAamljFXpfUJg4zNhUMJSu6TmrTiNJAouLznfM2xwrEJfOKk+htZy+Dw6ovC0nSshw5 OQZAIejQ==; 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=[IPV6:2a00:1940:107:1194::1000]) by wizmail.org (Exim 4.95.110) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1nGh77-003lf9-0U for emailcore@ietf.org (return-path ); Sun, 06 Feb 2022 12:57:57 +0000 Message-ID: <943ab66a-174c-a90b-33b3-0619bbd78cc6@wizmail.org> Date: Sun, 6 Feb 2022 12:57:55 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-GB To: emailcore@ietf.org References: <3bfc25ff-b074-0894-f28d-fc24864b22f8@taugh.com> From: Jeremy Harris In-Reply-To: <3bfc25ff-b074-0894-f28d-fc24864b22f8@taugh.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=[IPV6:2a00:1940:107:1194::1000]) with esmtpsa Archived-At: Subject: Re: [Emailcore] Comments on -09 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2022 12:58:08 -0000 On 06/02/2022 04:13, John R Levine wrote: > In 4.2.4.2 on Null MX: > >     If, despite publishing >     the DNS entry, the server domain chooses to respond on the SMTP port, >     it SHOULD respond with the 556 code as well. > > If I publish a null MX, what could have an SMTP port?  The DNS root doesn't have an A record. My guess is that it's handling the situation of a sending MTA spotting the null MX explicitly, ignoring it, and proceeding to try the A for the domain. Or never looking for an MX. -- Cheers, Jeremy From nobody Sun Feb 6 08:05:25 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A553A09B5 for ; Sun, 6 Feb 2022 08:05:23 -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 806Bd87wbDAd for ; Sun, 6 Feb 2022 08:05:18 -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 1CA693A09AB for ; Sun, 6 Feb 2022 08:05:15 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nGk2F-000Olu-Bu; Sun, 06 Feb 2022 11:05:07 -0500 Date: Sun, 06 Feb 2022 11:05:01 -0500 From: John C Klensin To: Jeremy Harris , John R Levine , emailcore@ietf.org Message-ID: <7A262F8E67B3CDA8D7A7F136@PSB> In-Reply-To: <943ab66a-174c-a90b-33b3-0619bbd78cc6@wizmail.org> References: <3bfc25ff-b074-0894-f28d-fc24864b22f8@taugh.com> <943ab66a-174c-a90b-33b3-0619bbd78cc6@wizmail.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Comments on -09 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2022 16:05:24 -0000 --On Sunday, February 6, 2022 12:57 +0000 Jeremy Harris wrote: > On 06/02/2022 04:13, John R Levine wrote: >> In=C2=A04.2.4.2=C2=A0on=C2=A0Null=C2=A0MX: >>=20 >> =C2=A0=C2=A0=C2=A0=C2=A0If,=C2=A0despite=C2=A0publishing >> = =C2=A0=C2=A0=C2=A0=C2=A0the=C2=A0DNS=C2=A0entry,=C2=A0the=C2=A0se= rver=C2=A0domain=C2=A0chooses=C2=A0to=C2=A0 >> respond=C2=A0on=C2=A0the=C2=A0SMTP=C2=A0port, >> = =C2=A0=C2=A0=C2=A0=C2=A0it=C2=A0SHOULD=C2=A0respond=C2=A0with=C2=A0= the=C2=A0556=C2=A0code=C2=A0as=C2=A0well. >>=20 >> If I publish a null MX, what could have an SMTP port?=C2=A0 = The >> DNS root doesn't have an A record. >=20 > My guess is that it's handling the situation of a sending MTA > spotting the null MX explicitly, ignoring it, and proceeding > to try the A for the domain. >=20 > Or never looking for an MX. John, Yes. Look at it from the standpoint of a server that is being extra-cautious and whose implementers assume that support for null MX in clients is not [yet] universal. So, consider two possible cases... (1) Client is not only pre-RFC 7505 but pre-RFC 974, e.g., some embedded thing that has not been updated to understand MX records at all, much less conformance to 5321bis. (I hope there are few, if any, of those left.) =20 (2) Client author has not read 7505, does a DNS lookup, finds a null MX which its considers bogus, and, instead of paying attention to "If MX records are present, but none of them are usable, this situation MUST be reported as an error."=20 which dates from RFC 2821 (at least) and, instead, goes looking for an address RR. Now, there is no question in either case that the client is non-conforming. However, for better or worse, there is a long tradition of SMTP receivers trying to figure out what is going on with non-conforming SMTP senders and trying to get messages through if at all possible. My understanding of Jeremy's reading of the situation (with which, fwiw, I agree) says being able to respond on port 25 and quickly reply with a "5yz" code is better than the alternatives. And I note, in that regard, that I can find nothing in RFC 7505 that prohibits advertising null MX but still responding to port 25. Interestingly, even if we imposed such a rule in 5321bis, the "operational requirements" text of Section 7.8 would still allow a server to have that port available. john =20 From nobody Sun Feb 6 09:31:05 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F343A0AAB for ; Sun, 6 Feb 2022 09:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=L3qTD+pn; dkim=pass (2048-bit key) header.d=taugh.com header.b=HUHsgBER Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rl51g6OCCmw1 for ; Sun, 6 Feb 2022 09:30:57 -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 D19E63A0AAC for ; Sun, 6 Feb 2022 09:30:56 -0800 (PST) Received: (qmail 45093 invoked from network); 6 Feb 2022 17:30:53 -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=b023.620005cd.k2202; bh=2TfQ6ciKHC/C8bQFq2dzvY1Zz720Z3JdCODb2YijxFI=; b=L3qTD+pnFf8WF+XixNVWKi0+pK8SDbhnTDZ8S4RWQ+gxgt7O4Q1G2ucnqGBsp6dW9GAQbCtWjtrfCOJGFY9bAezXOF91GC8a0+CvHEk4HaBoF94kTxTFePhMCtN3P557plT8h/sGQGI1xj7zuDeQ/DqR9FLMWaOqFFB3NIwj+CykBjA3mk7UZtJ2z2aN2RyWZhTpmtHjkA4caX/pkYDGEgnYL1kUoBA8ZT7aP2FiRwY6XAOP9dke63v/m3VJf8zdEMJZUaLuZybNQjYuy+xMt9gwK3a3v47mxO3D8PXykT5C5Hj7vp8rt4u+/7tqjbrKi+w5gZnchreQRBA+X6bEeQ== 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=b023.620005cd.k2202; bh=2TfQ6ciKHC/C8bQFq2dzvY1Zz720Z3JdCODb2YijxFI=; b=HUHsgBERzNOd1Es6xq9mPXucMZlBHCCIyiGEwqCJ29i4zUfyxsSZXRgtK80/Tdteeq6QIzUGi3z0BYM1c5Vv87W8qbGXfqvYchLTuF9BcCNv2m/VgTy1oboXbjXilDBhZmasFico+fWDgNCofgYeSU01xSaaluiiPp2co+BxubZtRLWd3QcwEDw9gRo6rJxvptj7e+UbFNglS7fyX+IMJuPomfMLdmt1DF+fLeXkNrJXsFvSJD3kPXN9bCiKZPnwghGiWX6Ys48dzTNZ5gssrBjCcR2Egpob9mBSU6e0kOW7yzqcd4p3OUb9sdeSb44p+SQ1RIXdDL5fLsMyeFEK1g== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 06 Feb 2022 17:30:52 -0000 Received: by ary.qy (Postfix, from userid 501) id 3C3123665D79; Sun, 6 Feb 2022 12:30:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 00B3A3665D5B; Sun, 6 Feb 2022 12:30:51 -0500 (EST) Date: 6 Feb 2022 12:30:51 -0500 Message-ID: <6e898e2d-15bb-1764-1a5f-a05a3d80cb8b@taugh.com> From: "John R Levine" To: "Alessandro Vesely" , emailcore@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: <26186a20-5189-fd98-91c8-5aaf41a8763d@tana.it> References: <3bfc25ff-b074-0894-f28d-fc24864b22f8@taugh.com> <26186a20-5189-fd98-91c8-5aaf41a8763d@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] Aliases and Mailing Lists, was Comments on -09 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2022 17:31:03 -0000 >> The A/S can say something about when you change the bounce address while >> forwarding, with the advice that the goal is to get the bounces to someone >> or something that can act on them. > > Agreed, except that this actionability advice is such an important principle > that deserves being published in 5321bis. 5321 is already too long and says the bounce address is where you send failure reports. Can you explain why this detail is so important that it needs to make 5321bis even longer? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Feb 6 09:48:28 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6D73A0AD2 for ; Sun, 6 Feb 2022 09:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.1 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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=nczt+N8m; dkim=pass (2048-bit key) header.d=taugh.com header.b=uRLaBweW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SA6TO0yQASQV for ; Sun, 6 Feb 2022 09:48:20 -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 71B9A3A0AD0 for ; Sun, 6 Feb 2022 09:48:20 -0800 (PST) Received: (qmail 52322 invoked from network); 6 Feb 2022 17:48:17 -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=cc5f.620009e1.k2202; bh=2Nm5TmTr4w71unWISroj76IC2MP3DYyQDrcknzVN1E4=; b=nczt+N8mfKF11yRl3resLP3JBeJuTZm2YJzym7WzEzAg/Q3XaUw2ZmCg/FrJ/M01HwRE3DIL+/99FZEBWMMPtuPbU+0VMmGrQ8izLKmrEjjcmFp6cgDvGjAUGEpb3jC3BNpeUWCY7qmUCeVL8eHfuiyJmF2XEoyaz5jl+GkfZinXb6hDtb9qcp9jZsKjvZcGeyZRe4pV6bQzmFCHNNMzjSLmOJn3MvuXEI55C6GKes4qOeI8M5VaFtZctDV98ZAODNwueRizSq2cXvQpjK82D6hJj7hMMmWrFlBZHqfWud9vK+DHRART+iJEG6AuUGVPWbyD9EJ2DLBaAtk4i1FlQA== 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=cc5f.620009e1.k2202; bh=2Nm5TmTr4w71unWISroj76IC2MP3DYyQDrcknzVN1E4=; b=uRLaBweWTrVxmVb01lBhxi5XCMQO+76fYkfsjZUt4s4LzaLQuqdGJZoeuy3h8FyUyvnLvqjpzg5nDwvoaMpNm+3ChhzkOAT9OP21q7odwjH/nRxWX8W8c9bUYki0/Q72ehKel7DDT0TEjjrpOWjc7crQZCJ978oEh8D62UFAg3q6EnaXcG7gAW0CPL4O7uTxVQbgb2iBaLB2YH6WXj1VLIP22VVWi2b8gi+t3LfmGkDjMxqJWrPAsVSNPh+lHqzuCjK4TXrMxLIMIGfdH6TOs3Jpvr/3HG9jS0NcK1tzbPG/zeY0XgJ0GX7IrMBn4v4huNd+CAJIVVHIzMiyCYuUjA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 06 Feb 2022 17:48:17 -0000 Received: by ary.qy (Postfix, from userid 501) id 941883665F4C; Sun, 6 Feb 2022 12:48:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 075743665F2E; Sun, 6 Feb 2022 12:48:16 -0500 (EST) Date: 6 Feb 2022 12:48:15 -0500 Message-ID: <57d0dffd-d74d-8765-7b9c-2092013af1a1@taugh.com> From: "John R Levine" To: "John C Klensin" , "Jeremy Harris" , emailcore@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: <7A262F8E67B3CDA8D7A7F136@PSB> References: <3bfc25ff-b074-0894-f28d-fc24864b22f8@taugh.com> <943ab66a-174c-a90b-33b3-0619bbd78cc6@wizmail.org> <7A262F8E67B3CDA8D7A7F136@PSB> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Emailcore] null MX Comments on -09 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 06 Feb 2022 17:48:26 -0000 >> My guess is that it's handling the situation of a sending MTA >> spotting the null MX explicitly, ignoring it, and proceeding >> to try the A for the domain. When I was working on 7505 I looked to see what existing MTAs do with a null MX. Most of them failed immediately with a message that the MX is invalid, some eventually timed out. We didn't say so in 7505 but one of the nice things about it was that in practice it mostly worked already, give or take the error message. I never saw one try to fall back to the A record. > (1) Client is not only pre-RFC 7505 but pre-RFC 974, e.g., some > embedded thing that has not been updated to understand MX > records at all, much less conformance to 5321bis. (I hope > there are few, if any, of those left.) ... I've never found it useful to try and guess how people who haven't read the spec will misimplement it. Keeping in mind that 7505 is basically a performance hack to make mail fail quickly rather than timing out, I would expect that ancient MTA to try for a week, then send the bounce message, which the recipient will not read because she retired a decade ago. This does not seem like a situation worth optimizing. >> Or never looking for an MX. By that logic, every host with an MX and an A should put a stub server sending 556 responses on the A hosts because who knows, someone might ignore the MXes and it is urgent that their users get failure messages right away rather than later. Aw, come on. I have nothing against people running 556 stub servers if they want to but that has nothing to do with null MX. R's, John PS: > And I note, in that regard, that I can find nothing in RFC 7505 that > prohibits advertising null MX but still responding to port 25. As I said, that is because "." is not a host name, is not a host, and has no ports. It equally does not forbid the root from running a gopher server or speculate about what people might do on hosts unrelated to the null MX. From nobody Mon Feb 7 00:51:27 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6733A08AD for ; Mon, 7 Feb 2022 00:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=CH3yLU6i; dkim=pass (1152-bit key) header.d=tana.it header.b=CxEmSjfY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUjIl6-VTiON for ; Mon, 7 Feb 2022 00:51:16 -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 463B73A08B5 for ; Mon, 7 Feb 2022 00:51:13 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1644223867; bh=E5UpzvqdiRljnTQCPXEAuDka7PFAuizPgy1Owq6vmSQ=; h=Date:Subject:To:References:From:In-Reply-To; b=CH3yLU6itJFWICvSoIdncuGUllT/P78T7o4XZaJZeDFGcdrx4bS5GUWWRQDMDsau+ xHoEbvnYSLscBZRQu8RBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1644223867; bh=E5UpzvqdiRljnTQCPXEAuDka7PFAuizPgy1Owq6vmSQ=; h=Date:To:References:From:In-Reply-To; b=CxEmSjfYKaG75Cad0KCgCuVL4qFt2ce2ZZcIfgcCqIxZRJyCzzdvTPEcc654QWQ9d k6dAIEaTxbP+enxDwk31dNE69q7wlRV1SGR64ZY4uXFuVdOtuQD0zNLs1vePqSGBW4 bITfQ75GwE2kRnMiVqEOnYIDhlIzKm6wOvVeSy0V+XJtEFOA0gPmLr6d2xe0z Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [192.168.1.108] (host-95-249-175-244.retail.telecomitalia.it [95.249.175.244]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0CD.000000006200DD7A.00006569; Mon, 07 Feb 2022 09:51:06 +0100 Message-ID: <40806d1a-aec6-bf18-4dde-9645f1b1d9d7@tana.it> Date: Mon, 7 Feb 2022 09:51:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: John R Levine , emailcore@ietf.org References: <3bfc25ff-b074-0894-f28d-fc24864b22f8@taugh.com> <26186a20-5189-fd98-91c8-5aaf41a8763d@tana.it> <6e898e2d-15bb-1764-1a5f-a05a3d80cb8b@taugh.com> From: Alessandro Vesely In-Reply-To: <6e898e2d-15bb-1764-1a5f-a05a3d80cb8b@taugh.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Aliases and Mailing Lists, was Comments on -09 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 07 Feb 2022 08:51:25 -0000 On Sun 06/Feb/2022 18:30:51 +0100 John Levine wrote: >>> The A/S can say something about when you change the bounce address >>> while forwarding, with the advice that the goal is to get the >>> bounces to someone or something that can act on them. >> >> Agreed, except that this actionability advice is such an important >> principle that deserves being published in 5321bis. > > 5321 is already too long and says the bounce address is where you send > failure reports.  Can you explain why this detail is so important that > it needs to make 5321bis even longer? Let me explain a bit better. I didn't mean to make it longer. I proposed to *replace* the treatment of a couple of fixed cases, aliases and mailing lists, which don't cover all possible situations, with some general principles which are to be expanded in the A/S. For example, Section 3.4.2.1 says aliases should never change the bounce address while there are cases where it is better to change it. One such case is treated in Section 3.4.1, but without mentioning what to do with the bounce address in case the final address shall not be disclosed. For anther example, let's consider a role alias which expands sales@example.com to joe@example.com, jane@example.com and jon@example.com. If I were a marketing manager at example.com, I'd want a message to be considered delivered if it arrives at one or more team members. Hence a bounce should be generated only if all three mailboxes bounce, unless positive MDN are also going to be generated. My proposal is that 5321bis just says that the bounce address should be adjusted according to the actionability principle and information leaking considerations, according to the semantics of the alias. That way the text would still be longer than by striking the whole Section 3.4.2 away, but somewhat shorter than -09. Best Ale -- From nobody Mon Feb 7 10:28:36 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0313A0B75 for ; Mon, 7 Feb 2022 10:28:33 -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 d0SVMEMWfCX4 for ; Mon, 7 Feb 2022 10:28:29 -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 C8E923A105C for ; Mon, 7 Feb 2022 10:28:28 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nH8kN-000183-31; Mon, 07 Feb 2022 13:28:19 -0500 Date: Mon, 07 Feb 2022 13:28:12 -0500 From: John C Klensin To: John R Levine , Jeremy Harris , emailcore@ietf.org Message-ID: In-Reply-To: <57d0dffd-d74d-8765-7b9c-2092013af1a1@taugh.com> References: <3bfc25ff-b074-0894-f28d-fc24864b22f8@taugh.com> <943ab66a-174c-a90b-33b3-0619bbd78cc6@wizmail.org> <7A262F8E67B3CDA8D7A7F136@PSB> <57d0dffd-d74d-8765-7b9c-2092013af1a1@taugh.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] null MX Comments on -09 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 07 Feb 2022 18:28:34 -0000 --On Sunday, February 6, 2022 12:48 -0500 John R Levine wrote: >>> My guess is that it's handling the situation of a sending MTA >>> spotting the null MX explicitly, ignoring it, and proceeding >>> to try the A for the domain. > > When I was working on 7505 I looked to see what existing MTAs > do with a null MX. Most of them failed immediately with a > message that the MX is invalid, some eventually timed out. We > didn't say so in 7505 but one of the nice things about it was > that in practice it mostly worked already, give or take the > error message. I never saw one try to fall back to the A > record. > >> (1) Client is not only pre-RFC 7505 but pre-RFC 974, e.g., >> some embedded thing that has not been updated to understand MX >> records at all, much less conformance to 5321bis. (I hope >> there are few, if any, of those left.) ... > > I've never found it useful to try and guess how people who > haven't read the spec will misimplement it. Keeping in mind > that 7505 is basically a performance hack to make mail fail > quickly rather than timing out, I would expect that ancient > MTA to try for a week, then send the bounce message, which the > recipient will not read because she retired a decade ago. > This does not seem like a situation worth optimizing. > >>> Or never looking for an MX. > > By that logic, every host with an MX and an A should put a > stub server sending 556 responses on the A hosts because who > knows, someone might ignore the MXes and it is urgent that > their users get failure messages right away rather than later. > Aw, come on. > > I have nothing against people running 556 stub servers if they > want to but that has nothing to do with null MX. > > R's, > John > > PS: >> And I note, in that regard, that I can find nothing in RFC >> 7505 that prohibits advertising null MX but still responding >> to port 25. > > As I said, that is because "." is not a host name, is not a > host, and has no ports. It equally does not forbid the root > from running a gopher server or speculate about what people > might do on hosts unrelated to the null MX. Sure, but I obviously was not clear about the case I had in mind. Clearly, a client would have to demonstrate a rather extreme and creative level of stupidity to try to look up "." and then open a connection to whatever host they think that means. Two things are more plausible: (i) the client gets the MX record back after looking up the domain in the address, sees "." in the data, doesn't understand the convention, and discards the record. At that point, it has run out of MX records and 5321 clearly says that it should stop and return a fatal reply message. That fact that most clients -- whether aware of 7505 or not -- are going to follow that "if there are one or more MXs and all of them ore exhausted or eliminated, fail" rule is, I assume, why you see the behavior you describe above. A server implementer who did not want the retry behavior you describe and therefore wants to run a 556 stub server should not be prohibited from doing that. On the other hand, we don't need to go out of our way to encourage that either. So, let me back up a bit. I think there are three questions here. One is why 5321bis says what it says (independent of trying to guess at motivations or types of wrong behavior). To a considerable extent, I (and perhaps Jeremy) was responding to that one but, for reasons you (indirectly) give, it isn't really important. The second is whether what it says is sufficiently wrong that we need to change it by rewriting, adding, or removing text and, if so, how. And the third is what, if anything can and should be clarified without changing the substance of what is said. And, fwiw, the cases I actually think are significant involves an SMTP server that accepts mail for several domains but, of course, does not act as an open relay or otherwise accept mail for other domains, even domains within the same administrative group, e.g., ones that might be supported by the same servers for web or other purposes but not for email. It cannot produce a 556 reply at connection-opening because it doesn't yet know what domains will appear in addresses in RCTP commands. Now, it would be entirely reasonable for whomever configures the DNS for the relevant domain to put in a null MX record, but as several of us have pointed out from time to time, DNS zone administration and mail server administration and operations are often separate people and even in separate groups, and assuming good coordination may be unrealistic. So here we have a server that has a perfectly good reason to have something that responds on the SMTP port even though it might reasonably want to reply 556 to a RCPT command (rather than a code about the specific mailbox)** if it will not accept _any_ mail for that domain). And getting into that situation does not require any client misbehavior, only a bit of DNS mis-configuration, whether latter is failure to include a null MX RR, an MX that points to the server, or omitting any MX records and letting the client to the address records intended for another purpose. best, john ** I just noticed that 556 is not included in the list of response codes for RCPT in Section 4.3.2. Given the logic above, should it be added or should we just rely on "usual possible replies" in the first paragraph of that second as not prohibiting and move on. And, especially if it is added, should the discussion of 556 in the second paragraph of Section 4.2.4.2 be modified to include that case? From nobody Mon Feb 7 15:00:19 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09D93A0E67 for ; Mon, 7 Feb 2022 15:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.85 X-Spam-Level: X-Spam-Status: No, score=-6.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, RCVD_IN_DNSWL_HI=-5, 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=r9oc3/Jc; dkim=pass (2048-bit key) header.d=taugh.com header.b=s/YzFaHP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpeIFGX-wtI2 for ; Mon, 7 Feb 2022 15:00:11 -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 91EFB3A0E3C for ; Mon, 7 Feb 2022 15:00:11 -0800 (PST) Received: (qmail 88855 invoked from network); 7 Feb 2022 23:00:08 -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=15b10.6201a478.k2202; bh=1El9CLiTZOTCRJ+5tjNd4zzmbj1aLGzmaivd18Y4OS0=; b=r9oc3/JcqKwFs6r2Om3mX3fEzpJnARPSaC7IwkjY+dzVEOBRA4OLqFEFVIG1jCui9LUyyOM+gv8dXnSPmhN4KihL5ad1U/eUirXtwRwJ3uFMBdq/PR65rbbcNrAEPLNSdgdjm5MnGktXjIU2qKiB6Gci4GJ+rCyPbaoOI5KzVzBXsF6uc3I3TfRX0TdXXT96lF1WFStFSnwctDpT6hjb9/Qq2fuwRg0DufKMRXwLfcQDAgmZr3zLnOn9RZ/eHvUjyOjqYifiQvM6VRHWnU4VX9chKwAcU5VbU4PJ+40vhJ4xNIJAImvP1TsxG+z6uD8Lwq2qHftowdfJ1hMnpM33GA== 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=15b10.6201a478.k2202; bh=1El9CLiTZOTCRJ+5tjNd4zzmbj1aLGzmaivd18Y4OS0=; b=s/YzFaHPs4B0th7GzUqoOE8Y6c/+yOm0namLLyDOP7AnnI5xji32oRSD07BJeHQwRMqfAmQjf486Trb2gDT8LuP+VXBsnNyBGr3fKEi6ayWPkw8+lguva56QpwajoHHW6M2WZyN5unkQJL1qBiBVzYglBQndHPskcsxglWnBgf9wj+sYS61x4d0+T3xbcZJm7JKIZ8A2RI/foUEcN4m1MMmznN2J2jQPF0jx1Oek1P/Ym2cgUMjKQ53Z37FTVUeK+x4U6otl3mXAFc909tGms5Aiq8/MB+bYiKBmr9Kmy4stMd8C7lQ2uTw7VsK5JE4UkKWjWNoqg5jNDFJkCJuVZg== 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; 07 Feb 2022 23:00:08 -0000 Received: by ary.qy (Postfix, from userid 501) id 7C98636730B1; Mon, 7 Feb 2022 18:00:06 -0500 (EST) Date: 7 Feb 2022 18:00:06 -0500 Message-Id: <20220207230007.7C98636730B1@ary.qy> From: "John Levine" To: emailcore@ietfa.amsl.com Cc: john-ietf@jck.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] null MX Comments on -09 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 07 Feb 2022 23:00:17 -0000 It appears that John C Klensin said: >So, let me back up a bit. I think there are three questions >here. One is why 5321bis says what it says (independent of >trying to guess at motivations or types of wrong behavior). To >a considerable extent, I (and perhaps Jeremy) was responding to >that one but, for reasons you (indirectly) give, it isn't really >important. The second is whether what it says is sufficiently >wrong that we need to change it by rewriting, adding, or >removing text and, if so, how. I took another look and the sentence that bothers me is this one: ... If, despite publishing the DNS entry, the server domain chooses to respond on the SMTP port, it SHOULD respond with the 556 code as well. The details of the Null MX convention were first defined in RFC 7505 [46]; see that document for additional discussion of the rationale for that convention. "The server domain" is confusing. I'd be OK with "hosts that are not mail servers but are identified by A or AAAA records for the domain." >And, fwiw, the cases I actually think are significant involves >an SMTP server that accepts mail for several domains but, of >course, does not act as an open relay or otherwise accept mail >for other domains, even domains within the same administrative >group, ... But this is the usual case. If I send mail to someone at hotmail.com, the MX is hotmail-com.olc.protection.outlook.com and that server does not accept mail for that domain (I checked.) I don't see any reason why you would want to have different responses for "I don't accept mail for that domain" and "I don't accept mail for that domain and I don't think anyone else does either." It's just one more thing to get wrong. It doesn't tell the other party anything useful other than I suppose, a hint that her mail system is broken. But of course the mail system sending that code might be broken instead. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Feb 7 18:11:31 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D613A1176 for ; Mon, 7 Feb 2022 18:11:30 -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 tLZd7xT24zBi for ; Mon, 7 Feb 2022 18:11:25 -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 2422D3A1174 for ; Mon, 7 Feb 2022 18:11:24 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nHFyT-0001x5-Qg; Mon, 07 Feb 2022 21:11:21 -0500 Date: Mon, 07 Feb 2022 21:11:15 -0500 From: John C Klensin To: John Levine , emailcore@ietfa.amsl.com Message-ID: In-Reply-To: <20220207230007.7C98636730B1@ary.qy> References: <20220207230007.7C98636730B1@ary.qy> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] null MX Comments on -09 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 08 Feb 2022 02:11:30 -0000 --On Monday, February 7, 2022 18:00 -0500 John Levine wrote: > It appears that John C Klensin said: >> So, let me back up a bit. I think there are three questions >> here. One is why 5321bis says what it says (independent of >> trying to guess at motivations or types of wrong behavior). >> To a considerable extent, I (and perhaps Jeremy) was >> responding to that one but, for reasons you (indirectly) >> give, it isn't really important. The second is whether what >> it says is sufficiently wrong that we need to change it by >> rewriting, adding, or removing text and, if so, how. > > I took another look and the sentence that bothers me is this > one: > > ... If, despite publishing > the DNS entry, the server domain chooses to respond on the > SMTP port, it SHOULD respond with the 556 code as well. > The details of the Null MX convention were first defined in > RFC 7505 [46]; see that document for additional discussion > of the rationale for that convention. > > "The server domain" is confusing. In retrospect, agreed. > I'd be OK with "hosts that > are not mail servers but are identified by A or AAAA records > for the domain." I think that might be even more confusing for the case in which the host is a mail server for some domain(s), just not that one (including, I think, your example below). How would you feel about: "hosts that are not mail servers for a particular domain but are identified by A or AAAA records for that domain." ? >> And, fwiw, the cases I actually think are significant involves >> an SMTP server that accepts mail for several domains but, of >> course, does not act as an open relay or otherwise accept mail >> for other domains, even domains within the same administrative >> group, ... > > But this is the usual case. If I send mail to someone at > hotmail.com, the MX is hotmail-com.olc.protection.outlook.com > and that server does not accept mail for that domain (I > checked.) For which domain? Certainly it accepts mail for hotmail.com or nothing would work. Assume you tried to send mail to user1@hotmail.com. Nothing we have said implies that it is obligated to accept mail addressed to user1@hotmail-com.olc.protection.outlook.com and would expect a 556 response it if got a RCPT command for that address. So, assuming that mailboxes exist for user1@hotmail.com and user2@live.com (see below) but not for user2@hotmail.com, I'd expect (noting that the text with the reply is explanatory, not necessarily what I'd expect from a server): RCPT TO: 250 OK RCPT TO: 550 No such mailbox RCPT TO: 556 No mail service for hotmail-com.olc.protection.outlook.com RCPT TO: 556 No mail service for hotmail-com.olc.protection.outlook.com RCPT TO: 250 OK RCPT TO: 556 No mail service for live-com.olc.protection.outlook.com Noting, fwiw, that the MX for live.com points to live-com.olc.protection.outlook.com. and that live-com.olc.protection.outlook.com. IN A 104.47.14.33 and hotmail-com.olc.protection.outlook.com. IN A 104.47.74.33 i.e., as far as TCP is concerned, hotmail.com and live.com are supported by the same host. Are we agreed so far? Do I think it makes a huge difference whether RCPT TO: gets a 556 or 550 code (after all, if there is no service for that domain, there is no mailbox either)? Nope, but the former seems more orderly. I also note that there is no null MX record for hotmail-com.olc.protection.outlook.com. That is ok, AFAICT, but, in its absence, the client has no way to know that, if it sends a RCPT command containing that domain, it won't work without trying it and (presumably) getting a 550 or 556 reply. > I don't see any reason why you would want to have > different responses for "I don't accept mail for that domain" > and "I don't accept mail for that domain and I don't think > anyone else does either." It's just one more thing to get > wrong. Agreed. I hope I didn't say anything that confuses you about that. Do the above examples help? Do we need to turn that into a table in 5321bis with the Microsoft domains appropriately disguised (I hope not, but, if it is the only way to make this clear, maybe we should consider it. > It doesn't tell the other party anything useful other than I > suppose, a hint that her mail system is broken. But of course > the mail system sending that code might be broken instead. Right. And that is also the reason I'm not sure whether the difference between getting a 550 or 556 code back if a RCPT command contains hotmail-com.olc.protection.outlook.com is really important. But that questions may take us several steps back to the "only the first digit counts" discussion. And the 556 _might_ allow the client or the user's MUA to give the user slightly more clues about what is going on... unless we decide that such a user is sufficiently confused that leading them around in circles would be desirable. best, john From nobody Mon Feb 7 18:50:09 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63B83A11AD for ; Mon, 7 Feb 2022 18:50:07 -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, 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=lMR8M4dr; dkim=pass (2048-bit key) header.d=taugh.com header.b=iaV+NGJb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPB_FXJEH9tG for ; Mon, 7 Feb 2022 18:50:03 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36583A119A for ; Mon, 7 Feb 2022 18:50:02 -0800 (PST) Received: (qmail 89085 invoked from network); 8 Feb 2022 02:50:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=15bf8.6201da58.k2202; bh=18jYioM9wdhcwjMgUkufnVkjSDB/J/bgVsgQw7oreEw=; b=lMR8M4driM2YgIGMrIsGjYQHD+Vwe9eJNxp2dTi4ws8NBM8i0Bcn1G092Ja59vRZ8UK9uup36P8pQWxjWeh4GUe+T7yhQzbUwXpUJV4Aaw8GFzUJAL7zH6+3Jp506lsURTLQW3Rte/nSSB+aibLkk96jjlLPZkw7ZqIUv4jPxb0gPRxUmkSAUSDrQkM6lCYnPgCcMxjF7LJ7i2eN69PN+hJIzGH5l1Ls9IlfVStWNMrx3P2ORjVyl0HcfSzaimcdstIG7p/RZex297HaZNPctFC4QSsw3Kf/lIuxDCx5cF9jphKwNf/TgdCoLVVqKK4WENgmuzmF2NqftSEY7B/twg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=15bf8.6201da58.k2202; bh=18jYioM9wdhcwjMgUkufnVkjSDB/J/bgVsgQw7oreEw=; b=iaV+NGJbkRGct+PqajEGUtvcSDwyeH+cByA8VjwLMZNjjbScaNtFqRERtA2a1BWjEIzDSFz671o3rmVvEUil/1g9kOyd2XOWV8qDGqKH+no4EWY2bDXTlMZZYiPhw/6JHKTqpRjElzEK02fsFKVAASPJkPzkLYU3tXRN62BiB3j8W90GAnnhOUNVIxxCTDaOVywSt2ZZ3cAaIVeT7iRJzpPpoao295TX4WYxko+K84rorg0PEl7j6/T8yEupsMEY0GyoFlIU6lfFOaAPeOagOe0VGvJWfWFCFyZIpmoS21VGCE9sElSZA9MUjTmo2OCStQf4ASxQ2AFZkY/w/YFQKw== 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; 08 Feb 2022 02:49:59 -0000 Received: by ary.qy (Postfix, from userid 501) id 3E436367492D; Mon, 7 Feb 2022 21:49:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id A40AF367490F; Mon, 7 Feb 2022 21:49:58 -0500 (EST) Date: 7 Feb 2022 21:49:58 -0500 Message-ID: <030418b4-7142-6d11-bd27-495f2dd45da4@taugh.com> From: "John R Levine" To: emailcore@ietfa.amsl.com Cc: "John C Klensin" X-X-Sender: johnl@ary.qy In-Reply-To: References: <20220207230007.7C98636730B1@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Emailcore] null MX Comments on -09 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 08 Feb 2022 02:50:08 -0000 >> I'd be OK with "hosts that >> are not mail servers but are identified by A or AAAA records >> for the domain." > > (including, I think, your example below). How would you feel > about: > > "hosts that are not mail servers for a particular domain > but are identified by A or AAAA records for that domain." That's just baffling. The domain has an MX and and A that points to a mail server that only handles other domains? I'm guessing that the idea is that there's a null MX for www.foo.com, and it happens that www.foo.com is the same host as mail.foo.com which handles mail for foo.com but not www.foo.com. While that surely happens and has been happening for 40 years, in practice either the mail server rejects mail to www.foo.com with a 550, or it's misconfigured and accepts it anyway. (See, for example, the To: address on this message.) > Do I think it makes a huge difference whether > RCPT TO: > gets a 556 or 550 code (after all, if there is no service for > that domain, there is no mailbox either)? Nope, but the former > seems more orderly. But it's not what anyone does now. It's all 550. More often than not the MTA has no idea what its name is or anything else other than the list of domains that it is configured to handle. >> I don't see any reason why you would want to have >> different responses for "I don't accept mail for that domain" >> and "I don't accept mail for that domain and I don't think >> anyone else does either." It's just one more thing to get >> wrong. > > Agreed. I hope I didn't say anything that confuses you about > that. Do the above examples help? No, they seem to say the opposite, trying to guess why the sender wants you to accept mail that you don't accept. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Feb 15 07:14:04 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8EE3A0D42 for ; Tue, 15 Feb 2022 07:14:01 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=paclan.it; domainkeys=pass (2048-bit key) header.from=giovanni+emailcore@paclan.it header.d=paclan.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 fWG4dURNCB3V for ; Tue, 15 Feb 2022 07:13:56 -0800 (PST) Received: from blink.snb.it (spiderman-ip0.snb.it [94.23.109.9]) (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 E35383A0D41 for ; Tue, 15 Feb 2022 07:13:55 -0800 (PST) Received: from blink.snb.it (localhost [127.0.0.1]) by blink.snb.it (OpenSMTPD) with ESMTP id ecd93964; Tue, 15 Feb 2022 16:13:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=paclan.it; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=dkim; bh=aePOCp5mZTVcQX5gGYf/5GsNa8U=; b=EfYOhZp xSXDNYXz5CKiiN+/7kaluDWkrND6cNKNGnaqsgCJPYAh4pv7Fg5XVKWK+QsMcigV xlOn5Vrqsp/BERYyEqpWRFbTEW45pasn2lxmWsBlJiBH39cJAGhlJjyTz9DxsWt9 cfRND9v98qUADbW1iTQc/rJPbnsx+HlRuBlutsjYRWM6CR/FWn4yUDa7PmbhMAVr iN6hF7qcWeNhrg6E1lhEeBiyxApsQeMEhJgdUjrHL1SpHyRq90YJBc6L0jCcmnfF nxuy8vqNpaOvsUQRLF6ivUa5S4JXtsw6O28qtsoTvoRnINIFKpHceN/cg9tovUXN YfAMV2uWexrDPiQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=paclan.it; h=date:from:to:cc :subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=dkim; b=vSOlHEJVPSFya9Brnm44vyp3si2fAY4nk a8Ry9ygJHNTYjwVULc580eL2zqi14lYmx9W/etoGThYJ2aG6rT/6zQlEXA24dp7b V0Ck9s567MqycIdk9Yqu/fPoVhi8GZN42AKk/ghotl3byj9qBVhwPt+R3pk9Ur/e 8SJn73UMKyIeEqk5H1vhIYXhWv+eLp71eClGLEooyep45TfLXTwJLtnrK4dipjik tEeMEL36KartnLzT7dNjqTP1q99VidaN1tn95URvyYE8XmPrHssc8/+UYdzRYYyj /UyOcsWbZ9dWsiA/B9uLfTaEac5pj+hlfa0MZkhpxgG9h7JrvD9aw== Received: from bigio.paclan.it (host-79-11-196-3.business.telecomitalia.it [79.11.196.3]) by smtp-news.snb.it (OpenSMTPD) with ESMTPSA id bc4f6cfe (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Tue, 15 Feb 2022 16:13:51 +0100 (CET) Received: from bigio.paclan.it (localhost [127.0.0.1]) by bigio.paclan.it (OpenSMTPD) with ESMTP id e2567840; Tue, 15 Feb 2022 15:13:49 +0000 (UTC) Date: Tue, 15 Feb 2022 16:13:49 +0100 From: Giovanni Bechis To: John C Klensin Cc: "Peter J. Holzer" , emailcore@ietf.org Message-ID: References: <20220204202552.7xygqwpobyl7nfgm@hjp.at> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oX9jIuPSxDRPQNc8" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Emailcore] The RDATA of a DNS record with RRTYPE=MX X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 15 Feb 2022 15:14:02 -0000 --oX9jIuPSxDRPQNc8 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 04, 2022 at 04:07:35PM -0500, John C Klensin wrote: >=20 >=20 > --On Friday, February 4, 2022 21:25 +0100 "Peter J. Holzer" > wrote: >=20 > > On 2022-02-04 14:42:04 -0500, John C Klensin wrote: > >> New: > >> When a domain name associated with an MX RR is looked up > >> and the associated data field obtained, the data field > >> of that response MUST contain a domain name that > >> conforms to the specifications of Section 2.3.5. That > >> domain name also MUST resolve to a primary host name, > >> i.e., it is not allowed to be an alias. > >=20 > > I would prefer "... also MUST be a primary host name ..." as > > in the penultimate paragraph of section 2.3.5. > >=20 > > "Resolve to a primary host name" for me implies that a DNS > > lookup would be necessary to get the primary host name. >=20 > Definite improvement. Thanks. >=20 > However, I had not read the subsequent paragraph (the one > starting "When a domain name associated...") closely enough > (this is why I ask the WG before making this sort of change). > It already asks that the domain name be queried (the DNS lookup > to which you object) and then handwaves the CNAME issue ("Any > other response, specifically including a value that will return > a CNAME record when queried, lies outside the scope of this > Standard." and then points to RFC 2181. I don't know whether > the several updates to 2181 clouds that advice. More important, > continuing to reference it from 5321bis will take us into > downref territory. =20 >=20 > So, I'm not going to try to write text right now and would > appreciate input and advice from you and others. However, given > recent pushback on another spec that said "MUST do this but, if > you don't then...", I'm inclined to see if we can clean things > up considerably. In particular, if "MUST be a primary host > name" is good enough, I wonder if we can eliminate most or all > of that subsequent paragraph rather than dragging things out. >=20 I think that specifying that if "MUST be a primary host name" is clear enough and at least a part of the subsequent part can be removed. Giovanni --oX9jIuPSxDRPQNc8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEqg3TnG6R3qYMxl94+r7qCYlyWOUFAmILwy0ACgkQ+r7qCYly WOXNWw//dkxXEqtIocefsVHGH20RDA5sTZPvUB3WfKgzsmHzAfVwPGNX+FFJd1ji 62DPHqF5UiFRItz6Xf081wmyupjroJWEdXUHoZ7WnqV+m6aqgCRL4hz1kQ1d8tbl aNgezBGhRFB9P73yNTfBflVBiYh1U23zgzMW+EbWCmxZFsiwFkEhV8tiN/+quw0R 49delVz4fmJMSnfiq54GCs28mvQd5ur/5+NWZdjoK3uKFOsWOjD1W5Nw4NJhhTMI /ekc/8xM9pkn1Bu6ClXhBMSPptPMnJKcABphxAftXJK/NYgiWbAuSv6cIKzXj/0j BeoGgwwx2LKmxmkixULF5FluKjzinNWvHK+t4oq48IMqq+3JBz5S8Jt0fZhr0Y71 sogw5nxJsstJTw5EDPB9K3m06YA4HA+5d2wNpnJDdmH68knKJEbPbvcAkIeFSUFS GLZlSNsa731hMccdsjj/ot/23eJkm3+txD3zH4C/dbqsIeDFtTYLLqNP3PDEMWuQ sRgCfgM1dL86OeXoDdbZAjerhBJMVlnkKU3wU/u/5NrVle2A2RwuQYx18R4ORy9i Y0o/sUhDeF0eQEcumtD6fk3j3dtYgfPvoGp2QONsLRH0xXarpUpkv14BA5IOtD3D 6bPGmU/qEyGPv428TejelZuS167kMp5lIEOl6+2fYk0nrVd6OX8= =uZBk -----END PGP SIGNATURE----- --oX9jIuPSxDRPQNc8-- From nobody Tue Feb 15 16:06:13 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80293A1092 for ; Tue, 15 Feb 2022 16:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tutanota.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 anTAjZyyDpBD for ; Tue, 15 Feb 2022 16:06:05 -0800 (PST) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (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 B71B03A1080 for ; Tue, 15 Feb 2022 16:06:05 -0800 (PST) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id 0262AFBF8D2 for ; Wed, 16 Feb 2022 00:06:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1644969962; s=s1; d=tutanota.com; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender; bh=Ql/0tqCIgpdqQB1kBrjQf1ODQ7na9JMa/NFVR3/RIHA=; b=1yn90nOkppH4SGTLrkBMBpvxV10rOfYM298FfRtp1+HVrvie8HuKfeuI9qx7utj/ kJNAZO0xaziNQmThyDZ7pdCcDC60pdSRFHCHrDX4JNZNfgLQUhHUa9Ut9zxQxYhINSv xSLf7OjWfL0GURWbdgHYl5kXqG+/mS/WVNseHR1vO2fEzFCY/6fkhR8k43skLCttUQZ xIjhPTMFK9+E00/9aKUpDTySG6BfcQtzK4G6B1LM0bKyYZYvzDfN1v49Sbd8ZyMDwMw 72yvb7bZk/7ZGlwIEmxKNSeq7AbdyJCbxZ9JMnvxi2Mjg3KY411tbLpCYXJ84v55/jC G2zMa4oYsA== Date: Wed, 16 Feb 2022 01:06:02 +0100 (CET) From: Borden To: emailcore@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Emailcore] Unicode X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 16 Feb 2022 00:06:11 -0000 I apologise that my first question to the IETF is out of scope. However, si= nce there is so much activity, I think the best person to answer will be re= ading: Under 2.1. of RFC 5322, why does it say ANSI instead of UTF-8 (or -16 or -3= 2)? Most technology uses Unicode (or at least supports it), so why does the= core e-mail standard still rely on the basic Latin alphabet? How will the = Internet break if the standard switches to Unicode? As not to clutter the list, you may respond to me privately. I'd appreciate= =C2=A0links to previous discussions or analysis that can help me understand= this issue. As I get more familiar with the IETF process, I would like to = prepare an argument to submit when the circumstances are appropriate. With thanks, From nobody Tue Feb 15 16:12:37 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FA83A0954 for ; Tue, 15 Feb 2022 16:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsefuiXwAW7v for ; Tue, 15 Feb 2022 16:12:30 -0800 (PST) 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 EC3D33A10A5 for ; Tue, 15 Feb 2022 16:12:21 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E10EE621836; Wed, 16 Feb 2022 00:12:17 +0000 (UTC) Received: from gcp-us-central1-a-smtpout1.hostinger.io (unknown [127.0.0.6]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 2EC84621B45; Wed, 16 Feb 2022 00:12:17 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout1.hostinger.io (gcp-us-central1-a-smtpout1.hostinger.io [35.184.15.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.121.92.76 (trex/6.5.3); Wed, 16 Feb 2022 00:12:17 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Oafish-Name: 11e717e76ef13bd3_1644970337701_832288496 X-MC-Loop-Signature: 1644970337701:2723924573 X-MC-Ingress-Time: 1644970337700 Received: from [192.168.0.107] (c-73-170-122-71.hsd1.ca.comcast.net [73.170.122.71]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 4Jyz0v250Wz2cFYm; Wed, 16 Feb 2022 00:12:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1644970336; bh=4X6j9PeJ+JHMwlmr+LzGNJ3HXrE5farwCllIZT/TgVQ=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To; b=QpcAM5ajhVErzBT9hXE8dq5FGDLUQLfvZqjAICsX0+BkjRzsxGRgtihqCWOT80nhV 0nLhYy618nagzbiTl/aKwcB29DaFpfG9ESYnh7K27dxoCreCtxDw/hGf5BcCZxtyr8 9jUHM/iSM8AyxoIAvpEWeri8LRrZhgmJO2VwTKA8Ut+SV6s4nSgqaKkfrMBgdpKOJF oAMKHlkQSxKp6tecf8reVpaciIQJUBHnNm5bbuq0RcZ3xujxM7E61thlKLlRu+7CNK 3VqRmuJIJa29VfsZD09E+hkoM4JlZAC88rkVRKwIgH016DQOXos1+oRt7PW57ePdif n2NbOfd9cqeYQ== Message-ID: <235f8375-23e8-cadd-04e3-af162b048c10@dcrocker.net> Date: Tue, 15 Feb 2022 16:12:14 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Reply-To: dcrocker@bbiw.net Content-Language: en-US To: Borden , emailcore@ietf.org References: From: Dave Crocker Organization: Brandenburg InternetWorking In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Unicode X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 16 Feb 2022 00:12:36 -0000 On 2/15/2022 4:06 PM, Borden wrote: > Most technology uses Unicode The origins of RFC 5322 date back to the 1970s. Quite a bit earlier than Unicode. Successors to that original work have been careful to maintain continuity, to protect the installed base. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Feb 15 18:47:49 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EBA3A00B1 for ; Tue, 15 Feb 2022 18:47:46 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=YjqxTx+q; dkim=pass (2048-bit key) header.d=taugh.com header.b=7h+BShYw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKkxwhrwnLYg for ; Tue, 15 Feb 2022 18:47:41 -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 2CF473A00E0 for ; Tue, 15 Feb 2022 18:47:40 -0800 (PST) Received: (qmail 97353 invoked from network); 16 Feb 2022 02:47:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=17c47.620c65ca.k2202; bh=E9Fxt+5VEHQiXLHDmfb9YCDA4racds1I8yOFFixwQvk=; b=YjqxTx+qwo6dgTFT03XeHDtI5PA6wA3s42P97zTELPTJT3H+jDMomKI79N6Ci5Ts7+mrVwOkhMkXPsd53yK74eD5NMjmOXy2xqn203BGZxf5ZlBeZtSb7g7/QQ/g9Zt+1MlNni9cvxflyiKx4jgPUf+bsFbpzIdUQy03Ya9jiYwIGsv6g/6r/DodcET+VKBCxlsYdprCChBDk9c2X9zSDo8lBJ3Vv5W1uOuDqzcBpLiTwhXWrpFjoF1k8yU3o6bzpN0xgwM1jSi6a/kGug4IEXOKKmtoRq4SFkD4h0YVMOSi4PyNPQUtgmi+lfaOZG/jEJF0OcIVOIf8yFuRS54qZg== 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=17c47.620c65ca.k2202; bh=E9Fxt+5VEHQiXLHDmfb9YCDA4racds1I8yOFFixwQvk=; b=7h+BShYw93Y7HFV/gKt5Sy7j66xp32gZ/sqEe78VoceMgwLmj23CRGvmgTpUrrUhW0GXgEXmCEIJowdQiKROxtgwzEeXDdGyNvx0I8zFLMAufejnTdMhgaQ21Jn/WNywvYriil5rzy+yM8JSOBMSxfBsDkQW9Fvs0ZZ/tJWd1PHljJo8PaUyTlc8Hxo6zV0fDsqBVjeZwgX8UxCH0Vr/KHiI9rU1OPCpEomC28EnHMy18J5N7qMKoPk98uvAqp/D8M5Kg+iTmuIW5qlNQdq7GWnOOHy5ChktEerH5n6wmDRctlXgo0Y3mppdt+/3nieiNWBVlhpE2z6+ZbecIfu7rA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 16 Feb 2022 02:47:37 -0000 Received: by ary.qy (Postfix, from userid 501) id 00699374631C; Tue, 15 Feb 2022 21:47:36 -0500 (EST) Date: 15 Feb 2022 21:47:36 -0500 Message-Id: <20220216024737.00699374631C@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <235f8375-23e8-cadd-04e3-af162b048c10@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Unicode X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 16 Feb 2022 02:47:47 -0000 It appears that Dave Crocker said: >On 2/15/2022 4:06 PM, Borden wrote: >> Most technology uses Unicode > >The origins of RFC 5322 date back to the 1970s. Quite a bit earlier >than Unicode. > >Successors to that original work have been careful to maintain >continuity, to protect the installed base. MIME allows you to use UTF-8 in nearly every bit of visible text in an e-mail messsage, sometimes encoded in base64 or quoted-printable in the internal form of the message, but every current mail program takes care of that transparently. The one place MIME doesn't allow UTF-8 is in the actual e-mail addresses. That was dealt with by Internationalized Email, usually known as EAI. See RFCs 6530, 6531, 6532, 6533, 6855, 6856, 6857, and 6858. Many large mail operators including Google's Gmail and Microsoft's various offerings can correspond using EAI addresses even though they only offer ASCII addresses on their own systems. Having done a lot of EAI conformance and compatibility testing, I can report that allowing UTF-8 in addreses and actually making it work is way more complicated than you might expect. R's, John From nobody Tue Feb 15 19:10:04 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3913A131D; Tue, 15 Feb 2022 19:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 54vAmFXJ7HIv; Tue, 15 Feb 2022 19:09:59 -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 F11E83A131B; Tue, 15 Feb 2022 19:09:57 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nKAhY-000795-I1; Tue, 15 Feb 2022 22:09:56 -0500 Date: Tue, 15 Feb 2022 22:09:50 -0500 From: John C Klensin To: Borden , emailcore@ietf.org Message-ID: <79C32A97E8BE24EDCA1FF920@PSB> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Unicode X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 16 Feb 2022 03:10:02 -0000 --On Wednesday, February 16, 2022 01:06 +0100 Borden wrote: > I apologise that my first question to the IETF is out of > scope. However, since there is so much activity, I think the > best person to answer will be reading: >=20 > Under 2.1. of RFC 5322, why does it say ANSI instead of UTF-8 > (or -16 or -32)? Most technology uses Unicode (or at least > supports it), so why does the core e-mail standard still rely > on the basic Latin alphabet? How will the Internet break if > the standard switches to Unicode? >=20 > As not to clutter the list, you may respond to me privately. > I'd appreciate=C2=A0links to previous discussions or analysis = that > can help me understand this issue. As I get more familiar with > the IETF process, I would like to prepare an argument to > submit when the circumstances are appropriate. Completely agreeing to Dave Crocker's comments, but to add to them, one does not just get to say "UTF-8" or "Unicode" -- there are all sorts of additional issues about comparisons, matching, special issues with particular scripts (including but certainly not limited to so-called "bidirectional" issues), etc., etc. If you are interested in what is involved, see RFC 6530 through 6533 for hints, both about what is involved and what breaks. I recommend directing further discussions to ima@ietf.org if you have additional questions or concerns. john From nobody Thu Feb 17 06:25:58 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEE13A089B for ; Thu, 17 Feb 2022 06:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=YKdJ5d69; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DN+SDwwX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXBh7gFXDqC5 for ; Thu, 17 Feb 2022 06:25:52 -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 23C2A3A089A for ; Thu, 17 Feb 2022 06:25:52 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 9D2D532009DB; Thu, 17 Feb 2022 09:25:50 -0500 (EST) Received: from imap42 ([10.202.2.92]) by compute3.internal (MEProxy); Thu, 17 Feb 2022 09:25:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; bh=B9vTxCVUOeW/3AzvWgGgh5LQZnRaLfyTFXpkJ1 vT+xk=; b=YKdJ5d692vSMIQWlIK27LiszhFhD+rZQWeVQMiguVK0MMt/Dvx9nsf rNGXJUHA9bUKrVv4KykLSuoHHqavtWXWs5Jv7JKbKoHiZCJV5CUY9m3/FgmG+tDl B5IEYDcahxTRpZZgu2a3699pNnoSp/4TQBQu6yEghIlokqfOLWYw+GVrgNZcJhjD vdfdFOu+hRIOVPgXNqw7orX46vov3wgydzYYQXTXxfPJKShtPajdi6X9GZYgQWw0 CowJz0B74TzXDueRvPBI1+UybXAJBnqSuFo5t006iGq9gyRdCR6mj4iYwXKlOQm/ PqhRyvmcuwm4/EXf57hWtGPb3eIQmKAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=B9vTxCVUOeW/3AzvW gGgh5LQZnRaLfyTFXpkJ1vT+xk=; b=DN+SDwwXO0Haf+7UCd6X9MtqvuLcFKkD6 Of42BiMuptPEUS2DbZV9CElTh01q83ssSRAjshHbdEuPPgNNRJjcqlTeqHQ18VT1 VSNFOsjrfF9X2lrTrYE9rzbVa4kRGm7+zYM5z147ijbLS2Bmgk+B1raX4dZ+hw1f 63xF2nSEavSdlvRSVtaBZ6g7bxIOrjqqglf2vJh/SoBZBDqyjC4t2/JAcLjUFSG6 3nhjSkRKAbXifDtvRsYJ9KOZzvF+iiGNGx1iGUrUIyzk1YZY7uVHmLTZYS9esAzb AIkb1+Un8qf0CjnrP7qElX+a7LccWsgfiaeEq4n9KeDh/kGty3A5g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrjeekgdeivdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucggtffrrghtthgvrhhnpeefveetkeeffeetteegtdeghfeigeeiteeghfekiefg udfhgfejvdduudekjeefieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C30FC2180078; Thu, 17 Feb 2022 09:25:49 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4776-gd3673c9443-fm-20220215.001-gd3673c94 Mime-Version: 1.0 Message-Id: <66bead97-dff3-4968-b4eb-473d4ec6e65b@www.fastmail.com> In-Reply-To: References: <20220122042951.379BB355E84F@ary.qy> Date: Thu, 17 Feb 2022 14:25:31 +0000 From: "Alexey Melnikov" To: "John C Klensin" , "John R Levine" , emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Post-Interim question about Section 3.4.2 of draft-ietf-emailcore-rfc5321bis-08 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2022 14:25:57 -0000 Hi John/John, On Sat, Jan 22, 2022, at 5:47 AM, John C Klensin wrote: > --On Friday, January 21, 2022 23:29 -0500 John Levine > wrote: > >> It appears that John C Klensin said: >>> Hi. >>> >>> During Friday's interim meeting, a decision was made >>> (associated with Ticket #4) to drop the last sentence of the >>> first paragraph of Section 3.4.2, which reads (in -08): >>> >>> 'However, in this case, the message header section (RFC >>> 5322 [12]) MUST be left unchanged; in particular, the >>> "From" field of the header section is unaffected.' >>> >>> Checking back over my notes, that sentence appeared in RFC >>> 2821. Checking further, the decision in DRUMS to put it in was >>> apparently based on real-world confusion as to whether a >>> change in the reverse-path was required to be reflected in >>> the mail headers. >> >> If people still think that the bounce address has to match the >> From header, we've got worse problems than this sentence. > > Agreed. But I think we have worse problems than that sentence > even without that condition, so I am trying to be careful and > ask. > >> For the list-id issue, I suppose we could say that existing >> message headers are left unchanged, implying that if you want >> to add new ones, you can. > > That was the case I was concerned about and (as an individual) I > like your suggestion for how to handle it. > > Others? I still think that the replacement text proposed at the interim is better than taking this sentence out, but I am happy with either: This change to MAIL FROM doesn't affect the header section of the message. Best Regards, Alexey From nobody Mon Feb 21 04:28:15 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AF83A07D4 for ; Mon, 21 Feb 2022 04:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=me.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 RC0K6OAwVv6n for ; Mon, 21 Feb 2022 04:28:05 -0800 (PST) Received: from mr85p00im-hyfv06011401.me.com (mr85p00im-hyfv06011401.me.com [17.58.23.191]) (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 6524A3A07BA for ; Mon, 21 Feb 2022 04:28:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1645446485; bh=V6c/KLsVHS4UZy3xBXs4bvZPduCtR815a3plWjtTHyA=; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To; b=rIxCM4qUry8jY7INxGGWt0pSr+9MnakWcBg7685TVU3XmPFF2meG0RtJYop2uZ5Ff +F0sAxwvHiY5lz6jvEAWvegrmcxYfLA6dKlhDZTE3n6c75mMV3m7kMp8k2NzmZfkgh QwWiQEXIwchWyrBw6U1cU+11QRNxLyiznmISIY5e1VjZWmUQAMPd6lRADkNdIvehdy WwX3rpJbX1jcJbWSXVBOE5E7HoZ/46f5x1zLzcDU7mQsDwRlJynWyPSUSR3ShW6aB6 dofG9RpI2/VdmOt6LYI0iO/yfkMCc8a4zzqsFzQ+GEcZFUlRmyYNpmVnKJi0fZqxY+ R8nMg7oKARAQA== Received: from smtpclient.apple (unknown [80.195.222.71]) by mr85p00im-hyfv06011401.me.com (Postfix) with ESMTPSA id A621D357B960 for ; Mon, 21 Feb 2022 12:28:04 +0000 (UTC) From: Sabahattin Gucukoglu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Message-Id: <3196A5AB-5735-45EE-BEB6-BB81B3E6A715@me.com> Date: Mon, 21 Feb 2022 12:27:30 +0000 To: emailcore@ietf.org X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.425,18.0.816,17.0.605.474.0000000_definitions?= =?UTF-8?Q?=3D2022-01-18=5F01:2022-01-14=5F01,2022-01-18=5F01,2020-01-23?= =?UTF-8?Q?=5F02_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 mlxlogscore=960 suspectscore=0 clxscore=1015 spamscore=0 adultscore=0 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2202210074 Archived-At: Subject: [Emailcore] 5321bis-09: Thinking About Interaction of Code 556 with 'postmaster' X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 21 Feb 2022 12:28:11 -0000 Please forgive any possible repetition; I note past discussions that are = adjacent but I think this is new. I am also not at my happiest at = present and have been somewhat remiss in keeping up. If I=E2=80=99m honest, I=E2=80=99m just not a fan of code 556. If = somebody finds it useful, fair enough, but it seems to me to require a = special-case treatment of a non-existent domain, which must be = configured to be useful. It is not clear to me what=E2=80=99s so great = about saying a domain doesn=E2=80=99t exist that can=E2=80=99t be said = of a mailbox in an empty domain that doesn=E2=80=99t exist. =46rom an = implementation point of view, certainly, that would be an attractive = option. After all, more offensive than the failure to distinguish the = non-existence of a domain and a mailbox is the failure to recognise even = the fact that a system is responsible for a domain; such a system might = report a transaction failure with code 554, perhaps to indicate a = refusal to relay mail. But more interesting is the =E2=80=98postmaster=E2=80=99 alias. We have = this text in draft 09 section 4.5.1: Any system that includes an SMTP server supporting mail relaying or delivery MUST support the reserved mailbox "postmaster" as a case- insensitive local name. This postmaster address is not strictly necessary if the server always returns 554 on connection opening (as described in Section 3.1). The requirement to accept mail for postmaster implies that RCPT commands that specify a mailbox for postmaster at any of the domains for which the SMTP server provides mail service, as well as the special case of "RCPT TO:" (with no domain specification), MUST be supported. Of course the most straightforward reading here is that since code 556 = indicates no service, postmaster for such a domain must also be refused. = But postmaster must be accepted without a domain, or for address = literals which refer to this system, and since code 556 when sent by a = public MX can only ever be useful if this system is reached using a = valid address, it is, I suggest, hard not to speculate that postmaster = ought nonetheless to be accepted for such unserviced domains. Is there any thinking on this? Cheers, Sabahattin From nobody Mon Feb 21 11:10:57 2022 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917303A0966 for ; Mon, 21 Feb 2022 11:10:54 -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=HvKMdh72; dkim=pass (2048-bit key) header.d=taugh.com header.b=jWHAGVwF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vykgKuMMkeL for ; Mon, 21 Feb 2022 11:10:49 -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 749053A0C09 for ; Mon, 21 Feb 2022 11:10:49 -0800 (PST) Received: (qmail 59876 invoked from network); 21 Feb 2022 19:10:47 -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=e9e1.6213e3b7.k2202; bh=paBnzH8ctQ1M3l82Fn5JQEvjTYNEOylI3isitAYnDgE=; b=HvKMdh72CtjLasNbMvSKX/B/KVC7tDu0Cy826nss5x6k+HBBcNQ8Z4ziNOLKZhXG41S8WXEXiuOySfNQ1mDvWtHO3uXFc6dXXhrJS940BYnkkzCdhBAMphMVY25JaUfY4kg/6hZgcKQqE2HzXXhOrUme3rnu8zPWSwdkSJOvnCAa+dbFehCIxk8BBVBt7InpjTJEcP/eleiWU6ceX+hbaDX9zelhR5ausRjKSZm+BO+dRgsfXPwtxKTkv7tdravZExw+q1TVMinwXRtEjmuHqCmBNxXtolyLir293vvzJ0FgRzL2TJgHjwIVI1fEV6mNkfFF0y9aX0ddIfS2ya+xcA== 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=e9e1.6213e3b7.k2202; bh=paBnzH8ctQ1M3l82Fn5JQEvjTYNEOylI3isitAYnDgE=; b=jWHAGVwFKge+ArclYTeX/owXc/I7yWVw05a2IVO5pCxp6yYYYHJcaO1IRvoyR/5HhKXGkgQSCYsFmZo1AMGQTKIZDeLigseWtC/Jc7ApeDjzbLR/I3V2HhrMJnIybSr7odlliAw1l8+CnH1vv2t+J/CdhEsDPWmkmng8dlzxs3ABxk9pfl8onRIYCd872Jvy8oOAqFDawaKzeDnz7yKL6Tr9+cLE4AzgLbbt8FA+KPa0NXTdmzbcl0YqOuOKYIUM0zJ9H4fPO0HVgYTHj8YlbgeRIDALPNtMdp4mUxMIx4am8gbul35m1sIKtn/sannNxvWdS/wVW35WP+6gPDx/IA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 21 Feb 2022 19:10:46 -0000 Received: by ary.qy (Postfix, from userid 501) id 970B137BA5CA; Mon, 21 Feb 2022 14:10:45 -0500 (EST) Date: 21 Feb 2022 14:10:45 -0500 Message-Id: <20220221191046.970B137BA5CA@ary.qy> From: "John Levine" To: emailcore@ietf.org In-Reply-To: <3196A5AB-5735-45EE-BEB6-BB81B3E6A715@me.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] 5321bis-09: Thinking About Interaction of Code 556 with 'postmaster' X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 21 Feb 2022 19:10:55 -0000 It appears that Sabahattin Gucukoglu said: >If I’m honest, I’m just not a fan of code 556. If somebody finds it useful, fair enough, but it seems to me to require a special-case >treatment of a non-existent domain, which must be configured to be useful. No, 556 doesn't need any special cases. The likely scenario is that you have a submission server, someone sends RCPT TO: and the submission server sees that example.wtf has a null mx so it knows there's no point to accepting the mail. It doesn't need to look at the mailbox. I suppose it would also be appropriate if the domain does not exist at all, again unrelated to the mailbox. There's also 521 and 554 which say "I am not a mail server." I don't think that we can realistically change that to "I am not a mail server except that I can send postmaster mail somewhere." R's, John From nobody Fri Feb 25 17:38:28 2022 Return-Path: X-Original-To: emailcore@ietf.org Delivered-To: emailcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C25163A12E7; Fri, 25 Feb 2022 17:29:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: emailcore@ietf.org, superuser@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164583895678.24617.15659721762749101778@ietfa.amsl.com> Date: Fri, 25 Feb 2022 17:29:16 -0800 Archived-At: Subject: [Emailcore] emailcore - Requested session has been scheduled for IETF 113 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2022 01:29:26 -0000 Dear Alexey Melnikov, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. emailcore Session 1 (1:00 requested) Friday, 25 March 2022, Afternoon Session I 1230-1430 Room Name: Park Suite 8 size: 145 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/113/sessions/emailcore.ics Request Information: --------------------------------------------------------- Working Group Name: Revision of core Email specifications Area Name: Applications and Real-Time Area Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): Number of Attendees: 50 Conflicts to Avoid: Can't meet: Monday morning, Monday early afternoon, Tuesday morning, Tuesday early afternoon, Wednesday morning, Wednesday early afternoon, Thursday morning, Thursday early afternoon, Friday morning, Friday early afternoon People who must be present: Alexey Melnikov Dr. John C. Klensin Murray Kucherawy Pete Resnick Todd Herr Resources Requested: Special Requests: Late afternoon slot on any day, if possible ---------------------------------------------------------