From nobody Sat Oct 2 21:18:27 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49663A0857 for ; Sat, 2 Oct 2021 21:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0wAMooFqCT2 for ; Sat, 2 Oct 2021 21:18:24 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166CC3A012A for ; Sat, 2 Oct 2021 21:18:23 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mWsxB-000EG6-PD for emailcore@ietf.org; Sun, 03 Oct 2021 00:18:21 -0400 Date: Sun, 03 Oct 2021 00:18:15 -0400 From: John C Klensin To: emailcore@ietf.org Message-ID: <83B4F6B32B95DC44B97BD2E5@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] rfc5321bis G.7.1.1 (Ticket #6); G.7.18, Section 4.2.4.2. -- "no mail accepted" X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 03 Oct 2021 04:18:26 -0000 Hi. In the absence of input from the WG, I've tried to sort out the issues with codes 521, 554, and 566 so that people have text to which to respond. In the note below "rfc5321bis-04" or just "-04" refer to draft-ietf-emailcore-rfc5321bis-04 (coming soon). My assumption is that the intent of RFC 1846 (and hence 7504) was to replace the use of 554 with 521 in the connection-opening state when no mail was being accepted from any source. I have made that substitution. The changes could not have been made in 2821 or 5321 because the relevant standards track specs were not published until some time after the latter. However, in going through the text and thinking about a recent thread on a non-IETF list, it occurs to me that there are actually three or four plausible cases on connection-opening in addition to the "normal" one: (i) The server responding on the SMTP port is actually a stub whose intent is to tell people that no mail is accepted at that address, ever. This was, AFAICT, the focus of RFC 1846 (carried forward into 7504). (ii) The server accepts mail from some sources, under some circumstances, but does not accept it from the particular sending client, origin address. etc. AFAICT from RFC 7504, 554 should continue to be used for that case. (iii) The client should have determined, via the "Null MX" convention specified in RFC 7505, that it should not try to open a connection at all. If it does anyway, code 556 should be returned in preference to 521 (or 554). (iv) The server accepts mail from at least some sources, but is temporarily down or shutting down but something is still able to respond (see below for codes). Now, three questions: (1) Is that description correct? If it is not, comments and/or text that might go into 5321bis would be welcome, but I am not going to hold up -04 waiting. Text suggestions are hence likely to wait until after it is posted. (2) Case (iv) above suggests that there should be a code for temporary service outage in which the "real" server is unavailable. We could use 450 (server shutting down) for that purpose or add a new code (457?). Thoughts? (3) Should we aspire to get enough of the text from RFCs 1846, 7504, and maybe 7505 into 5321bis to obsolete those specs entirely (even if they are used as historical references)? I have made some moves in that direction in -04, but have probably not gone all the way. If so, what is needed that is not in there (as of rfc5321bis-04 if not earlier) already? The alternative would seem to be including text in 5321bis describing its relationship to those specs and increasing confusion about just what specs make up "SMTP". On the other hand, incorporating the substances of 7504, probably 7505, and (at least implicitly) 1846 would, I think, require someone doing implementation reports for 7504 and 7505, but I assume they would be straightforward. -04 and supporting notes follow... soon. best, john From nobody Sat Oct 2 21:24:48 2021 Return-Path: X-Original-To: emailcore@ietf.org Delivered-To: emailcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E15333A0A08; Sat, 2 Oct 2021 21:24:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emailcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <163323508684.31549.3875860456751129696@ietfa.amsl.com> Date: Sat, 02 Oct 2021 21:24:46 -0700 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5321bis-04.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: Sun, 03 Oct 2021 04:24:47 -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-04.txt Pages : 117 Date : 2021-10-02 Abstract: This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. This document replaces the earlier version with the same title in RFC 5321. [[CREF1: Note in Draft: Except for the last sentence, the above is unchanged from 5321 and may need adjusting in the light of RFC 6409 (Message Submission) as an Internet Standard.]] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5321bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-rfc5321bis-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 2 21:30:23 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F5B3A09FF for ; Sat, 2 Oct 2021 21:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMYCxX_uWoDa for ; Sat, 2 Oct 2021 21:30:17 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02CF53A09FD for ; Sat, 2 Oct 2021 21:30:15 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mWt8f-000EHG-Vl for emailcore@ietf.org; Sun, 03 Oct 2021 00:30:13 -0400 Date: Sun, 03 Oct 2021 00:30:07 -0400 From: John C Klensin To: emailcore@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Emailcore] rfc5321bis-04 and notes from minutes X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 03 Oct 2021 04:30:22 -0000 Hi. Pete getting the new version of 5322bis posted motivated me a bit although I've been working on this on and off since the meeting during IETF 111. As I sort of promised (although much later than I intended) I have gone through the minutes [1], updated rfc5321bis accordingly, and posted a new version (-04). For the avoidance of doubt, helping the co-chairs map out what to do next, and in the hope that people will catch errors or omissions and tell me, The bullet points from the minutes that seem to apply to 5321bis are below ("###" is a point from the minutes; "-->" identifies an action in -04 or comment). Any document references there are to -04. The "no mail accepted" issues are discussed in a separate note. Note that several people volunteered to post text or suggestions/ comments that have not appeared: consider yourselves reminded. best, john [1] https://datatracker.ietf.org/meeting/111/materials/minutes-111-emailcore-00 --------------- Note that this list, derived from the minutes, is complementary to, but does not replace, the change log in Appendix H.3.8 of -04. ### Trace header fields --> Agreed at meeting that lone Return=path is ok. There does not seem to be a restriction in 5321bis to be removed. ### Can other fields exist between Trace and Resent-* fields? --> Meeting conclusion: no change needed in 5321bis ### RFC5321 beter(sic) definition of trace fields ### Slide 11 (3.6.3 and 7.6) Better definition of trace header fields --> Awaiting clear instructions from WG. ### Ticket 20: removal of SEND,SAML,SOML --> Done (I think -- see note in G.7.13) ### Ticket 14: Review of size limits --> Ticket closed, no action ### Extension keywords starting with X ### private-use commands with X ### change "MUST be registered unless X" to SHOULD be registered --> Awaiting mailing list discussion and proposed text from Barry ### Ticket 30? Erratum 4055 -> remove reference to SPF/DKIM --> Done. Did not remove quite as much as suggested; want to get a consensus call/ ruling from the chairs. ### Ticket 19 - requirements for domain name and IP address in EHLO --> Deferred to mailing list. Meeting actions to Viktor and maybe Allessandro. Inserted note about pointer to the A/S. ### Use of top-level domains where FQDN is expected not interoperable --> Deferred, awaiting text. Johne Levine took action during meeting ## AOB (Ticket #8 - IANA registry) --> Based on message thread ("Subject: Re: [Emailcore] Ticket #8: Need a registry of header fields that are Ok to add after submission". Discussion on list between 2021-07-27 and 2021-08-05), while we seem to agree on the principle, no conclusion has been reached about where the registry goes nor about which document should do it. No 5321bis action in the -04 draft. From nobody Sun Oct 3 09:04:50 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294243A074D for ; Sun, 3 Oct 2021 09:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-wSGPkpKDKp for ; Sun, 3 Oct 2021 09:04:40 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09B73A03EA for ; Sun, 3 Oct 2021 09:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1633277074; bh=mTSefqj4TP8bmQ9Fx5s4aZ0AbC9OOvf44YI5borz2hA=; l=2332; h=To:References:From:Date:In-Reply-To; b=C2iSCOKa6Q5W+sUM2PprLispNu6L+lnRUPM+vrKop2nao16aWATz6J7Ti09TxqqRS 0k0mCOr3JL9k7F/z/v3e7alZy6xMAuOOEdsP10xuFgixMt4EhDIpcsbJcpDjGJOWa9 vgohqeUpFe3EEqjkkuWZzX+EqgxGtjbKLDX8KssDcYUYCTN3oFhkeG9eyUbnZ 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 00000000005DC053.000000006159D492.000011E4; Sun, 03 Oct 2021 18:04:34 +0200 To: emailcore@ietf.org References: From: Alessandro Vesely Message-ID: Date: Sun, 3 Oct 2021 18:04:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] rfc5321bis-04 and notes from minutes X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 03 Oct 2021 16:04:47 -0000 On Sun 03/Oct/2021 06:30:07 +0200 John C Klensin wrote: > ### Ticket 19 - requirements for domain name and IP address in > EHLO > --> Deferred to mailing list. Meeting actions to Viktor and > maybe Alessandro. Inserted note about pointer to the > A/S. The HELO name is also referenced in the 6th paragraph of Section 4.1.4 "Order of Commands": An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. [[CREF13: [5321bis] [[Note in draft -- proposed change to "An SMTP server MAY verify that the domain name argument in the EHLO command has an address record matching the IP address of the client." ]] However, if the verification fails, the server MUST NOT refuse to accept a message on that basis. Information captured in the verification attempt is for logging and tracing purposes. Note that this prohibition applies to the matching of the parameter to its IP address only; see Section 7.9 for a more extensive discussion of rejecting incoming connections or mail messages. That text is inconsistent with Section 2.1 "Handling of the Domain Argument to the EHLO Command" of the A/S: If the "Domain" argument to the EHLO command does not have an address record in the DNS that matches the IP address of the client, the SMTP server may refuse any mail from the client as part of established anti-abuse practice. Both paragraphs refer to forward DNS matching with the client's IP address, but there are other checks that mail servers frequently carry on, such as reverse DNS matching (Section 3 of RFC 7601) and SPF's "HELO" identity check (Section 2.3 of RFC 7208). For this spec to be generally applicable, I'd strike most of the 6th paragraph of Section 4.1.4. For example, reducing it to a two-liner: An SMTP server MAY verify the domain name argument in the EHLO command. See A/S [xx] for further discussion. Note that such kind of statement may make the preceding 5th paragraph somewhat puzzling if it isn't obvious to the reader that address literals are accepted for authenticated submission only (on whatever port). Since this specification also contains information that is important to its use as mail submission, it may be worth to make that point explicit. Best Ale -- From nobody Sun Oct 3 15:32:17 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AADF73A0D85 for ; Sun, 3 Oct 2021 15:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=JRxEXbTu; dkim=pass (2048-bit key) header.d=taugh.com header.b=2ArdyT2/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3StMn0qJYrik for ; Sun, 3 Oct 2021 15:32:06 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753293A0CD9 for ; Sun, 3 Oct 2021 15:32:05 -0700 (PDT) Received: (qmail 65692 invoked from network); 3 Oct 2021 22:32:02 -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=1009a.615a2f62.k2110; bh=/aeabLd4WMy4kuPldKWigfFaRKCg/qjWczVMy37zH1g=; b=JRxEXbTuKvgVNq6uJcubE+ruceJl1Srg4XgZuUp1TjZYpp3ZOrM8JjbGyR+jM81C6bwY0N7V8HmFtmnaNhRGnHFiNhf7rrtkgR9JpQs9nzRgfXudyqaoBEWTTAFFJ5rCCTGRQNELWo1/s1GWGIh/Bkvxj8XlpwA4NrRNjUzXKboyO9d+v1SwoAYiZerqGreGiyMQ6xb3hz4d3axpOyPx6QeEy2eEupYJm8GJqa0YwQynuzQ1LhEfB3NWT4n7S1BCdpYjWEMbVH0PI1+cd5jAoJe/OWutPQ0ycZT4rQG9rRljOwk8Y70I130NFFE+NW3734KHqgH1W6etdf8qfo7c5g== 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=1009a.615a2f62.k2110; bh=/aeabLd4WMy4kuPldKWigfFaRKCg/qjWczVMy37zH1g=; b=2ArdyT2/6Oa2vL0KzxziSy8Gyqae5GVACmsTzW2ai3+WowhpOX3IId1/UOixlRusn4Fq5N0kUsr71fRCJ3kZ64P+8GgOYVp9dHeLmt6hYdN5X0Sem6ZV8AJrhYsyWJEPn9oF63avP7tuLR/h8eLp5beFhgq4VXhO+zEx6Zh8kLpTvCF5Rsa4AF1gncaIa7F2XPv48K7l27dOIK9AQ+HnCWM9SJFYUXqKnTzkMCH0GwQy4DDi8lqgOX/fIqYSnEwm6XEmAIPVSfV8KZFC9H3OtQpxzTYEf1+q9MDltN6BnJX+9Rq3N1Uqi0J2Rj1lk4WqlvqMhky6grwTAE0D43CnJQ== 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 Oct 2021 22:32:02 -0000 Received: by ary.qy (Postfix, from userid 501) id BDDAC29BDAA1; Sun, 3 Oct 2021 18:32:00 -0400 (EDT) Date: 3 Oct 2021 18:32:00 -0400 Message-Id: <20211003223201.BDDAC29BDAA1@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: john-ietf@jck.com In-Reply-To: <83B4F6B32B95DC44B97BD2E5@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] rfc5321bis G.7.1.1 (Ticket #6); G.7.18, Section 4.2.4.2. -- "no mail accepted" X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 03 Oct 2021 22:32:15 -0000 It appears that John C Klensin said: >Now, three questions: > >(1) Is that description correct? Looks correct to me. >(2) Case (iv) above suggests that there should be a code for >temporary service outage in which the "real" server is >unavailable. We could use 450 (server shutting down) for that >purpose or add a new code (457?). Thoughts? I think 450 is appropriate. Whatever mailbox you want, it's unavailable at the moment. >(3) Should we aspire to get enough of the text from RFCs 1846, >7504, and maybe 7505 into 5321bis to obsolete those specs >entirely (even if they are used as historical references)? Unless it's a ridiculous amount of work, I would prefer that we decrease the number of RFCs that people have to read to implement a working SMTP package, so yes. R's, John From nobody Mon Oct 4 06:57:54 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EB13A0691 for ; Mon, 4 Oct 2021 06:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0-6w-rhMxoF for ; Mon, 4 Oct 2021 06:57:45 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id D1FBF3A060D for ; Mon, 4 Oct 2021 06:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1633355863; d=isode.com; s=june2016; i=@isode.com; bh=UsGOZtammKwwGAYlgPvSJg8TVQYifbyRFP1E24bZTYM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=dw264bMHvntWYcbKwJOuKzPP4UJs1tr6TdFURjtpyBkL5T0iBlNisOhAGSdMPNQcyhh3aO grslpwgZUlPprZmaXgHZQlPGMczRL26kZja9spevfuHPXL5WNAbCbjwx7ImnzSMIMajdD3 mVF9K5ZCIPinjlJ4d7N/ZWlXxyAT7ks=; Received: from [192.168.1.222] (host5-81-100-26.range5-81.btcentralplus.com [5.81.100.26]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 4 Oct 2021 14:57:42 +0100 To: emailcore@ietf.org From: Alexey Melnikov Message-ID: <123b9a73-fd5b-3c87-ec82-432b2da0e6da@isode.com> Date: Mon, 4 Oct 2021 14:57:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: [Emailcore] Closing ticket #48 (G.15 Rename/expand section 7.8 to "Resistance to Attacks and Local Operational Requirements") X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 04 Oct 2021 13:57:52 -0000 Dear WG participants, Suggestion in this ticket were implemented in rfc5321-03 and there were no further comments. I will thus close this ticket. Best Regards, Alexey From nobody Mon Oct 4 07:01:55 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F453A0768 for ; Mon, 4 Oct 2021 07:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=dvgFfUOX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ij+oROYJ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8fItOPYGQWX for ; Mon, 4 Oct 2021 07:01:30 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C283A074E for ; Mon, 4 Oct 2021 07:01:30 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 387145C0192; Mon, 4 Oct 2021 10:01:30 -0400 (EDT) Received: from imap42 ([10.202.2.92]) by compute6.internal (MEProxy); Mon, 04 Oct 2021 10:01:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=2IQCWUkck6X7Dh/KeMvk35x0LzjWyVr N3haaArtr1XY=; b=dvgFfUOX7NLqmSN3NRCZ4LOSbAO2kEJ8wXJ7KwHoV21nTVn bha9Ktwz1CXOG7OJ2ZXZntLLa4ZMWOAC9RQi/QE5FVK+Mn9NhDbbvv8U3+dk5z90 h3ZLgRj+oLqhoRsj8toYryaSfxZnVLGArbp2A/KtgoRMR0TawR7WbWxPC+t8qbud V7ehWgrw4E+KJjxvKkf1CidY5MP/DpZ5M1o6ZzNjp8t2wc8s3c4lJmer8J2hPjUr 5pRo42Gx2koYMiAaDYi3uNc/+c8gI2US5N8psk0eZSRDsnvaT4dWkswXZnQMHd0y QuLBYeYlrVP2iuwMeJHfo5VLukx33bd2IIhUOqA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=2IQCWU kck6X7Dh/KeMvk35x0LzjWyVrN3haaArtr1XY=; b=ij+oROYJMlIZC36LXhNfb+ 21qOk+bxUtEDxqsU0vGHqSSIalQXhHfnCQXPEe6COJEfFEl+kRolvUzi/OHJpF6k lNgu7+XLpiNd/xpZw1XiNbZxywadtl20dOK9WVTC0duyZFJsvoIkbj2rxqpColng wkdOjoCh406lU8OYAJvM/Yy1HRILf1oarPSGDAcD2U7IdHUP7uSNPkaD5yVoTLAd UECnzmLjdVEnK0/UECRrpsnmzuPOvA4FNFRbdZGVtwT7+xz5MrFOLQp9/u6PnEN6 yiRSHMhk6YkISGKjRDct7oveqVq0mPzcZoNYeKUOrj+KSBOM2TPcj8xZBfy7CRCA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudelvddgieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuggftrfgrthhtvghrnhepiedtueehtdfhvedvtefhgeeludefuefgvdejvdeh heefveeutdegudefgeduhfdtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A52162180075; Mon, 4 Oct 2021 10:01:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1322-g921842b88a-fm-20210929.001-g921842b8 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20201007204619.243722312B5C@ary.qy> Date: Mon, 04 Oct 2021 15:01:08 +0100 From: "Alexey Melnikov" To: "Pete Resnick" , "John R Levine" Cc: emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] =?utf-8?q?Closing_the_loop_on_ticket_=2339_=28Was=3A?= =?utf-8?q?_erratum_2950=2C_I-D_Action=3A_draft-ietf-emailcore-rfc5322bis-?= =?utf-8?q?00=2Etxt=29?= X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 04 Oct 2021 14:01:37 -0000 On Thu, Sep 30, 2021, at 4:01 AM, Pete Resnick wrote: > Found this old message while finishing up the new version of 5322bis: > > On 7 Oct 2020, at 15:46, John Levine wrote: > >> In article <160200528245.32425.2250633164754152213@ietfa.amsl.com> you >> write: >>> Title : Internet Message Format >>> Author : Peter W. Resnick >>> Filename : draft-ietf-emailcore-rfc5322bis-00.txt >>> Pages : 56 >>> Date : 2020-10-06 >> >> In the interest of moving things along, I see a question about >> whether we should change the "fields" ABNF per erratum 2950. >> >> That one's easy: no. The author of the erratum misunderstands how ABNF >> works. In particular there is no promise that ABNF will produce a >> unique parse for any valid string, only that it will match every valid >> string. > > While no harm is done by changing the "*" to "1*" before the resent > fields (since the enclosing production is a "*" and the other portion of > that production is also optional), it is also unnecessary for the > reasons John notes. So I suggest closing issue, changing the erratum to > "Reject" (giving this explanation), and making no change in the > document. > > Updated the comments on this in -02 (coming out in just a few minutes). Agreed. I closed the ticket. From nobody Mon Oct 4 07:15:54 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01403A079D for ; Mon, 4 Oct 2021 07:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=ndvUsHoG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cW3TEhwE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aaa3zWU_vmgw for ; Mon, 4 Oct 2021 07:15:41 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E793A083D for ; Mon, 4 Oct 2021 07:15:23 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B997B5C01B9; Mon, 4 Oct 2021 10:15:22 -0400 (EDT) Received: from imap42 ([10.202.2.92]) by compute6.internal (MEProxy); Mon, 04 Oct 2021 10:15:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=vIGztLU7zjrGIfKxnWX1n3uuLL8fSCu lpYrLGbECLLQ=; b=ndvUsHoGXNmao54Hx+EMnAwWUvAnch24zQl3W6NCPHzLDBi pd3i3WM+1vsMgfZvC9aUP6eRR7tkkBXfdBe2U/bz1b5ITM+N5hbkeLHIq4gfyOLm nJ4bfENsFtaOu8Pg1758xE2doorgJ+Ov44WQXezEUvUF+NS2eiaCN2cVHwYOiORt uOBSmhcZeaZlgJ4uLBzy4pSCD7NEIjhcPrhro+oAYuZaacotpE6bvIvh+mCGIEBb +B80dSC2vPOaGX94HGB79J0fwfkjFQECkRgl21RCyvhYpsn6rHePuJjzeravglzK H+zbASYjbrmD2XTCoPqqMLXDfWug0VjhxhQm/uw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=vIGztL U7zjrGIfKxnWX1n3uuLL8fSCulpYrLGbECLLQ=; b=cW3TEhwED8PUYvb4pHhkPK zVsdbCN8Nrbhb7u2Z9wjRjLYx3xL9bX6K6BGZTgr7U5HqZ3wjHMSJdwOrdEL77sp lOMKEXBE5qaX8uKn3cbV3bg2lXfUlqiqONpABHsftc4Zg1tg2ZGn6XmiCOCrJ1YV fRNTzbm1rsvgaguVZDwfS5azhXNPgA3QmYO37WQmWm6PKA6QA9m+6XXfw0A4Q/a3 WCtuzdF38ziOsBsY0tzNRzqZrWFqAWwvPtVUN7z0i7wD45T7BPIQgqpkmhO48ut1 anaEE9P/Lk+lRGsDEUfN2BDQF+demR9/9q/fan/Q4KeUz2brpGvZUuSA6ab7r6+w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudelvddgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuggftrfgrthhtvghrnheplefftdfghfevueduiefhffejlefgtdduhfdvtedt heeftedthfeghfefiefggeffnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhho vhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 93DC52180075; Mon, 4 Oct 2021 10:15:22 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1322-g921842b88a-fm-20210929.001-g921842b8 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 04 Oct 2021 15:15:01 +0100 From: "Alexey Melnikov" To: "John C Klensin" , "Todd Herr" Cc: emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] rfc5321bis-04 and notes from minutes X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 04 Oct 2021 14:15:51 -0000 Hi John, Thank you for the summary. I commented on your list below. On Sun, Oct 3, 2021, at 5:30 AM, John C Klensin wrote: > Hi. Pete getting the new version of 5322bis posted motivated > me a bit although I've been working on this on and off since > the meeting during IETF 111. > > As I sort of promised (although much later than I intended) I > have gone through the minutes [1], updated rfc5321bis > accordingly, and posted a new version (-04). For the avoidance > of doubt, helping the co-chairs map out what to do next, and in > the hope that people will catch errors or omissions and tell > me, The bullet points from the minutes that seem to apply to > 5321bis are below ("###" is a point from the minutes; "-->" > identifies an action in -04 or comment). Any document > references there are to -04. > > The "no mail accepted" issues are discussed in a separate note. > > Note that several people volunteered to post text or > suggestions/ comments that have not appeared: consider > yourselves reminded. > > best, > john > > [1] > https://datatracker.ietf.org/meeting/111/materials/minutes-111-emailcore-00 > > > --------------- > > Note that this list, derived from the minutes, is complementary > to, but does not replace, the change log in Appendix H.3.8 of > -04. > > ### Trace header fields > --> Agreed at meeting that lone Return=path is ok. There > does not seem to be a restriction in 5321bis to be > removed. > > ### Can other fields exist between Trace and Resent-* fields? > --> Meeting conclusion: no change needed in 5321bis Right. I think a change in 5322bis is needed now. I will followup separately. > ### RFC5321 beter(sic) definition of trace fields > ### Slide 11 (3.6.3 and 7.6) Better definition of trace header > fields > --> Awaiting clear instructions from WG. I think there were specific suggestions in my slides for IETF 111, but I will followup on this separately. > ### Ticket 20: removal of SEND,SAML,SOML > --> Done (I think -- see note in G.7.13) There is one more change to be done, as discussed on the mailing list. I will send you a separate email. > ### Ticket 14: Review of size limits > --> Ticket closed, no action Yes. > ### Extension keywords starting with X > ### private-use commands with X > ### change "MUST be registered unless X" to SHOULD be > registered > --> Awaiting mailing list discussion and proposed text from > Barry I just reminded Barry as well. > ### Ticket 30? Erratum 4055 -> remove reference to SPF/DKIM > --> Done. Did not remove quite as much as suggested; want > to get a consensus call/ ruling from the chairs. Todd is in charge of this ticket, I will ask him to comment. > ### Ticket 19 - requirements for domain name and IP address in > EHLO > --> Deferred to mailing list. Meeting actions to Viktor and > maybe Allessandro. Inserted note about pointer to the > A/S. I think there is specific text suggested in the ticket already. Todd should comment as the ticket owner. > ### Use of top-level domains where FQDN is expected not > interoperable > --> Deferred, awaiting text. Johne Levine took action > during meeting I think this was addressed in A/S as per suggestion from John L. > ## AOB (Ticket #8 - IANA registry) > --> Based on message thread ("Subject: Re: [Emailcore] > Ticket #8: Need a registry of header fields that are Ok > to add after submission". Discussion on list between > 2021-07-27 and 2021-08-05), while we seem to agree on the > principle, no conclusion has been reached about where the > registry goes nor about which document should do it. No > 5321bis action in the -04 draft. I will review and followup on this. Best Regards, Alexey From nobody Mon Oct 4 07:21:10 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A323A07D8 for ; Mon, 4 Oct 2021 07:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE9EQMKQgqWX for ; Mon, 4 Oct 2021 07:21:03 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A323A07AA for ; Mon, 4 Oct 2021 07:21:03 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mXOpx-000H0w-Bw; Mon, 04 Oct 2021 10:21:01 -0400 Date: Mon, 04 Oct 2021 10:20:55 -0400 From: John C Klensin To: Alessandro Vesely , emailcore@ietf.org Message-ID: <5DEAF8141B7F85DC43B50B57@PSB> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] rfc5321bis-04 and notes from minutes X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 04 Oct 2021 14:21:08 -0000 Alessandro, I'm going to sit back for a while and let the WG discuss most of the issues you have raised (or decide to not do so). However, one comment: At least from my perspective, the reason the charter was written to give priority to 5321bis and 5322bis (I note the charter was never revised to include benchmarks) was, in large measure, to avoid getting into race conditions or other arguments about inconsistencies between 5321bis or 5322bis and the A/S. So I would hope that we can concentrate on what the two base documents should say (or not say) and getting that right and inserting forward pointers to the A/S when appropriate. We should, I think, concentrate on finishing those base docs and then bringing the A/S into alignment with both those forward pointers and the base document text. If others (especially the WG Chairs) disagree, we should probably get that sorted out really soon. best, john --On Sunday, October 3, 2021 18:04 +0200 Alessandro Vesely wrote: > On Sun 03/Oct/2021 06:30:07 +0200 John C Klensin wrote: >> ### Ticket 19 - requirements for domain name and IP address in >> EHLO >> --> Deferred to mailing list. Meeting actions to Viktor >> and maybe Alessandro. Inserted note about pointer to the >> A/S. > > > The HELO name is also referenced in the 6th paragraph of > Section 4.1.4 "Order of Commands": > > An SMTP server MAY verify that the domain name argument in > the EHLO > command actually corresponds to the IP address of the > client. > [[CREF13: [5321bis] [[Note in draft -- proposed change to > "An SMTP > server MAY verify that the domain name argument in the > EHLO command > has an address record matching the IP address of the > client." ]] > However, if the verification fails, the server MUST NOT > refuse to > accept a message on that basis. Information captured in > the > verification attempt is for logging and tracing purposes. > Note that > this prohibition applies to the matching of the parameter > to its IP > address only; see Section 7.9 for a more extensive > discussion of > rejecting incoming connections or mail messages. > > That text is inconsistent with Section 2.1 "Handling of the > Domain Argument to the EHLO Command" of the A/S: > > If the "Domain" argument to the EHLO command does not have > an address > record in the DNS that matches the IP address of the > client, the SMTP > server may refuse any mail from the client as part of > established > anti-abuse practice. > > Both paragraphs refer to forward DNS matching with the > client's IP address, but there are other checks that mail > servers frequently carry on, such as reverse DNS matching > (Section 3 of RFC 7601) and SPF's "HELO" identity check > (Section 2.3 of RFC 7208). For this spec to be generally > applicable, I'd strike most of the 6th paragraph of Section > 4.1.4. For example, reducing it to a two-liner: > > An SMTP server MAY verify the domain name argument in the > EHLO > command. See A/S [xx] for further discussion. > > Note that such kind of statement may make the preceding 5th > paragraph somewhat puzzling if it isn't obvious to the reader > that address literals are accepted for authenticated > submission only (on whatever port). Since this specification > also contains information that is important to its use as mail > submission, it may be worth to make that point explicit. > > > Best > Ale > -- From nobody Mon Oct 4 07:38:03 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEED3A0896 for ; Mon, 4 Oct 2021 07:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=episteme.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 VitYm3jeD3CQ for ; Mon, 4 Oct 2021 07:37:48 -0700 (PDT) Received: from helm.helm.episteme.net (helm.helm.episteme.net [209.51.32.195]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 118413A084F for ; Mon, 4 Oct 2021 07:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=episteme.net; s=mail; t=1633358266; bh=S3bsIybkBJyXLZwzyV9gAA92UfCXHNi08hM5aqAgE4Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=IOXDWD71KFy/ifKtYtwC32XEAE+GQ3QlNWOn5Ss4cnSU5ODSxgYh88eWna4nwWDDb qc0zgIYs2/lu9IfTkE7N6+fq+hvHGmHkvkHZr0gWOVLT64wxhd4KTT8VRTYppI2f/7 Xm+2mwqSaNtjrAjx/AoZJmwfBUrsmopqO9giSjnM= From: Pete Resnick To: Alexey Melnikov Cc: John C Klensin , Todd Herr , emailcore@ietf.org Date: Mon, 04 Oct 2021 09:37:42 -0500 X-Mailer: MailMate (1.14r5820) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_6053270B-7391-4A54-B0FB-E2305C7B19B9_=" Archived-At: Subject: Re: [Emailcore] rfc5321bis-04 and notes from minutes X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 04 Oct 2021 14:38:01 -0000 --=_MailMate_6053270B-7391-4A54-B0FB-E2305C7B19B9_= Content-Type: text/plain; format=flowed; markup=markdown On 4 Oct 2021, at 9:15, Alexey Melnikov wrote: >> ### Trace header fields >> >> --> Agreed at meeting that lone Return=path is ok. There >> >> does not seem to be a restriction in 5321bis to be >> >> removed. >> >> ### Can other fields exist between Trace and Resent-* fields? >> >> --> Meeting conclusion: no change needed in 5321bis > > Right. I think a change in 5322bis is needed now. I will followup > separately. I believe the current text in 5322bis-02 is what we agreed to, and anything else was left for the AS. Do I have that wrong? pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best --=_MailMate_6053270B-7391-4A54-B0FB-E2305C7B19B9_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

On 4 Oct 2021, at 9:15, Alexey Melnikov wrote:

Trace header fields

--> Agreed at meeting that lone Return=3Dpath is ok. = There

does not seem to be a restriction in 5321bis to be

removed.

Can other fields exist between Trace and Re= sent-* fields?

--> Meeting conclusion: no change needed in 5321bis

Right. I think a change in 5322bis is needed now. I will = followup separately.

I believe the current text in 5322bis-02 is what we agree= d to, and anything else was left for the AS. Do I have that wrong?

pr

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

--=_MailMate_6053270B-7391-4A54-B0FB-E2305C7B19B9_=-- From nobody Mon Oct 4 08:34:08 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17863A09EB for ; Mon, 4 Oct 2021 08:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRSrm-GJkaQj for ; Mon, 4 Oct 2021 08:33:51 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id AC6043A096C for ; Mon, 4 Oct 2021 08:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1633361630; d=isode.com; s=june2016; i=@isode.com; bh=tiFyvzOY8e5GxG0Je5GMQ1I/sRLU92o1VltFN44+zb4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=UpXj+20z8AG9NNuyRGIiFv0Tcms0FPpk6id24WpUL03Etg9HrUtO/lCOTovgTovTuyQYay drdMfbBt64eKLJzHnsLUn/py/X72vPggVJG37BuM7+MdBMYP+D/N1lIdfhdVCHf3s1Ojbi p9rx6oSptvDGW2+FC9JEyIPtI7vhtbE=; Received: from [192.168.1.222] (host5-81-100-26.range5-81.btcentralplus.com [5.81.100.26]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 4 Oct 2021 16:33:49 +0100 To: John C Klensin Cc: emailcore@ietf.org From: Alexey Melnikov Message-ID: <914b4691-cea6-1a88-855d-0f9b19687e4a@isode.com> Date: Mon, 4 Oct 2021 16:33:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [Emailcore] Ticket #7: Better definition for trace header fields (rfc5321bis changes only) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 04 Oct 2021 15:34:06 -0000 Hi John, Below I am summarizing proposed changed to 5321bis to address ticket #7.=20 The changes only address trace header fields and other tickets remain=20 unaffected. 1) Move the current content of Section 4.4 into Section 4.4.1. Rename it=20 to be "Receive header field" (or similar). 2) Add the following paragraph to the now empty (other than the new=20 subsection) 4.4: =C2=A0 Trace information is used to provide an audit trail of message handl= ing. =C2=A0 In addition, it indicates a route back to the sender of the message. 3) In Section 2.3.10, 1st paragraph, last sentence: =C2=A0=C2=A0 A "relay" SMTP =C2=A0=C2=A0 system (usually referred to just as a "relay") receives mail f= rom an =C2=A0=C2=A0 SMTP client and transmits it, without modification to the mess= age =C2=A0=C2=A0 data other than adding trace information Insert cross reference to section 4.4 here. =C2=A0=C2=A0 , to another SMTP server for =C2=A0=C2=A0 further relaying or for delivery. 4) In Section 3.6.3 (Message Submission Servers as Relays), last paragraph: =C2=A0=C2=A0 As discussed in Section 6.4, a relay SMTP has no need to inspe= ct or =C2=A0=C2=A0 act upon the header section or body of the message data and MU= ST NOT =C2=A0=C2=A0 do so except to add its own "Received:" header field (Section = 4.4) Change "Section 4.4" to "Section 4.4.1". Also add "and possibly other=20 trace header fields" after it. =C2=A0=C2=A0 and, optionally, to attempt to detect looping in the mail syst= em (see =C2=A0=C2=A0 Section 6.3).=C2=A0 Of course, this prohibition also applies t= o any =C2=A0=C2=A0 modifications of these header fields or text (see also Section= 7.9). 5) In Section 7.6: =C2=A0=C2=A0 In some circumstances, such as when mail originates from withi= n a LAN =C2=A0=C2=A0 whose hosts are not directly on the public Internet, trace =C2=A0=C2=A0 ("Received") header fields produced in conformance with this Insert "e.g." before "Received". =C2=A0=C2=A0 specification may disclose host names and similar information = that =C2=A0=C2=A0 would not normally be available.=C2=A0 This ordinarily does no= t pose a =C2=A0=C2=A0 problem, but sites with special concerns about name disclosure= should =C2=A0=C2=A0 be aware of it.=C2=A0 Also, the optional FOR clause should be = supplied =C2=A0=C2=A0 with caution or not at all when multiple recipients are involv= ed lest =C2=A0=C2=A0 it inadvertently disclose the identities of "blind copy" recip= ients =C2=A0=C2=A0 to others. Best Regards, Alexey From nobody Mon Oct 4 08:40:47 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007EF3A08FC for ; Mon, 4 Oct 2021 08:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=ANJ1c6No; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eCw1dMaw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4UYyq8k3ZYX for ; Mon, 4 Oct 2021 08:40:37 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49F4D3A0907 for ; Mon, 4 Oct 2021 08:40:37 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A960C5C007B; Mon, 4 Oct 2021 11:40:36 -0400 (EDT) Received: from imap42 ([10.202.2.92]) by compute6.internal (MEProxy); Mon, 04 Oct 2021 11:40:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=+dYy+zeEY0xiRLu8KyEyPspWpEYw8wA U5Jd4/qvzzvo=; b=ANJ1c6NoM+MboB2jSq1oJBgf74v6Lha95HD3ZL+h42LgpqV o7GBEvL35QgseYZLxSD9qtYttEYvCe6p1JI3kJunC+Xi/pgTQy732fFlxjtNGHdZ DW9ELOUoyedMn3d4UGh177L3J0hcSsSGQvwvCGLgDrEMqiCdlQVX/f6v4bTTMhc3 CK1Vnu33kHOBRHvsYtr8Nvjo0gJ0jXzHmANPCyPrs98VSsfQh8xUf1ftKFS/6uV3 rF4eoQQk99v2qQAvd4Owb8kLaHroMuECoexukI7piGQH7eEmLRPjgJy85yo1tVLW XlQVcWwjCeaSDOD6qYUGD+LBStuhEAaKQQ6iqZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=+dYy+z eEY0xiRLu8KyEyPspWpEYw8wAU5Jd4/qvzzvo=; b=eCw1dMawi3PHPqgPzMynvN JqXYly4B67wP+2opx1S6egW2JEgzi2m2SjG3heorMyuERXguImu0RINQcmY61Mxi KMNt76ydC38fuBkulAAbm1ZyhbuiXUnPxboFHzkJ2EGIOECmK5lRnhcn0RwNrUV9 LIwGqSFfUivT90Xri+xJLA9lFG0QYyeBwXGD8g/Glj/ZmwW7lb4stwbWywrTdLFR 26Boj7NbcDddzrCorGnujA5W5DL/X8QVYaobgJbO8ZRdjwYLes4HlFoALhOoa8Tf PQR5SgQyLa4vf/rzQluz2t4pLDRz5qx+e1foR2Nj0G4fnlSjokGGxrs1uIeNdYxg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudelvddgkeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuggftrfgrthhtvghrnhepfeeggfeiudejgedtledugfduvdfgteefiedtveet udekfeegtefgheeuiedvgfeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7E18A2180075; Mon, 4 Oct 2021 11:40:36 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1322-g921842b88a-fm-20210929.001-g921842b8 Mime-Version: 1.0 Message-Id: <2bebe700-2ad6-449a-9ad3-f4eb344b0438@www.fastmail.com> In-Reply-To: References: Date: Mon, 04 Oct 2021 16:40:14 +0100 From: "Alexey Melnikov" To: "Pete Resnick" Cc: emailcore@ietf.org Content-Type: multipart/alternative; boundary=1a96ab3d906849e1b87530cef788b9e2 Archived-At: Subject: Re: [Emailcore] rfc5321bis-04 and notes from minutes X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 04 Oct 2021 15:40:44 -0000 --1a96ab3d906849e1b87530cef788b9e2 Content-Type: text/plain Hi Pete, Your change was almost perfect ;-). But see below, On Mon, Oct 4, 2021, at 3:37 PM, Pete Resnick wrote: > On 4 Oct 2021, at 9:15, Alexey Melnikov wrote: > >>> Trace header fields >>> >>> --> Agreed at meeting that lone Return=path is ok. There >>> >>> does not seem to be a restriction in 5321bis to be >>> >>> removed. >>> >>> Can other fields exist between Trace and Resent-* fields? >>> >>> --> Meeting conclusion: no change needed in 5321bis >>> >> Right. I think a change in 5322bis is needed now. I will followup separately. >> > I believe the current text in 5322bis-02 is what we agreed to, and anything else was left for the AS. Do I have that wrong? > IMHO, you've included a change that was not agreed. In Section 3.6 ABNF of "fields" you remove "*optional-field" after "trace". I think it should be added back, as we had a discussion about whether optional-fields which are not trace fields are allowed between trace section and resent header fields. I believe the discussion at IETF 111 concluded that allowing for this is fine. Best Regards, Alexey --1a96ab3d906849e1b87530cef788b9e2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Pete,

Your change was almost perfect ;-). But see = below,

On Mon, Oct 4, 2021, at 3:37 PM, Pet= e Resnick wrote:

On 4 Oct 2021, at 9:15, Alexey Melnikov wrote:

<= blockquote style=3D"border-left-width:2px;border-left-style:solid;color:= rgb(153, 153, 153);margin-top:0px;margin-right:0px;margin-bottom:5px;mar= gin-left:0px;padding-left:5px;border-left-color:rgb(153, 153, 153);">Trace header fields

= --> Agreed at meeting that lone Return=3Dpath is ok. There

does not seem to be a restriction in 5321bis to be

=

removed.

Can other= fields exist between Trace and Resent-* fields?

--> Meeting conclusion: no change needed in 5321bis

Right. I think a change in 5322bis is needed now. I = will followup separately.

I believe = the current text in 5322bis-02 is what we agreed to, and anything else w= as left for the AS. Do I have that wrong?

IMHO, you've included a change that was not agreed. In Section 3.= 6 ABNF of "fields" you remove "*optional-field" after "trace". I think i= t should be added back, as we had a discussion about whether optional-fi= elds which are not trace fields are allowed between trace section and re= sent header fields. I believe the discussion at IETF 111 concluded that = allowing for this is fine.

Best Regards,
Alexey

--1a96ab3d906849e1b87530cef788b9e2-- From nobody Mon Oct 4 10:05:00 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199DB3A09E5 for ; Mon, 4 Oct 2021 10:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=episteme.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 FIbikUUIoSgM for ; Mon, 4 Oct 2021 10:04:53 -0700 (PDT) Received: from helm.helm.episteme.net (helm.helm.episteme.net [209.51.32.195]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 306B83A09DF for ; Mon, 4 Oct 2021 10:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=episteme.net; s=mail; t=1633367091; bh=VOJQClVMdnLpidEFc0diu9OrME/X2D4NHyZ0l7AytGs=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=XB4897E3YrwStu/AuLffdVpvRtr0pDoXZDl6UE95XTVYZqvLMsJ5Eai04ZC+VWEMU TneKQgxtoch1UtGSNQjuIwU96puvLAw5XGslb5cr6qa//99lhRNQJeHp37rInaqrly UVTIcXLbGh/Kihg+TmvwoCxfTjKmn7hE7Onk7lMw= From: Pete Resnick To: Alexey Melnikov Cc: emailcore@ietf.org Date: Mon, 04 Oct 2021 12:04:47 -0500 X-Mailer: MailMate (1.14r5820) Message-ID: <8806D8AA-8A7D-48F8-8788-62F5C274C213@episteme.net> In-Reply-To: <2bebe700-2ad6-449a-9ad3-f4eb344b0438@www.fastmail.com> References: <2bebe700-2ad6-449a-9ad3-f4eb344b0438@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Emailcore] rfc5321bis-04 and notes from minutes X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 04 Oct 2021 17:04:59 -0000 On 4 Oct 2021, at 10:40, Alexey Melnikov wrote: > IMHO, you've included a change that was not agreed. In Section 3.6 > ABNF of "fields" you remove "*optional-field" after "trace". I think > it should be added back, as we had a discussion about whether > optional-fields which are not trace fields are allowed between trace > section and resent header fields. I believe the discussion at IETF 111 > concluded that allowing for this is fine. Ah, OK. I misunderstood. Just to confirm: Though optional-field is now allowed *in* trace, and therefore syntactically can appear between blocks of trace and resent (because return and received are optional in trace), we also want optional-field to syntactically appear *between* trace and resent to make it clear that there can be optional-fields that are part of trace and optional-fields that are not part of trace. That seems perfectly reasonable. I just want to make sure what was agreed. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Mon Oct 4 10:15:44 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7AC3A09FD for ; Mon, 4 Oct 2021 10:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=AtZM9xuB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nGIbye1X Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8RFNl0KUnv7 for ; Mon, 4 Oct 2021 10:15:35 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C683A09F9 for ; Mon, 4 Oct 2021 10:15:35 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 81E6D5C01A6; Mon, 4 Oct 2021 13:15:31 -0400 (EDT) Received: from imap42 ([10.202.2.92]) by compute6.internal (MEProxy); Mon, 04 Oct 2021 13:15:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=aEg2Usvjvu20W38L7uSzSmw37mXWOAD PnZB+EvjvrlM=; b=AtZM9xuBdEv1/LFDYmphh8ICHPS5R2p01efRNm6y2AMTA5/ GWLoTO3OBrFv+er+BobRh/MOaTgS/dFCUdUC4Q8XcHGN9LrALxXEOp+TcPjwr5CT Xs40979uJMR/GxZK834Po4A+89DK+X2qC8mJReli3aRuhyMGHtecRHVg18/nJDOZ lMdNixjwBDwvaBLi/hGucdJw0Lfbbk+dwj+HMoqR74+JnCNR/pqxDquQvLdjb15d nej3OuJI/3QUwZz7BUXcI0P1RZW6KE6GRNvu3ZIHHUB2nZ3ht8wBDGPyKNUZxU2E eXeCoFByi/aVOspw9wyMXOUFqtcBzX4akA9oR1w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=aEg2Us vjvu20W38L7uSzSmw37mXWOADPnZB+EvjvrlM=; b=nGIbye1XceZTCdRO/Z2h6R dq4Fg+RymIcy51eOlms6fEFuv8ty+EBBQ5RtqkhSwrwSOJZKOpWfWPQwlioWVkzP pC6gffRPDuwdg5tPnuy7G/965432/FCdpRf+VDkdtNWoEhh5GBteBu09pZ2BvmvD wIMLFTe8dHDARc1sC/D7R3SjSu2g8khPR/cHiRoxq50ZLrq0LeIPfHW0vms2kmuG HjLMH5QiXGlTCVTVwtDj7dWCe/8jpXpsF/Iggi9SQ3pA6dVojwN49MWcxGNL1T4l UG+aypEjUdmUyWmvQNaaEhUo4kl+A13HOuroj5Ajkb1jL5KmV0orxrrjxdTGIrrA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudelvddguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehl vgigvgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhmqeenucggtffrrghtthgvrhhnpeefveetkeeffeetteegtdeghfeigeeiteeghfek iefgudfhgfejvdduudekjeefieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 745172180075; Mon, 4 Oct 2021 13:15:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1322-g921842b88a-fm-20210929.001-g921842b8 Mime-Version: 1.0 Message-Id: <78f958c0-c9a4-40e0-9fd6-7f589b78cf42@www.fastmail.com> In-Reply-To: <8806D8AA-8A7D-48F8-8788-62F5C274C213@episteme.net> References: <2bebe700-2ad6-449a-9ad3-f4eb344b0438@www.fastmail.com> <8806D8AA-8A7D-48F8-8788-62F5C274C213@episteme.net> Date: Mon, 04 Oct 2021 18:15:10 +0100 From: "Alexey Melnikov" To: "Pete Resnick" Cc: emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] rfc5321bis-04 and notes from minutes X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 04 Oct 2021 17:15:41 -0000 Hi Pete, On Mon, Oct 4, 2021, at 6:04 PM, Pete Resnick wrote: > On 4 Oct 2021, at 10:40, Alexey Melnikov wrote: > >> IMHO, you've included a change that was not agreed. In Section 3.6 >> ABNF of "fields" you remove "*optional-field" after "trace". I think >> it should be added back, as we had a discussion about whether >> optional-fields which are not trace fields are allowed between trace >> section and resent header fields. I believe the discussion at IETF 111 >> concluded that allowing for this is fine. > > Ah, OK. I misunderstood. Just to confirm: Though optional-field is now > allowed *in* trace, and therefore syntactically can appear between > blocks of trace and resent (because return and received are optional in > trace), we also want optional-field to syntactically appear *between* > trace and resent to make it clear that there can be optional-fields that > are part of trace and optional-fields that are not part of trace. That > seems perfectly reasonable. I just want to make sure what was agreed. Exactly! Best Regards, Alexey From nobody Tue Oct 12 07:00:56 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B333A13F3 for ; Tue, 12 Oct 2021 07:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eNvNMb-1GGu for ; Tue, 12 Oct 2021 07:00:49 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF893A13FF for ; Tue, 12 Oct 2021 07:00:49 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id bi9so5530022qkb.11 for ; Tue, 12 Oct 2021 07:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DwT9sjNR1bEI6YUgNC2XAvW2rcv9nzuenL3VQb0nrOA=; b=F6VPR4/3ec8fi4LpL2LdtPfWqeAPouWqIBNcOhfuR5hBy5JIpce70ACPG3JWotr+VP K7SDnLEjDBN2qaGJicJTmUkxB6u8i/WFkRL/kcCAZsn1br51WxS9QiKRpybxcCF5a0yg nIMuMk2GuvQk1wlLUz5pZwvosx0tqn9XoDPY4JdqP0w2y+R4r89glNHzZZ1xOWP75dhY 9eTQK1K15H5GawEQ8OLmQH7WwvxXEQ5F+/MxzlsuVCr3V7L5YJ63N5djOZC666BBX0e3 jUBnF5SvrE0BnD8uZQbgslXWijySDIsk16tomafdeX0FNcjW3mzcp5MdbWXUCQKfHlaH Rf3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DwT9sjNR1bEI6YUgNC2XAvW2rcv9nzuenL3VQb0nrOA=; b=PR6vOA3YtNWNOaRjJyX69Jp+jCDQnX3tyzJkYxvQ4JFJ7WI+sWOXupbMK4u2a7nvK5 uMWYtb510jgJk1EzM08s7ewsMUaoDdeo7rov3q+fJF2SNLg55QQhB+uCfrINvoaWhT7A sS+hdp38qIqg5EU6NjqKeHwLz7u9FvLYHMINsLj6Fr0+Yu+bq5E8wkQpVtRzJArdxvfE xmUPDmAiJG03R2oVfpF0fcKVWKlYhWORBUjN1s/3cHND45rmE5qfarijLJfiJC+4f2YX QCAabfg0p45G1gio0AC6RW/QTAM2oIjvnmRQSdidcIZBFCwzUqG9MOzmxu5nJS3O1rUk Sq9Q== X-Gm-Message-State: AOAM532Q9nc7E/VCG9b6wAWMrFyWYaO4kGXtrmDR5Mv4q+ZVZ5Md2zeg 3o0pT6RjlFs4Y259phNCZ6JBmSFMUC7ftJOBHLptMShG19s= X-Google-Smtp-Source: ABdhPJwxtEs52CUgh2c+e/y0ociNGw8oqNwn9K1+h0btMELVyAwakXANH50g2rGXgzJEtif3756vM5hYka0OHhomjqI= X-Received: by 2002:a37:b142:: with SMTP id a63mr19590043qkf.393.1634047248064; Tue, 12 Oct 2021 07:00:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Todd Herr Date: Tue, 12 Oct 2021 10:00:32 -0400 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000c472c005ce28450d" Archived-At: Subject: Re: [Emailcore] rfc5321bis-04 and notes from minutes X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 12 Oct 2021 14:00:55 -0000 --000000000000c472c005ce28450d Content-Type: text/plain; charset="UTF-8" On Mon, Oct 4, 2021 at 10:15 AM Alexey Melnikov wrote: > > > ### Ticket 30? Erratum 4055 -> remove reference to SPF/DKIM > > --> Done. Did not remove quite as much as suggested; want > > to get a consensus call/ ruling from the chairs. > > Todd is in charge of this ticket, I will ask him to comment. > > I am happy with the current text for the second paragraph of section 3.6.2, which now reads: This specification does not deal with the verification of return paths. Server efforts to verify a return path and actions to be taken under various circumstances are outside the scope of this specification. > > ### Ticket 19 - requirements for domain name and IP address in > > EHLO > > --> Deferred to mailing list. Meeting actions to Viktor and > > maybe Allessandro. Inserted note about pointer to the > > A/S. > > I think there is specific text suggested in the ticket already. Todd > should comment as the ticket owner. > > Ticket 19 as currently written proposes the following... Replace this paragraph from section 4.1.4 of RFC 5321: An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis. Information captured in the verification attempt is for logging and tracing purposes. Note that this prohibition applies to the matching of the parameter to its IP address only; see Section 7.9 for a more extensive discussion of rejecting incoming connections or mail messages. With this: An SMTP server MAY verify that the domain argument in the EHLO command has an address record matching the IP address of the client. There is other proposed text in the ticket, text proposing action to take if the verification fails, text for which there is not yet consensus on its content, but text for which this thread seemed to arrive at the consensus that anything said on the topic should be in the Applicability Statement, and not 5321bis. I anticipate further discussion on *that* text, obviously. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000c472c005ce28450d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 4, 2021 at 10:15 AM Alexey Melnikov <aamelnikov@fastmail.fm>= wrote:

> ### Ticket 30? Erratum 4055 -> remove reference to SPF/DKIM
>=C2=A0 =C2=A0 --> Done.=C2=A0 Did not remove quite as much as sugges= ted; want
>=C2=A0 =C2=A0 to get a consensus call/ ruling from the chairs.

Todd is in charge of this ticket, I will ask him to comment.

I am happy with the current text for the seco= nd paragraph of section 3.6.2, which now reads:

<= blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px">
This s= pecification does not deal with the verification of return
paths. Server efforts to verify a return path and actions to b= e
taken under various circumstances are outsid= e the scope of this
specification.
=C2=A0
> ### Ticket 19 - requirements for domain name and IP address in
>=C2=A0 =C2=A0 EHLO
>=C2=A0 =C2=A0--> Deferred to mailing list.=C2=A0 Meeting actions to = Viktor and
>=C2=A0 =C2=A0 =C2=A0 maybe Allessandro.=C2=A0 Inserted note about point= er to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 A/S.

I think there is specific text suggested in the ticket already. Todd should= comment as the ticket owner.


Ticket 19 as currently written proposes the follo= wing...

Replace this paragraph from section 4.1.4 of RFC 5321:

= 
   An SMTP server MAY verify that the domain na=
me argument in the EHLO
   command actually corresponds to the IP address of the client.
   However, if the verification fails, the server MUST NOT refuse to
   accept a message on that basis.  Information captured in the
   verification attempt is for logging and tracing purposes.  Note that
   this prohibition applies to the matching of the parameter to its IP
   address only; see Section 7.9 for a more extensive disc=
ussion of
   rejecting incoming connections or mail messages.

With this:

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

There is other prop= osed text in the ticket, text proposing action to take if the verification = fails, text for which there is not yet consensus on its content, but text f= or which=C2=A0this thread=C2=A0seemed to arrive at the co= nsensus that anything said on the topic should be in the Applicability Stat= ement, and not 5321bis. I anticipate further discussion on *that* text, obv= iously.

-- <= br>

Todd Herr | Technical Director, Standards and Ec= osystem
m: 703.220.4153

This email and all data transmit= ted with it contains confidential and/or proprietary information intended s= olely for the use of individual(s) authorized to receive it. If you are not= an intended and authorized recipient you are hereby notified of any use, d= isclosure, copying or distribution of the information included in this tran= smission is prohibited and may be unlawful. Please immediately notify the s= ender by replying to this email and then delete it from your system.=

--000000000000c472c005ce28450d-- From nobody Wed Oct 13 01:18:45 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61AE3A14C6 for ; Wed, 13 Oct 2021 01:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=XHuL/sSU; dkim=pass (1152-bit key) header.d=tana.it header.b=B0Uz29B0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yw9Tfjodd77 for ; Wed, 13 Oct 2021 01:18:36 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88A873A113B for ; Wed, 13 Oct 2021 01:18:35 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1634113110; bh=x603mMzQQxhb1Idy//93m73ORy32qHHqFe64+c4kOe0=; l=2516; h=Subject:To:References:From:Date:In-Reply-To; b=XHuL/sSUM5/V7TxLCuz219F1N3S4OQVBoJ/HNIL+4ZWT0JfDiXkNMXWK2UDucUuL0 2rMB3YGREEfEl+StaKwCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1634113110; bh=x603mMzQQxhb1Idy//93m73ORy32qHHqFe64+c4kOe0=; l=2516; h=To:References:From:Date:In-Reply-To; b=B0Uz29B0yYK2iWqcgDhKcMWJD+sPOhLMOAdUf+303KF4uCbPqZjeiNu/TNKGXeMtg OZ9JOOw5BywBhPJxMaS2LSjgvzoJQxf14uzH/6PqYNScSNIb71g9yKIzoPNPrQ5+zi Zx75onKY6VZut3guP3oOOyiuHWj3G9kd1fNEesimo0LAXzPeU99NjwzVaUqoi 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.0000000061669655.00000423; Wed, 13 Oct 2021 10:18:29 +0200 To: emailcore@ietf.org References: From: Alessandro Vesely Message-ID: <9feda317-4e5a-4883-fe1c-bbac5a9ef19c@tana.it> Date: Wed, 13 Oct 2021 10:18:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] rfc5321bis-04 and notes from minutes X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 13 Oct 2021 08:18:44 -0000 On Tue 12/Oct/2021 16:00:32 +0200 Todd Herr wrote: > On Mon, Oct 4, 2021 at 10:15 AM Alexey Melnikov wrote: >> >>> ### Ticket 30? Erratum 4055 -> remove reference to SPF/DKIM >>> --> Done. Did not remove quite as much as suggested; want >>> to get a consensus call/ ruling from the chairs. >> >> Todd is in charge of this ticket, I will ask him to comment. >> > I am happy with the current text for the second paragraph of section 3.6.2 +1, neat and concise. >>> ### Ticket 19 - requirements for domain name and IP address in >>> EHLO >>> --> Deferred to mailing list. Meeting actions to Viktor and >>> maybe Allessandro. Inserted note about pointer to the >>> A/S. >> >> I think there is specific text suggested in the ticket already. Todd >> should comment as the ticket owner. > > Ticket 19 as currently written proposes the following... > > Replace this paragraph from section 4.1.4 of RFC 5321: > > An SMTP server MAY verify that the domain name argument in the EHLO > command actually corresponds to the IP address of the client. > However, if the verification fails, the server MUST NOT refuse to > accept a message on that basis. Information captured in the > verification attempt is for logging and tracing purposes. Note that > this prohibition applies to the matching of the parameter to its IP > address only; see Section 7.9 for a more extensive discussion of > rejecting incoming connections or mail messages. > > With this: > > An SMTP server MAY verify that the domain argument in the EHLO command > has an address record matching the IP address of the client. > > There is other proposed text in the ticket, text proposing action to take > if the verification fails, text for which there is not yet consensus on its > content, but text for which this thread > > seemed to arrive at the consensus that anything said on the topic should be > in the Applicability Statement, and not 5321bis. I anticipate further > discussion on *that* text, obviously. The thread pointed shows a generic disagreement on the exact checks carried out by various servers, possibly having different criteria for public Internet, known hosts, and private networks, all of which implement SMTP. I re-propose the text I already proposed: An SMTP server MAY verify the validity of the domain name argument in the EHLO command. See [A/S] for further discussion. Best Ale -- From nobody Fri Oct 15 15:42:39 2021 Return-Path: X-Original-To: emailcore@ietf.org Delivered-To: emailcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B79AF3A0E12; Fri, 15 Oct 2021 15:34:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: emailcore@ietf.org, superuser@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163433724374.17026.17913850855687954290@ietfa.amsl.com> Date: Fri, 15 Oct 2021 15:34:03 -0700 Archived-At: Subject: [Emailcore] emailcore - Requested session has been scheduled for IETF 112 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 22:34:20 -0000 Dear Liz Flynn, 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) Wednesday, 10 November 2021, Session I 1200-1400 Room Name: Room 1 size: 501 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/112/sessions/emailcore.ics Request Information: --------------------------------------------------------- Working Group Name: Revision of core Email specifications Area Name: Applications and Real-Time Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: People who must be present: Alexey Melnikov Dr. John C. Klensin Murray Kucherawy Pete Resnick Todd Herr Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Oct 16 21:39:20 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD39F3A11A4 for ; Sat, 16 Oct 2021 21:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Etd6U3J84LEJ for ; Sat, 16 Oct 2021 21:39:13 -0700 (PDT) Received: from mr85p00im-zteg06012001.me.com (mr85p00im-zteg06012001.me.com [17.58.23.197]) (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 CE3C03A1197 for ; Sat, 16 Oct 2021 21:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1634445553; bh=n9c8Ni9Zu8CMlbTzRbx2YqQAcrxnN5uHjj8wBqweufc=; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To; b=ubX5b2UbgHYX0l2vkoRa6zRMvQg6JvtBTItGzdf/XR8tmvPhxNvCQ0ERNqhkNYnfb HZFxDmxfBRbePJ01cX5Chm6VngJ7ibv+HIU2GIr6lnaXhugXbpLXMWQoVqywFe1XSQ kR/5/CYT4lsMjG4ubPnv055ue1ZKD6gflr+MVYrQ2lEvTdFm1WfYo7EQrTB1ImbVQD 5GRA8mnAY6ED/7JPd+UJrEaKMneBPEZ2MmvhyhJm7ZXPdzvr1KvAUKZ8l+kslbyDBU jzraKb6IH+AczNH6FBI9zT39fxN+AjQ0T4leNFv+y7gZkOCE4skVg55mNThbQV3tgD 1GyfnElc8tk0A== Received: from [172.16.16.24] (natbox.sabahattin-gucukoglu.com [90.155.50.12]) by mr85p00im-zteg06012001.me.com (Postfix) with ESMTPSA id 1E143A004E7 for ; Sun, 17 Oct 2021 04:39:12 +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 12.4 \(3445.104.21\)) Message-Id: <87605987-5256-48AA-AFE1-13452412BC79@me.com> Date: Sun, 17 Oct 2021 05:39:10 +0100 To: emailcore@ietf.org X-Mailer: Apple Mail (2.3445.104.21) X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.425,18.0.790,17.0.607.475.0000000_definitions?= =?UTF-8?Q?=3D2021-10-16=5F08:2021-10-14=5F01,2021-10-16=5F08,2020-04-07?= =?UTF-8?Q?=5F01_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 suspectscore=0 bulkscore=0 clxscore=1011 mlxlogscore=999 spamscore=0 mlxscore=0 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2110170032 Archived-At: Subject: [Emailcore] SMTP-TCP is de facto 8bit (suggested clarity in 5321bis) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 17 Oct 2021 04:39:19 -0000 5321bis-04 (and especially section 2.4) suggests SMTP-TCP servers = corrupt or refuse undeclared 8bit content, and that SMTP clients MUST = NOT send undeclared 8bit content. Can I respectfully suggest that in = 2021 this is a bad idea that will simply result in corrupted or lost = mail? For a long time now, SMTP-TCP is de facto 8bit: hosts just pass through = 8bit content, whether or not it is declared, unless it is MIME-aware, in = which case it may or may not perform conversion on 8BITMIME mail that is = declared as such or that is auto-detected (but in which case it may = corrupt the message or invalidate authentication signatures such as = DKIM). Many implementations do not include MIME support in the SMTP servers. = This isn=E2=80=99t unreasonable because it adds complexity. But they = will still advertise 8BITMIME, in order to optimise the delivery of 8bit = mail. See e.g. Dan Bernstein=E2=80=99s notable rant on the subject: https://cr.yp.to/smtp/8bitmime.html Exim enabled 8BITMIME by default in version 4.80. It is =E2=80=9C8bit = clean=E2=80=9D, too. I think language should be added that sternly admonishes servers against = corrupting or refusing undeclared 8bit content, and that downgrades MUST = NOT to SHOULD NOT in discussion of client behaviour, suggesting strongly = that 8BITMIME is an obligation to perform 7bit downgrade but recognising = the necessity of transmitting 8bit where the content cannot definitely = be identified as MIME or protected by an authentication scheme (this = latter being an especially important consideration for relaying or = forwarding systems). Cheers, Sabahattin From nobody Sat Oct 16 23:13:28 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366853A0938; Sat, 16 Oct 2021 23:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sb4Oo2mX_yLQ; Sat, 16 Oct 2021 23:13:22 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EBA43A0926; Sat, 16 Oct 2021 23:13:17 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mbzQ3-000MoR-Qc; Sun, 17 Oct 2021 02:13:15 -0400 Date: Sun, 17 Oct 2021 02:13:10 -0400 From: John C Klensin To: Sabahattin Gucukoglu , emailcore@ietf.org Message-ID: In-Reply-To: <87605987-5256-48AA-AFE1-13452412BC79@me.com> References: <87605987-5256-48AA-AFE1-13452412BC79@me.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] SMTP-TCP is de facto 8bit (suggested clarity in 5321bis) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 17 Oct 2021 06:13:28 -0000 Sabahattin, I am, as usual, willing to modify the text any way the WG tells me to and I certainly think this issue deserves further discussion. However, with all due respect to Dan Bernstein and the quality of his rants (including both the ones you cite and, IIR, the arguments in the 1990s that we should simply declare all older systems obsolete and let anyone who used them bear the consequences) there are still legacy systems around (I even still see HELO announcements). There is also an interesting question of who or what is sending 8bit content to servers that do not make announcements. If the reality is that all contemporary servers that otherwise conform to 5321 are making the announcement, then this issue is probably moot. And if all of those who might send 8bit materials to servers who don't announce it are bad actors for other reasons, maybe we should not be too concerned about dropping their mail. Finally, as people are thinking about this, please also think about whether encouraging people to send message body material that contains what we are calling 8bit content would also encourage them or others to ignore the more complicated rules associated with SMTPUTF8 and just assume that good 8-bit-clear servers will cope. best, john --On Sunday, October 17, 2021 05:39 +0100 Sabahattin Gucukoglu wrote: > 5321bis-04 (and especially section 2.4) suggests SMTP-TCP > servers corrupt or refuse undeclared 8bit content, and that > SMTP clients MUST NOT send undeclared 8bit content. Can I > respectfully suggest that in 2021 this is a bad idea that will > simply result in corrupted or lost mail? > > For a long time now, SMTP-TCP is de facto 8bit: hosts just > pass through 8bit content, whether or not it is declared, > unless it is MIME-aware, in which case it may or may not > perform conversion on 8BITMIME mail that is declared as such > or that is auto-detected (but in which case it may corrupt the > message or invalidate authentication signatures such as DKIM). > > Many implementations do not include MIME support in the SMTP > servers. This isn't unreasonable because it adds complexity. > But they will still advertise 8BITMIME, in order to optimise > the delivery of 8bit mail. See e.g. Dan Bernstein's notable > rant on the subject: https://cr.yp.to/smtp/8bitmime.html > > Exim enabled 8BITMIME by default in version 4.80. It is > "8bit clean", too. > > I think language should be added that sternly admonishes > servers against corrupting or refusing undeclared 8bit > content, and that downgrades MUST NOT to SHOULD NOT in > discussion of client behaviour, suggesting strongly that > 8BITMIME is an obligation to perform 7bit downgrade but > recognising the necessity of transmitting 8bit where the > content cannot definitely be identified as MIME or protected > by an authentication scheme (this latter being an especially > important consideration for relaying or forwarding systems). > > Cheers, > Sabahattin From nobody Sun Oct 17 12:34:51 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEDF3A0A5F for ; Sun, 17 Oct 2021 12:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=cv3898rL; dkim=pass (2048-bit key) header.d=taugh.com header.b=AUDdNJpX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NyZGt0p5-qd for ; Sun, 17 Oct 2021 12:34:43 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78E993A0A55 for ; Sun, 17 Oct 2021 12:34:43 -0700 (PDT) Received: (qmail 54543 invoked from network); 17 Oct 2021 19:34:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=d50c.616c7ad1.k2110; bh=PsCMQrku924kE++CaJz/7Jb1m7o55OGY+fRSWsrNHPE=; b=cv3898rL2PQVeiadkeo0oszBhZIBQZuQrbm2PQO6ANEk0u7c3Cbqq71wGAFMx7Mn5UQCdw2gfyfeFGC+QP8IN8Bykwoc8WFOvS/dJKtiCO3jplyfbSXWzJKXPxg8p2fJPhrqODs8dn+iQyAQgN4P+WH+Brh8O7yt08lwc1dgNvka3NsVY9RunodJCQtXgUf4zIr7twGxSHPXs08uGjQlz0dKCDh4ytd4j/HUGRHoiYs/DYHx8m7fd4V+cGw+SYbb61X0CLsp5mcwrLz75q/3XeK7J6CMd1sfa5F7HbHHLADQwbaQriwNC+oD1KXAEy8SAZEtZo7jQH3pUDey+Mb6oQ== 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=d50c.616c7ad1.k2110; bh=PsCMQrku924kE++CaJz/7Jb1m7o55OGY+fRSWsrNHPE=; b=AUDdNJpXePUrMYL45bv6vDGhLKAqT1isRqeM4JcO4jFUcT6508ij+Ss6GoWeFO7ZMLIwS1ACgDnrF58jsKaq7y8OscdJTuHJ+fwBu7P/Sj0RwecF/RLJXmBC9ZtdY8pPHFOgz0Fs+HZNHnUgGtRMfu5oWRRIMGNjMk0DezIswvDXTdyEpqMaEXTyrc37Ej8D3pKevGPURQlRnfqK+4Sj/DsHHC5qYG9yuwdwrfeh71+Cc45Hd67QVhsqYEUpZS1lQ5lvSV+3IJl/1ZQwm6oOi0twGljoI472p5X/FfbperB45VDzhnLnQBDYTX5KM5/DjpcqH2BZbmCU7NIX+Em/JA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 17 Oct 2021 19:34:41 -0000 Received: by ary.qy (Postfix, from userid 501) id 2A5602A76EB6; Sun, 17 Oct 2021 15:34:39 -0400 (EDT) Date: 17 Oct 2021 15:34:39 -0400 Message-Id: <20211017193440.2A5602A76EB6@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] SMTP-TCP is de facto 8bit (suggested clarity in 5321bis) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 17 Oct 2021 19:34:49 -0000 It appears that John C Klensin said: >Sabahattin, > >I am, as usual, willing to modify the text any way the WG tells >me to and I certainly think this issue deserves further >discussion. However, with all due respect to Dan Bernstein and >the quality of his rants (including both the ones you cite and, >IIR, the arguments in the 1990s that we should simply declare >all older systems obsolete and let anyone who used them bear the >consequences) there are still legacy systems around (I even >still see HELO announcements). ... How about making 8BITMIME support mandatory. Sure, there is a long tail of dusty MTAs that still say HELO, but the people who run them won't be reading our specs and if they still send 7bit, nothing will break. Every computer on the Internet has used 8 bit bytes for at least 30 years, and at this point it is just perverse not to handle 8 bit input data. R's, John From nobody Sun Oct 17 15:20:20 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8338B3A12AE for ; Sun, 17 Oct 2021 15:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnI53Xk_UhyM for ; Sun, 17 Oct 2021 15:20:13 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B143A12AD for ; Sun, 17 Oct 2021 15:20:09 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mcEVj-000O5A-6i; Sun, 17 Oct 2021 18:20:07 -0400 Date: Sun, 17 Oct 2021 18:20:01 -0400 From: John C Klensin To: John Levine , emailcore@ietf.org Message-ID: <765255A93C749948FD118FE8@PSB> In-Reply-To: <20211017193440.2A5602A76EB6@ary.qy> References: <20211017193440.2A5602A76EB6@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] SMTP-TCP is de facto 8bit (suggested clarity in 5321bis) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 17 Oct 2021 22:20:19 -0000 --On Sunday, October 17, 2021 15:34 -0400 John Levine wrote: > It appears that John C Klensin said: >> Sabahattin, >> >> I am, as usual, willing to modify the text any way the WG >> tells me to and I certainly think this issue deserves further >> discussion. However, with all due respect to Dan Bernstein >> and the quality of his rants (including both the ones you >> cite and, IIR, the arguments in the 1990s that we should >> simply declare all older systems obsolete and let anyone who >> used them bear the consequences) there are still legacy >> systems around (I even still see HELO announcements). ... > > How about making 8BITMIME support mandatory. Sure, there is a > long tail of dusty MTAs that still say HELO, but the people > who run them won't be reading our specs and if they still send > 7bit, nothing will break. > > Every computer on the Internet has used 8 bit bytes for at > least 30 years, and at this point it is just perverse not to > handle 8 bit input data. I'd be happier about that solution than about the relaxation that Sabahattin suggested. It would also improve the foundation for SMTPUTF8 which already requires 8BITMIME. john From nobody Wed Oct 20 14:50:58 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460C03A13AF for ; Wed, 20 Oct 2021 14:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhX6Mmv80Yj9 for ; Wed, 20 Oct 2021 14:50:50 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B9C13A13AD for ; Wed, 20 Oct 2021 14:50:50 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S576EFOTI800APMA@mauve.mrochek.com> for emailcore@ietf.org; Wed, 20 Oct 2021 14:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1634766345; bh=MqcI5/og8i0YPF544FpUi4y5rasja3Hquz3atny+5PY=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Ty+joUWjxtmJToE47rvAOemnO1KaI8pyqX7NV3YUkUUu2RhDb57z7CPyJ1NG4PlBO f3DpPssz+5Ajo/XW2V9CB6eKx3or2m9sOY3dMECHiXswwObJNtL7c78kSVBuiZPgUG 2VYb2znvwNYDkQac6rwK2qk1Ltg4rvwGsFRd7pws= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S56OEM7AOG005PTU@mauve.mrochek.com>; Wed, 20 Oct 2021 14:45:42 -0700 (PDT) Cc: John Levine , emailcore@ietf.org Message-id: <01S576EDCIW6005PTU@mauve.mrochek.com> Date: Wed, 20 Oct 2021 14:21:22 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 17 Oct 2021 18:20:01 -0400" <765255A93C749948FD118FE8@PSB> References: <20211017193440.2A5602A76EB6@ary.qy> <765255A93C749948FD118FE8@PSB> To: John C Klensin Archived-At: Subject: Re: [Emailcore] SMTP-TCP is de facto 8bit (suggested clarity in 5321bis) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 20 Oct 2021 21:50:56 -0000 > --On Sunday, October 17, 2021 15:34 -0400 John Levine > wrote: > > It appears that John C Klensin said: > > > Sabahattin, > > > I am, as usual, willing to modify the text any way the WG > > > tells me to and I certainly think this issue deserves further > > > discussion. However, with all due respect to Dan Bernstein > > > and the quality of his rants (including both the ones you > > > cite and, IIR, the arguments in the 1990s that we should > > > simply declare all older systems obsolete and let anyone who > > > used them bear the consequences) there are still legacy > > > systems around (I even still see HELO announcements). ... > > How about making 8BITMIME support mandatory. Sure, there is a > > long tail of dusty MTAs that still say HELO, but the people > > who run them won't be reading our specs and if they still send > > 7bit, nothing will break. > > Every computer on the Internet has used 8 bit bytes for at > > least 30 years, and at this point it is just perverse not to > > handle 8 bit input data. The concerns of DEC-10 aficionados notwithstanding, 8BITMIME was never about supporing machines with odd byte sizes. Rather, it was about accommodating implementations on 8 bit byte machines that handled 8bit data *badly*, e.g., clearing (or in a few cases, setting) the high bit unconditionally. A secondary concern was proper charset labeling in place, but I'd just as soon not get into that. We had customers turn on "just send 8" and run into issues as late as the mid-2000s. Like it or not, support from the underlying infrastructure doesn't necessarily translate into application support for something. I'll also note that personal experience, no matter how extensive, doesn't translate into comprehensive understanding of everything that's out there. An anecdote. Like most implementations, at some point we changed the default so our SMTP server would only accept TLS , not SSL. This seemed like a perfectly reasonable change to make. However, as luck would have it, a customer had deployed some sort of software with a version of sendmail that it used to send out status reports, which were then processed somewhere else. And this version of sendmail only supported SSL, not TLS. Even worse, fallback to plaintext didn't work, for reasons I no longer recall. So the messages stayed in the sendmail queue, which was located on the root partition with limited disk space. And this was deployed on 1000s of machines. > I'd be happier about that solution than about the relaxation > that Sabahattin suggested. It would also improve the foundation > for SMTPUTF8 which already requires 8BITMIME. Mandating 8BITMIME seems like the right approach to me as well. Ned From nobody Wed Oct 20 14:54:35 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01723A13BF for ; Wed, 20 Oct 2021 14:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=OHCkZh5T; dkim=pass (2048-bit key) header.d=taugh.com header.b=VYv8hTY0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1L4SKk8hR7ZT for ; Wed, 20 Oct 2021 14:54:27 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949AC3A13BE for ; Wed, 20 Oct 2021 14:54:27 -0700 (PDT) Received: (qmail 69885 invoked from network); 20 Oct 2021 21:54:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=110f8.61709011.k2110; bh=LHrVjtHdH8Z8VRMxe8P+2IPWonJA2xNQHVTfeHBHP40=; b=OHCkZh5TNyzZ1UpcFyF/baS8oPyoioSZdI3jUd/Mnbe1K2pjhN4R6XAxBmO2KhHF9RVd9qWACvv7THJQuUH0YPcM7g/s/KRYAAcf+sjDVzNw7JRrtPUILwZL1W36VYe8AOBNNYGqut4TRl1FyoRwsC/vlj9H0NWW2vO0jHip8yHosO1ect7eXrtH9LI+UDYgdm7IivXobCZLCY5KQYrMZlh23C7Ii3dkZViH2wdKgufs+sqMUkeuuiqNC4avOCbJzbiZpADPA1NiwKNhfJDzji+MboKuEpYlZYOGB3vmORQM/27UmmrLw18z8mNOfsFlFP6r7/5wiYO5miKcBsh5gw== 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=110f8.61709011.k2110; bh=LHrVjtHdH8Z8VRMxe8P+2IPWonJA2xNQHVTfeHBHP40=; b=VYv8hTY0yMwHbaoELI2nLj+NzPha0aDHC61swwbQ7j+TNWNpCqwmmLdayuKr2PFAKI0YKJupTG5816RF7N92cTIvj9g9NXNalk6VCzQ3oTuZMCGm00I7yRf19ROFuBqH9Qkrr7IPFMb17T11xOHgnbt/XRZBN7oMwVFbuY35IJkdYpp3LVwIfksRUpO2XLrqUBya33c9zwDvWfonvT53Jroux7OYmMU7hZ9cG6dGTXhkHuRZ+T+LOljoTYzo4XIlDfRv04sYSsoxkQqVyNP/1HuNSDxaTMlp155oLmgZSswI2nXNbK+IChyWbARyPzcc67pkzbhMzz3iOJX7FnIvCg== 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; 20 Oct 2021 21:54:24 -0000 Received: by ary.qy (Postfix, from userid 501) id 77CAB2B19FC1; Wed, 20 Oct 2021 17:54:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 18B4F2B19FA3; Wed, 20 Oct 2021 17:54:24 -0400 (EDT) Date: 20 Oct 2021 17:54:23 -0400 Message-ID: From: "John R Levine" To: "Ned Freed" Cc: emailcore@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: <01S576EDCIW6005PTU@mauve.mrochek.com> References: <20211017193440.2A5602A76EB6@ary.qy> <765255A93C749948FD118FE8@PSB> <01S576EDCIW6005PTU@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] SMTP-TCP is de facto 8bit (suggested clarity in 5321bis) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 20 Oct 2021 21:54:33 -0000 On Wed, 20 Oct 2021, Ned Freed wrote: >>> How about making 8BITMIME support mandatory. Sure, there is a >>> long tail of dusty MTAs that still say HELO, but the people >>> who run them won't be reading our specs and if they still send >>> 7bit, nothing will break. > >>> Every computer on the Internet has used 8 bit bytes for at >>> least 30 years, and at this point it is just perverse not to >>> handle 8 bit input data. ... > > The concerns of DEC-10 aficionados notwithstanding, 8BITMIME was never about > supporing machines with odd byte sizes. Rather, it was about accommodating > implementations on 8 bit byte machines that handled 8bit data *badly*, e.g., > clearing (or in a few cases, setting) the high bit unconditionally. ... > Mandating 8BITMIME seems like the right approach to me as well. I think we agree. My point was more that there are no machines left where it would be hard to handle 8 bits if the people running it care to do so. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Oct 22 10:06:53 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA353A1181 for ; Fri, 22 Oct 2021 10:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=ze+55bGn; dkim=pass (1152-bit key) header.d=tana.it header.b=DfxJWgJk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nl0kIQShPYmx for ; Fri, 22 Oct 2021 10:06:42 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAA113A117D for ; Fri, 22 Oct 2021 10:06:40 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1634922396; bh=m+dzJeHN28a9MF4XBcBsGPghpUOhziQq811kBXyAD4E=; l=271; h=Subject:To:References:From:Date:In-Reply-To; b=ze+55bGn/vOJNUlr8dCj/YH434gPXFGO0a7uWQ5t+V9N0qojEo+Z6B9XRtHB/JgBE VvAjnI0+ZaQxOp8sz0aAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1634922396; bh=m+dzJeHN28a9MF4XBcBsGPghpUOhziQq811kBXyAD4E=; l=271; h=To:References:From:Date:In-Reply-To; b=DfxJWgJkiEBXSeEwZ3GzWf2sG1vZZCjOyXMlBYife+tfLkpcfmPkojgL1kKsG20fd L872KZrNKScsyW6MvkoIV+rXQCWKGJre8G1URco+1dv1nmcKoXWamksXzfQPnU3SLL +jwq8c9Wu/52i6LtmVHXhEMRYfPHpn7ATtRYLvptDMZFh1qGjzw+w2iEo1Jci Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC028.000000006172EF9B.00007070; Fri, 22 Oct 2021 19:06:35 +0200 To: emailcore@ietf.org References: <20211017193440.2A5602A76EB6@ary.qy> <765255A93C749948FD118FE8@PSB> <01S576EDCIW6005PTU@mauve.mrochek.com> From: Alessandro Vesely Message-ID: Date: Fri, 22 Oct 2021 19:06:35 +0200 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: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] SMTP-TCP is de facto 8bit (suggested clarity in 5321bis) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 22 Oct 2021 17:06:52 -0000 On Wed 20/Oct/2021 23:54:23 +0200 John R Levine wrote: > On Wed, 20 Oct 2021, Ned Freed wrote: > >> Mandating 8BITMIME seems like the right approach to me as well. > > I think we agree. +1, this should neutralize most X-MIME-Autoconverted:. Best Ale -- From nobody Fri Oct 22 15:13:36 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4DC3A08C4 for ; Fri, 22 Oct 2021 15:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mi7SEm78uqkM for ; Fri, 22 Oct 2021 15:13:29 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F9E3A08BD for ; Fri, 22 Oct 2021 15:13:29 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1me2n1-000CyM-Di; Fri, 22 Oct 2021 18:13:27 -0400 Date: Fri, 22 Oct 2021 18:13:20 -0400 From: John C Klensin To: Alexey Melnikov cc: emailcore@ietf.org Message-ID: In-Reply-To: <914b4691-cea6-1a88-855d-0f9b19687e4a@isode.com> References: <914b4691-cea6-1a88-855d-0f9b19687e4a@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition for trace header fields (rfc5321bis changes only) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 22 Oct 2021 22:13:35 -0000 Alexey, Thanks and sorry for the long delay in getting back to this. I have tried to implement this as I think you intended, but I don't think part of it works. See below. --On Monday, October 4, 2021 16:33 +0100 Alexey Melnikov wrote: > Hi John, >=20 > Below I am summarizing proposed changed to 5321bis to address > ticket #7. The changes only address trace header fields and > other tickets remain unaffected. >=20 > 1) Move the current content of Section 4.4 into Section 4.4.1. > Rename it to be "Receive header field" (or similar). >=20 > 2) Add the following paragraph to the now empty (other than > the new subsection) 4.4: >=20 > =C2=A0 Trace information is used to provide an audit trail of > message handling. > =C2=A0 In addition, it indicates a route back to the sender = of > the message. Ok, but this leaves a subsection 4.4.1 without a 4.4.2. I object to that editorially and the RFC Editor usually objects to it as well. Do we need at least a stub 4.4.2 for "Return-path:" which would solve that editorial problem? Or, IMO less attractively, we could make the new paragraph 4.4.1 and the Received text 4.4.2. =20 > 3) In Section 2.3.10, 1st paragraph, last sentence: >=20 > =C2=A0=C2=A0 A "relay" SMTP > =C2=A0=C2=A0 system (usually referred to just as a "relay") = receives > mail from an > =C2=A0=C2=A0 SMTP client and transmits it, without = modification to > the message > =C2=A0=C2=A0 data other than adding trace information >=20 > Insert cross reference to section 4.4 here. Done. > =C2=A0=C2=A0 , to another SMTP server for > =C2=A0=C2=A0 further relaying or for delivery. >=20 > 4) In Section 3.6.3 (Message Submission Servers as Relays), > last paragraph: >=20 > =C2=A0=C2=A0 As discussed in Section 6.4, a relay SMTP has no = need to > inspect or > =C2=A0=C2=A0 act upon the header section or body of the = message data > and MUST NOT > =C2=A0=C2=A0 do so except to add its own "Received:" header = field > (Section 4.4) >=20 > Change "Section 4.4" to "Section 4.4.1". Also add "and > possibly other trace header fields" after it. Done. If the "Received" subsection becomes 4.4.2 as in the not-preferred solution about, this will auto-correct. =20 > =C2=A0=C2=A0 and, optionally, to attempt to detect looping in = the > mail system (see > =C2=A0=C2=A0 Section 6.3).=C2=A0 Of course, this prohibition = also applies > to any > =C2=A0=C2=A0 modifications of these header fields or text = (see also > Section 7.9). >=20 > 5) In Section 7.6: >=20 > =C2=A0=C2=A0 In some circumstances, such as when mail = originates from > within a LAN > =C2=A0=C2=A0 whose hosts are not directly on the public = Internet, > trace > =C2=A0=C2=A0 ("Received") header fields produced in = conformance with > this >=20 > Insert "e.g." before "Received". Done. > =C2=A0=C2=A0 specification may disclose host names and = similar > information that > =C2=A0=C2=A0 would not normally be available.=C2=A0 This = ordinarily does > not pose a > =C2=A0=C2=A0 problem, but sites with special concerns about = name > disclosure should > =C2=A0=C2=A0 be aware of it.=C2=A0 Also, the optional FOR = clause should > be supplied > =C2=A0=C2=A0 with caution or not at all when multiple = recipients are > involved lest > =C2=A0=C2=A0 it inadvertently disclose the identities of = "blind copy" > recipients > =C2=A0=C2=A0 to others. One comment, just to be sure we are all on the same page. The text, especially with these changes, makes substantially any relay (there might be exception, but I can't think of one) that goes into the anti-spam or anti-malware business on the basis of headers or content -- even noticing DKIM/SPF/DMARC failures and rejecting or bouncing a message on that basis -- non-conforming unless it relies entirely on the "operational necessity" provisions. Otherwise, we intend to only allow such filtering behavior in, or prior to, the submission server and after what SMTP believes is final delivery (i.e., within the vaguely defined administrative domain of the recipient. I can life with that but, if others are going to object, it would be good to hear from them RSN rather than much later. best, john From nobody Fri Oct 22 16:21:30 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78DD3A0945 for ; Fri, 22 Oct 2021 16:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNaj7Mi8BOJw for ; Fri, 22 Oct 2021 16:21:21 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33FB3A0918 for ; Fri, 22 Oct 2021 16:21:21 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1me3qf-000D48-MS; Fri, 22 Oct 2021 19:21:17 -0400 Date: Fri, 22 Oct 2021 19:21:10 -0400 From: John C Klensin To: Alexey Melnikov , Todd Herr cc: emailcore@ietf.org Message-ID: <73058CDA2857C379A946A785@PSB> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] rfc5321bis-04 and notes from minutes X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 22 Oct 2021 23:21:29 -0000 Alexey, Again thanks for the comments and sorry for the delay in getting to this. Most comments that have been acted on or that do not involve further action in 5321bis have been removed for brevity. --On Monday, October 4, 2021 15:15 +0100 Alexey Melnikov wrote: >... >> Note that several people volunteered to post text or >> suggestions/ comments that have not appeared: consider >> yourselves reminded. Another reminder :-( >... >> ### Ticket 20: removal of SEND,SAML,SOML >> --> Done (I think -- see note in G.7.13) > > There is one more change to be done, as discussed on the > mailing list. I will send you a separate email. Done. >... >> ### Extension keywords starting with X >> ### private-use commands with X >> ### change "MUST be registered unless X" to SHOULD be >> registered >> --> Awaiting mailing list discussion and proposed text from >> Barry > > I just reminded Barry as well. I do not believe we have heard from him. As a starting point for further discussion, in rfc5321bis-05 I have simply removed all mention of "X" from that paragraph and minimally restated the requirement for registration. If we either want to reduce the requirement from MUST... IESG-approved or to put in words explicitly deprecating "X-" in this document, I await text (and, if needed, tickets). >> ### Ticket 30? Erratum 4055 -> remove reference to SPF/DKIM >> --> Done. Did not remove quite as much as suggested; want >> to get a consensus call/ ruling from the chairs. > > Todd is in charge of this ticket, I will ask him to comment. Done per (partially off-list) discussion. For this and the next item, more work will be needed for the A/S, probably including either contact information for the Protocol Police when the ISP supporting a server refuses to supply (or demands a hefty fee for) reverse mapping to anything but an ITU-style location identifer or a discussion of why something like EHLO be-302-cr11.newark.nj.xxxx.example.net would be a good idea. See also the two CREFs in the current (rfc5321bis-05) text. >> ### Ticket 19 - requirements for domain name and IP address in >> EHLO >> --> Deferred to mailing list. Meeting actions to Viktor and >> maybe Allessandro. Inserted note about pointer to the >> A/S. > > I think there is specific text suggested in the ticket > already. Todd should comment as the ticket owner. See above. I await further instructions if the text in rfc5321bis-05 is not sufficient. >... >> ## AOB (Ticket #8 - IANA registry) >> --> Based on message thread ("Subject: Re: [Emailcore] >> Ticket #8: Need a registry of header fields that are Ok >> to add after submission". Discussion on list between >> 2021-07-27 and 2021-08-05), while we seem to agree on the >> principle, no conclusion has been reached about where the >> registry goes nor about which document should do it. No >> 5321bis action in the -04 draft. > > I will review and followup on this. I think I'm still awaiting that. best, john From nobody Fri Oct 22 16:26:59 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C3A3A09D0 for ; Fri, 22 Oct 2021 16:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_HJWabU91fI for ; Fri, 22 Oct 2021 16:26:56 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076DD3A09CF for ; Fri, 22 Oct 2021 16:26:55 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1me3w6-000D5T-HT for emailcore@ietf.org; Fri, 22 Oct 2021 19:26:54 -0400 Date: Fri, 22 Oct 2021 19:26:47 -0400 From: John C Klensin To: emailcore@ietf.org Message-ID: <9B80FA4E8D90E6EF3349B423@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] rfc5321bis-05 preview and heads-up X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 22 Oct 2021 23:26:58 -0000 Hi. As people have probably guessed from notes I have posted to this list within the last hour or two, I'm trying to wrap up rfc5321bis-05 with the expectation of getting it done and posted over the weekend. Anyone having uncompleted assignments (either self-imposed or WG-assigned) for work that should be incorporated in that version should try to get it up RSN. If such messages appear, I will incorporate their content if time permits and they seem uncontroversial but, even if I don't, getting text posted now would probably allow useful discussion before we meet at IETF 112. best, john From nobody Sun Oct 24 07:31:12 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287BF3A14D3 for ; Sun, 24 Oct 2021 07:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.45 X-Spam-Level: X-Spam-Status: No, score=-5.45 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=-3.33, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=nmNRjybw; dkim=pass (1152-bit key) header.d=tana.it header.b=BMGRCG97 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41TwxvTB4Kf6 for ; Sun, 24 Oct 2021 07:31:03 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD14A3A14D4 for ; Sun, 24 Oct 2021 07:30:59 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1635085854; bh=mZkUIFgALCyMtZ+OlvDmF59yS5j+H7ae6EeeimQsRtg=; l=853; h=Subject:To:References:From:Date:In-Reply-To; b=nmNRjybw4/DQ8elP+sEt+t3CFQ8kgjamVaDLh2h/vVAEZRth4l29s0OEGiVqyQZL2 3fYf/EXD3gUazEzfMxmCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1635085854; bh=mZkUIFgALCyMtZ+OlvDmF59yS5j+H7ae6EeeimQsRtg=; l=853; h=To:References:From:Date:In-Reply-To; b=BMGRCG97MC/0WGngd+SS2L8vxiSiyucgRyJSJJlKyRVTh6SbAQpCyC22q8FtMCxiS stNxNdk1l4907deLd7zoccT6OZdC08N6sRiUYshsHmlnXRmel9mnIoQSgItICHkwjY xTWRB2gvtouvqtVJ0zZQAa3INEdW9ZSkPhlLISKJCEX2HvEySqynFTUXpmgeC Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC03D.0000000061756E1E.000065CD; Sun, 24 Oct 2021 16:30:54 +0200 To: emailcore@ietf.org References: <9B80FA4E8D90E6EF3349B423@PSB> From: Alessandro Vesely Message-ID: <519bad00-0619-f53f-e474-516b92f687e3@tana.it> Date: Sun, 24 Oct 2021 16:30:54 +0200 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: <9B80FA4E8D90E6EF3349B423@PSB> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] rfc5321bis-05 preview and heads-up X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 24 Oct 2021 14:31:10 -0000 Hi, On Sat 23/Oct/2021 01:26:47 +0200 John C Klensin wrote: > > If such messages appear, I will incorporate their content if time permits > and they seem uncontroversial but, even if I don't, getting text posted now > would probably allow useful discussion before we meet at IETF 112. May I re-re-propose text for ticket #19, comment 4? It's for Section 4.1.4, replacing the paragraph that contains CREF13 with the following two-liner: An SMTP server MAY verify the validity of the domain name argument in the EHLO command. See [A/S] for further discussion. In fact, w.r.t. previous text proposals, verifying that the domain name argument resolves to the other side of the TCP connection is not the only type of verification that servers carry out. With the advent of MPTCP it might change even further. Best Ale -- From nobody Sun Oct 24 08:01:25 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6053F3A1528 for ; Sun, 24 Oct 2021 08:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLmAnxUm48sW for ; Sun, 24 Oct 2021 08:01:19 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EC0A3A1520 for ; Sun, 24 Oct 2021 08:01:18 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1meezs-000GdI-GP; Sun, 24 Oct 2021 11:01:16 -0400 Date: Sun, 24 Oct 2021 11:01:10 -0400 From: John C Klensin To: Alessandro Vesely , emailcore@ietf.org Message-ID: In-Reply-To: <519bad00-0619-f53f-e474-516b92f687e3@tana.it> References: <9B80FA4E8D90E6EF3349B423@PSB> <519bad00-0619-f53f-e474-516b92f687e3@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] rfc5321bis-05 preview and heads-up X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 24 Oct 2021 15:01:23 -0000 --On Sunday, October 24, 2021 16:30 +0200 Alessandro Vesely wrote: > Hi, > > On Sat 23/Oct/2021 01:26:47 +0200 John C Klensin wrote: >> >> If such messages appear, I will incorporate their content if >> time permits and they seem uncontroversial but, even if I >> don't, getting text posted now would probably allow useful >> discussion before we meet at IETF 112. > > > May I re-re-propose text for ticket #19, comment 4? It's for > Section 4.1.4, replacing the paragraph that contains CREF13 > with the following two-liner: > > > An SMTP server MAY verify the validity of the domain > name argument in > the EHLO command. See [A/S] for further discussion. Mostly already done in -05 (which I'm getting ready to post). There is a broader question about what to say about forward referencing to the A/S and how to say it that may be better for a discussion during the meeting than trying to sort it out in email. I do wonder about the upper-case "MAY" in this case because I'm not sure it communicates anything, but I'm not going to change it unless the WG decides it is an issue. > In fact, w.r.t. previous text proposals, verifying that the > domain name argument resolves to the other side of the TCP > connection is not the only type of verification that servers > carry out. With the advent of MPTCP it might change even > further. First, that is one of the reasons I question "MAY" (see above). Second, please reread Sections 7.8 and 7.9. They appear to me to cover other types of verification and no one has proposed opening them yet. Finally, unlike 821, 5321 (and 5321bis so far) are specifications for SMTP over TCP. If you think we should be considering MTCP (or any other transport-level protocol), propose a charter change and consider what would be needed to keep these documents on the path to Internet Standard. best, john From nobody Sun Oct 24 08:43:27 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068C43A045B for ; Sun, 24 Oct 2021 08:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.45 X-Spam-Level: X-Spam-Status: No, score=-5.45 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=-3.33, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=hruwOhJX; dkim=pass (1152-bit key) header.d=tana.it header.b=BR08mo7J Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_Lzsu5QmJDS for ; Sun, 24 Oct 2021 08:43:19 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91C983A041C for ; Sun, 24 Oct 2021 08:43:17 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1635090193; bh=KLUozBEQWBpILl+nHTwm9C2mkKhTjykbZEKPZKdL3Aw=; l=2100; h=Subject:To:References:From:Date:In-Reply-To; b=hruwOhJXHlN8DXqQMh1ks6Dfd96OnBx6fgHR8VX2QtmSf+4vfTiaeCzENhZ9krZRQ lW2UQE0eEQriO0NZNPhCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1635090193; bh=KLUozBEQWBpILl+nHTwm9C2mkKhTjykbZEKPZKdL3Aw=; l=2100; h=To:References:From:Date:In-Reply-To; b=BR08mo7J++A1+wyJuJ7k1JR7c7PEkn0r6vKylDxtx2HTKQaiQjrOq8SZfQi0xgrZr 18UxyvxyyzWYHVHL211ZEqZ9REhul5QhxdoDsFHMwCJ1FkLlkDvh549huqODxCiL78 v42IAe6RES6nvvoBKLJjvBPKCA8jlgk2Y+QQ067hEZUrK0WOJOV1RX6q9Np6D 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 00000000005DC042.0000000061757F10.00006C0C; Sun, 24 Oct 2021 17:43:12 +0200 To: emailcore@ietf.org References: <9B80FA4E8D90E6EF3349B423@PSB> <519bad00-0619-f53f-e474-516b92f687e3@tana.it> From: Alessandro Vesely Message-ID: <985590ff-9f4d-eb7a-9618-37242f98151c@tana.it> Date: Sun, 24 Oct 2021 17:43:12 +0200 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: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] rfc5321bis-05 preview and heads-up X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 24 Oct 2021 15:43:26 -0000 On Sun 24/Oct/2021 17:01:10 +0200 John C Klensin wrote: > --On Sunday, October 24, 2021 16:30 +0200 Alessandro Vesely wrote: >> On Sat 23/Oct/2021 01:26:47 +0200 John C Klensin wrote: >>> >>> If such messages appear, I will incorporate their content [...] >> >> May I re-re-propose text for ticket #19, comment 4? It's for >> Section 4.1.4, replacing the paragraph that contains CREF13 >> with the following two-liner: >> >> >> An SMTP server MAY verify the validity of the domain name argument in >> the EHLO command. See [A/S] for further discussion. > > Mostly already done in -05 (which I'm getting ready to post). Great! > I do wonder about the upper-case "MAY" in this case because I'm > not sure it communicates anything, but I'm not going to change > it unless the WG decides it is an issue. > >> In fact, w.r.t. previous text proposals, verifying that the >> domain name argument resolves to the other side of the TCP >> connection is not the only type of verification that servers >> carry out. With the advent of MPTCP it might change even >> further. > > First, that is one of the reasons I question "MAY" (see above). It is stated that way in RFC 5321. If we want to further retract the rest of that paragraph, we could add: However, if the verification fails, the server MAY refuse to accept a message on that basis. > Second, please reread Sections 7.8 and 7.9. They appear to me > to cover other types of verification and no one has proposed > opening them yet. Finally, unlike 821, 5321 (and 5321bis so > far) are specifications for SMTP over TCP. If you think we > should be considering MTCP (or any other transport-level > protocol), propose a charter change and consider what would be > needed to keep these documents on the path to Internet Standard. While sticking to TCP transport, Multipath TCP is designed to be fully compatible with it. If it will eventually make it to main stream kernel, all servers which install it will be actually running MPTCP, possibly unwittingly. Best Ale -- From nobody Sun Oct 24 10:04:55 2021 Return-Path: X-Original-To: emailcore@ietf.org Delivered-To: emailcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 957F53A0A3E; Sun, 24 Oct 2021 10:04:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emailcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <163509508956.11685.2935620014682204259@ietfa.amsl.com> Date: Sun, 24 Oct 2021 10:04:49 -0700 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5321bis-05.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: Sun, 24 Oct 2021 17:04:50 -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-05.txt Pages : 118 Date : 2021-10-24 Abstract: This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. This document replaces RFC 5321, the earlier version with the same title. [[CREF1: Note in Draft: Except for the last sentence, the above is unchanged from 5321 and may need adjusting in the light of RFC 6409 (Message Submission) as an Internet Standard.]] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5321bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-rfc5321bis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 24 11:13:03 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FBA3A0827 for ; Sun, 24 Oct 2021 11:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=episteme.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 ZpDimBXj4Kj7 for ; Sun, 24 Oct 2021 11:12:56 -0700 (PDT) Received: from helm.helm.episteme.net (helm.helm.episteme.net [209.51.32.195]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9C03A0825 for ; Sun, 24 Oct 2021 11:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=episteme.net; s=mail; t=1635099173; bh=CJWsb0Urs5vde0tIBBm9vd59WzmcrJHhoH0zYprHRn4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=A/kdmaRp7nmXoN+JmtVMi156ZnQ/RXFAwkNxuuBOVuJoYeCu0vlk431l4dISIh4ZQ DUzK2WzFirBOrz45rZzbi3Jk7K2eGCTonl8oWoP/n0cXg1vs25toY1vENs89x/w5J/ Zp2hzQ9nK9n2X4dK2eoSVdGRTkilxD8cz/Jb4Qkc= From: Pete Resnick To: John C Klensin Cc: Alessandro Vesely , emailcore@ietf.org Date: Sun, 24 Oct 2021 13:12:50 -0500 X-Mailer: MailMate (1.14r5820) Message-ID: In-Reply-To: References: <9B80FA4E8D90E6EF3349B423@PSB> <519bad00-0619-f53f-e474-516b92f687e3@tana.it> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_3E67EC49-672D-4DBB-9B91-0EC8B1897D6C_=" Archived-At: Subject: Re: [Emailcore] rfc5321bis-05 preview and heads-up X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 24 Oct 2021 18:13:01 -0000 --=_MailMate_3E67EC49-672D-4DBB-9B91-0EC8B1897D6C_= Content-Type: text/plain; format=flowed On 24 Oct 2021, at 10:01, John C Klensin wrote: >> An SMTP server MAY verify the validity of the domain name argument in >> the EHLO command. See [A/S] for further discussion. > > I do wonder about the upper-case "MAY" in this case because I'm not > sure it communicates anything, but I'm not going to change it unless > the WG decides it is an issue. I am reminded of the printed instructions I got from the doctor after being on anesthetic: "DO NOT COOK USING THE STOVE; YOU MAY START A FIRE AND INJURE YOURSELF" I was not, AFAICT, being given permission to start a fire or injure myself. My take is that MAY in standards should be used to express permission to the actor, and more importantly to express a warning to someone interacting with the actor that this option might occur. Mostly, that's important when the actor is sending something in the protocol stream that the recipient is going to have to deal with. In this case, we are saying it is permissible for a server receiving the command to do (or not do) the verifications, so we are warning sender of the command that it might be verified (or not). (*shrug*) I guess that it's good for the sender of the command to know that they best put something reasonable in there, but that usually dictates a MUST or SHOULD on the sending side, not a MAY on the receiving side. But all that to say: "Whatever." It's generally superfluous. pr --=_MailMate_3E67EC49-672D-4DBB-9B91-0EC8B1897D6C_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

On 24 Oct 2021, at 10:01, John C Klensin wrote:

An SMTP server MAY ver= ify the validity of the domain name argument in the EHLO command. See [= A/S] for further discussion.

I do wonder about the upper-case "MAY" in th= is case because I'm not sure it communicates anything, but I'm not going = to change it unless the WG decides it is an issue.

I am reminded of the printed instructions I got from the = doctor after being on anesthetic:

"DO NOT COOK USING THE STOVE; YOU MAY START A FIRE AND IN= JURE YOURSELF"

I was not, AFAICT, being given permission to start a fire= or injure myself.

My take is that MAY in standards should be used to expres= s permission to the actor, and more importantly to express a warning to s= omeone interacting with the actor that this option might occur. Mostly, t= hat's important when the actor is sending something in the protocol strea= m that the recipient is going to have to deal with. In this case, we are = saying it is permissible for a server receiving the command to do (or not= do) the verifications, so we are warning sender of the command that it m= ight be verified (or not). (shrug) I guess that it's good for th= e sender of the command to know that they best put something reasonable i= n there, but that usually dictates a MUST or SHOULD on the sending side, = not a MAY on the receiving side. But all that to say: "Whatever." It's ge= nerally superfluous.

pr

--=_MailMate_3E67EC49-672D-4DBB-9B91-0EC8B1897D6C_=-- From nobody Sun Oct 24 11:19:26 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F246C3A0062 for ; Sun, 24 Oct 2021 11:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.43 X-Spam-Level: X-Spam-Status: No, score=-5.43 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=-3.33, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDF4JDPHfCql for ; Sun, 24 Oct 2021 11:19:19 -0700 (PDT) Received: from fossa.birch.relay.mailchannels.net (fossa.birch.relay.mailchannels.net [23.83.209.62]) (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 9CC3F3A086C for ; Sun, 24 Oct 2021 11:19:19 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 21D536E1139; Sun, 24 Oct 2021 18:19:18 +0000 (UTC) Received: from gcp-us-central1-a-smtpout2.hostinger.io (unknown [127.0.0.6]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 3A7D46E118C; Sun, 24 Oct 2021 18:19:17 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from gcp-us-central1-a-smtpout2.hostinger.io (gcp-us-central1-a-smtpout2.hostinger.io [35.192.45.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.114.196.210 (trex/6.4.3); Sun, 24 Oct 2021 18:19:17 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Interest-Shelf: 2b3ef5787631eaaa_1635099557782_3986717933 X-MC-Loop-Signature: 1635099557782:2163374685 X-MC-Ingress-Time: 1635099557782 Received: from [192.168.0.111] (unknown [98.42.204.36]) (Authenticated sender: dhc@dcrocker.net) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 2DD85310E1ED; Sun, 24 Oct 2021 18:19:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1635099556; bh=k6WXmg+LZc6ajWbPGORvQyowVySpSdCs0jJJP+6fJWg=; h=Date:Reply-To:Subject:To:Cc:References:From:In-Reply-To; b=ZJTwLIYq2akJCkefNnbCoy6IehyIvSa6rC7CDhQxGwxGG7T/YmyFB/flXsUQJuMt7 odyCu239BKgTZYFvCoYqVkArEw1Pww5DdZW+JTTZmxkXMg5fGAPm/WUzT8JFVc8swm ayDx+1DEI55wY6ZIYgNQeCU0BfFCm8wf15opCPaMltVT6BXqO8NZdbMHbM0JZJ40UM AkWBDii7Y99bIsyyU7JurWQtO6SIiOdpTzpZF6zHxa+tvTjjwTyaSupoomFCnPK/GY y7xb7AKr9/84uQmKGid8vVsf3l4Bo02Jy7ei1Gpx75xYjqot1fPiHPoUbZ+/ROtSUM I4mI9QE4C5vhA== Message-ID: Date: Sun, 24 Oct 2021 11:19:11 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Reply-To: dcrocker@bbiw.net Content-Language: en-US To: Pete Resnick , John C Klensin Cc: emailcore@ietf.org, Alessandro Vesely References: <9B80FA4E8D90E6EF3349B423@PSB> <519bad00-0619-f53f-e474-516b92f687e3@tana.it> 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] rfc5321bis-05 preview and heads-up X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 24 Oct 2021 18:19:25 -0000 On 10/24/2021 11:12 AM, Pete Resnick wrote: > Mostly, that's important when the actor is sending something in the > protocol stream that the recipient is going to have to deal with. In > this case, we are saying it is permissible for a server receiving the > command to do (or not do) the verifications, so we are warning sender of > the command that it might be verified (or not). The problem is that it's normative language that a) does not pertain to an actual protocol component, and b) does not specify something that can reasonably be controlled by the presence or absence of the MAY. Servers can and do reject sessions for all sorts of reasons. Giving them "permission" for this one case is in the noise, at best. That is, it's meaningless. It's the sort of text that looks intuitively reasonable but is not actually useful. To the extent that the goal is to give notice about some of the reasons a server might choose to reject a message or a connection -- beyond the definition of response codes -- that makes more sense to have in a document for operational guidance. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Oct 24 11:49:31 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A76A3A0827 for ; Sun, 24 Oct 2021 11:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9o-QefSstqd for ; Sun, 24 Oct 2021 11:49:26 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A1C3A0771 for ; Sun, 24 Oct 2021 11:49:06 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1meiYL-000GwL-6O for emailcore@ietf.org; Sun, 24 Oct 2021 14:49:05 -0400 Date: Sun, 24 Oct 2021 14:48:58 -0400 From: John C Klensin To: emailcore@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Emailcore] draft-ietf-emailcore-rfc5321bis-05 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 24 Oct 2021 18:49:30 -0000 Hi. As promised, draft-ietf-emailcore-rfc5321bis-05 has been posted. Discussion of most of the issues it addresses appeared in the notes that I posted Friday. There is a change log, as usual, this time in H.3.9. There are two additional issues that the WG should address at some point, perhaps during IETF 112, or we could decide to put them off: (1) As noted in my exchange with Ale a couple of hours ago, we need to figure out just what 5321bis is going to say about the A/S, where to put in forward pointers, etc. To make doing anything at all easier in the future, I've put a reference to the A/S [1] into the document but it is not anchored. Instead there is assorted text, some temporary that either asserts what will be in the A/S, asks questions about it, or involves conditionals about whether it will be produced. (2) For someone trying to find information in RFC 5321, it is very difficult to navigate without the fourth-level sections (the ones with, e.g., the command names in them) in the Table of Contents and/or a working index. As of today, the bug(s) that prevented those TOC entries from appearing in RFC 5321 are still present and the index is still tied to page numbers that do not appear in the PDF form at all. The HTML is ok, but I have no idea what would happen if a given term were indexed from more than one location. The question for the WG is whether we are willing to live with whatever the state of the tools happens to be when the document is ready or do we want to push for something more usable. best, john [1] Reference [51] in Section 10.2, "Informative References" From nobody Sun Oct 24 12:02:33 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64753A0970; Sun, 24 Oct 2021 12:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_Oo0jyXiCHW; Sun, 24 Oct 2021 12:02:25 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90423A08E7; Sun, 24 Oct 2021 12:02:22 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1meilA-000Gxj-FS; Sun, 24 Oct 2021 15:02:20 -0400 Date: Sun, 24 Oct 2021 15:02:13 -0400 From: John C Klensin To: dcrocker@bbiw.net, Pete Resnick cc: emailcore@ietf.org, Alessandro Vesely Message-ID: <5E12FD2D5187630F39FB8165@PSB> In-Reply-To: References: <9B80FA4E8D90E6EF3349B423@PSB> <519bad00-0619-f53f-e474-516b92f687e3@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] rfc5321bis-05 preview and heads-up X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 24 Oct 2021 19:02:33 -0000 FWIW, I agree with both Dave and Pete, and considerations similar to their different ones were the reason I identified the issue. Given RFC 8174, I could apply the principle of minimum change and just drop that to "may" and we could then go about our business. Or I/we could figure out how to rewrite things to tell SMTP clients that they need to be careful and orderly about that information because some server might try to verify it and behave in a way that would not be conducive to the message getting through if the verification failed (an extension on Pete's observation). As editor, I have no opinion at the moment other than reluctance to start messing with this unless the WG clearly wants to. Too late for -05 (and hence our meeting at IETF 112) in any event. best, john --On Sunday, October 24, 2021 11:19 -0700 Dave Crocker wrote: > On 10/24/2021 11:12 AM, Pete Resnick wrote: >> Mostly, that's important when the actor is sending something >> in the protocol stream that the recipient is going to have >> to deal with. In this case, we are saying it is permissible >> for a server receiving the command to do (or not do) the >> verifications, so we are warning sender of the command that >> it might be verified (or not). > > > The problem is that it's normative language that a) does not > pertain to an actual protocol component, and b) does not > specify something that can reasonably be controlled by the > presence or absence of the MAY. > > Servers can and do reject sessions for all sorts of reasons. > Giving them "permission" for this one case is in the noise, at > best. That is, it's meaningless. It's the sort of text that > looks intuitively reasonable but is not actually useful. > > To the extent that the goal is to give notice about some of > the reasons a server might choose to reject a message or a > connection -- beyond the definition of response codes -- that > makes more sense to have in a document for operational > guidance. > > d/ From nobody Mon Oct 25 03:00:12 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8280A3A08F9 for ; Mon, 25 Oct 2021 03:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=r/FZAaZ1; dkim=pass (1152-bit key) header.d=tana.it header.b=A04WXB+B Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90LU59bX2LHN for ; Mon, 25 Oct 2021 03:00:04 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0373A08FA for ; Mon, 25 Oct 2021 03:00:02 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1635155997; bh=0OQaLJUjppJ77eCbPQPC3gmEeT3PrAWXKDJvNRQ1w9E=; l=2389; h=Subject:To:References:From:Date:In-Reply-To; b=r/FZAaZ1FgEYQmOchi7g9JlhJTzdWSZu/ytcOT+2BdclZxeCF7CdfASmAjMFoF6gl 0pckD1oCUX5DXtI2TI2DQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1635155997; bh=0OQaLJUjppJ77eCbPQPC3gmEeT3PrAWXKDJvNRQ1w9E=; l=2389; h=To:References:From:Date:In-Reply-To; b=A04WXB+BtkRZOcdpYdNB3EXrKxselpU5q7j7dtLTjt2EaPSINPG7+J+j+ueR7Dcat r+TKWCErtbQmC8kGms3QGzVBOUEjKZmHRVdW60zppsKzHJgATzMjE1e3sOO+f78lDh eFNeVNX3bA0nZKwlaypSvh64XgnLLV3fsMA9zpFPdgpNspsJCfv85Nmz2Bskw Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC03D.000000006176801D.00003E49; Mon, 25 Oct 2021 11:59:57 +0200 To: dcrocker@bbiw.net, Pete Resnick , John C Klensin , emailcore@ietf.org References: <9B80FA4E8D90E6EF3349B423@PSB> <519bad00-0619-f53f-e474-516b92f687e3@tana.it> From: Alessandro Vesely Message-ID: <192dd888-a82e-cb52-58d7-2a2fa12d2268@tana.it> Date: Mon, 25 Oct 2021 11:59:55 +0200 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Emailcore] The domain name argument in the EHLO command, was rfc5321bis-05 preview and heads-up X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 25 Oct 2021 10:00:12 -0000 On Sun 24/Oct/2021 20:19:11 +0200 Dave Crocker wrote: > On 10/24/2021 11:12 AM, Pete Resnick wrote: > >> In this case, we are saying it is permissible for a server receiving the >> command to do (or not do) the verifications, so we are warning sender of >> the command that it might be verified (or not). > > Servers can and do reject sessions for all sorts of reasons.  Giving them > "permission" for this one case is in the noise, at best.  That is, it's > meaningless.  It's the sort of text that looks intuitively reasonable but is > not actually useful. The point is to stress that the domain name argument in the EHLO command is an essential identifier. That stress is needed because, in the past, phrases like "the server MUST NOT refuse to accept a message on that basis" have been used to infer that one can write whatever it likes in the EHLO command. Because of this reason, for example, DMARC discards the domain name given here. Domain alignment becomes more and more important to sort out email traffic, and reliability of Received: chains depends on the domain name given in EHLO. It can be verified according to SPF or iprev methods, defined in their own RFCs. To verify that the domain name resolves to the actual IP address of the remote connection is an obvious method which, AFAIK, is not described in any standard document. RFC1123 mentions that such test is possible, but postpones it to offline checking of Received: fields: DISCUSSION: Including both the source host and the IP source address in the Received: line may provide enough information for tracking illicit mail sources and eliminate a need to explicitly verify the HELO parameter. Perhaps, RFC5321-bis could specify in the last paragraph of Section 2.3.5 that the resolved domain address must match the connecting IP. Or perhaps the A/S could fully describe this method and assign an Authentication-Results: keyword to it. For Section 4.1.4, IMHO, there is no reason why generic verifications of the domain name argument should be limited to this method only. At any rate, since a server can reject an invalid EHLO, the next question is going to be what its consequences are. I think we don't want to fail the EHLO command itself. Should the spec say that rejections shall reveal themselves when/if transactions are attempted? Best Ale -- From nobody Mon Oct 25 05:01:49 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329393A0A83 for ; Mon, 25 Oct 2021 05:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=KAbIn0SH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KD742ycv Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYXDRy9ilWun for ; Mon, 25 Oct 2021 05:01:43 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9423A08C0 for ; Mon, 25 Oct 2021 05:01:16 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 043015C0181; Mon, 25 Oct 2021 08:01:16 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 25 Oct 2021 08:01:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-type:content-transfer-encoding:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; s=fm1; bh=ruSN2nI LcNk5Qk00gPrVPsuR2cpHYBoyCS1pArnaNic=; b=KAbIn0SH7aIQE3d7rhizlT+ fgCFuRrvGAc3QECf150pkLZMdGjsj9X6a9Uz0J0pu6vHgAxzUHqYh9zS8i8R2l6q fF0lnQpsTcneIvJHqmcal1zLPDKZ/mXX/0X1VQyszXI4vIYCBWMm9R2clvFZIAKZ PEfA1f1p55p4S0cTEQh94OuvQ19I80eUHTyHKP+ZDP1XtVIExjW7gzq1DZpzLXGG S/KaV0FQ7lUGxfC6vpZvUejyXaKAkVJ3U4CySLeDBO6Vwss6ydYeK/0vX0ZQG83J tE/ojPVNhQHmNl6hL9ZtfPGR83BjAkR7ca6W9zYzALVF6vZuLvOP0Ott1aAiDZQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=ruSN2nILcNk5Qk00gPrVPsuR2cpHYBoyCS1pArnaN ic=; b=KD742ycv3Yc9w368mNzn/bS0vdrRI1mGYnsboPI5hCudKT251rW34nC51 nAwGu7d23VX95XoWs+QlsA1xbODrPd8aVJks9RmFl0mSR4E9ajFdbjP/7XUeCYFn IXVBTdGoEfusAowpTTNpmf9nhLwq4mtjCMSNRFQs/bSqkL2xbz2Db1zk45RjPH3F kFea4FmMdezEPRjMxUfmjkJD2xkClwVWVf61PRWP+nivYCkW150h+NeWwlYvHqwb U9Eh51s2zS4fPjOYWisKmPWPx/9avfxkO3YPoMBucBY+cnPzY/MQXBNriS9YLXRA tD1mLBopbhqRPHXQljEsincpL+ftw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdefhedggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptgfgggfuhfgjfffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlvgig vgihucfovghlnhhikhhovhcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh eqnecuggftrfgrthhtvghrnhephfegtdegvdejjeevueeiteffudelueeufefhjeekvedt gfefgfevtdefiedtvdevnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhes fhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 25 Oct 2021 08:01:13 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Alexey Melnikov In-Reply-To: <5E12FD2D5187630F39FB8165@PSB> Date: Mon, 25 Oct 2021 13:01:12 +0100 Cc: dcrocker@bbiw.net, Pete Resnick , emailcore@ietf.org, Alessandro Vesely Message-Id: References: <5E12FD2D5187630F39FB8165@PSB> To: John C Klensin X-Mailer: iPhone Mail (18H17) Archived-At: Subject: Re: [Emailcore] rfc5321bis-05 preview and heads-up X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 25 Oct 2021 12:01:48 -0000 > On 24 Oct 2021, at 20:02, John C Klensin wrote: >=20 > =EF=BB=BFFWIW, I agree with both Dave and Pete, and considerations > similar to their different ones were the reason I identified the > issue. Given RFC 8174, I could apply the principle of minimum > change and just drop that to "may" and we could then go about > our business. I think lowercase may is the right thing here. > Or I/we could figure out how to rewrite things > to tell SMTP clients that they need to be careful and orderly > about that information because some server might try to verify > it and behave in a way that would not be conducive to the > message getting through if the verification failed (an extension >> on Pete's observation). >>=20 >> As editor, I have no opinion at the moment other than reluctance >> to start messing with this unless the WG clearly wants to. Too >> late for -05 (and hence our meeting at IETF 112) in any event. >>=20 >> best, >> john >>=20 >>=20 >> --On Sunday, October 24, 2021 11:19 -0700 Dave Crocker >> wrote: >>=20 >>> On 10/24/2021 11:12 AM, Pete Resnick wrote: >>> Mostly, that's important when the actor is sending something >>> in the protocol stream that the recipient is going to have >>> to deal with. In this case, we are saying it is permissible >>> for a server receiving the command to do (or not do) the >>> verifications, so we are warning sender of the command that >>> it might be verified (or not). >>=20 >>=20 >> The problem is that it's normative language that a) does not >> pertain to an actual protocol component, and b) does not >> specify something that can reasonably be controlled by the >> presence or absence of the MAY. >>=20 >> Servers can and do reject sessions for all sorts of reasons. >> Giving them "permission" for this one case is in the noise, at >> best. That is, it's meaningless. It's the sort of text that >> looks intuitively reasonable but is not actually useful. >>=20 >> To the extent that the goal is to give notice about some of >> the reasons a server might choose to reject a message or a >> connection -- beyond the definition of response codes -- that >> makes more sense to have in a document for operational >> guidance. >>=20 >> d/ >=20 >=20 > --=20 > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore From nobody Mon Oct 25 08:05:59 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8255B3A0BA0 for ; Mon, 25 Oct 2021 08:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.427 X-Spam-Level: X-Spam-Status: No, score=-5.427 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=-3.33, 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=hRxu1PXZ; dkim=pass (2048-bit key) header.d=wizmail.org header.b=P555pnAg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIX9Pvfokp91 for ; Mon, 25 Oct 2021 08:05:52 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C86403A0BDC for ; Mon, 25 Oct 2021 08:05:51 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To: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=Q35WRbgQ21SZfET3PKkp1LgxrGcf7xD08AkoHeJBqqA=; b=hRxu1PXZqIsJNRHH2LXpbDeEXR uTcEwdHzeyU16oyv2hkeHbK7iSyug40ctpkIuZmr15NZoq2/tjykLIhb9SDg==; 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=Q35WRbgQ21SZfET3PKkp1LgxrGcf7xD08AkoHeJBqqA=; b=P555pnAgUZXQik7vkndL2m1H7M N+QUS1sJchKFQiByw3sJ7TOVDPpO1eBSGJDZlXhuXdP4AOd95hl7Fmzr+CDgLBpEZ9u9ajGFITapR FSzgAOzyqVdpVD+++Vy1ikRfY/wMV5QdHnsiqCvnH2lrACM97NZvPybNOvSmAReTXYszkhzj5prD5 f76pjfJ8jI4xlcRRtK/F6Ky/hvTBnau4hkM7UPVXAjM1bRsB6V9YDGT6WZ86T8jor0Y8yZhwhyTuL NXinum82/OYTfDRz6nANonFOFoKER/tgePKn/bpsLPSWaB1CvxQ/8IKR5nfYsKQhysmpZUNJKgnH3 zzj6mB6w==; 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.101) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1mf1Xn-000Ebn-21 for emailcore@ietf.org (return-path ); Mon, 25 Oct 2021 15:05:47 +0000 Message-ID: <2f429a00-6b8f-a9ba-5638-d78b49708416@wizmail.org> Date: Mon, 25 Oct 2021 16:05:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 Content-Language: en-GB To: emailcore@ietf.org References: <9B80FA4E8D90E6EF3349B423@PSB> <519bad00-0619-f53f-e474-516b92f687e3@tana.it> <192dd888-a82e-cb52-58d7-2a2fa12d2268@tana.it> From: Jeremy Harris In-Reply-To: <192dd888-a82e-cb52-58d7-2a2fa12d2268@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] The domain name argument in the EHLO command, was rfc5321bis-05 preview and heads-up X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 25 Oct 2021 15:05:58 -0000 On 25/10/2021 10:59, Alessandro Vesely wrote: > At any rate, since a server can reject an invalid EHLO, the next question is going to be what its consequences are.  I think we don't want to fail the EHLO command itself. I think you will find that this does indeed happen. -- Cheers, Jeremy From nobody Mon Oct 25 08:21:39 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18943A0AC4 for ; Mon, 25 Oct 2021 08:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.229 X-Spam-Level: X-Spam-Status: No, score=-5.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-3.33, 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 2yCHPvJs3QQT for ; Mon, 25 Oct 2021 08:21:34 -0700 (PDT) Received: from mail-ob.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4CD3A0AE2 for ; Mon, 25 Oct 2021 08:21:33 -0700 (PDT) Received: (qmail 2662556 invoked from network); 25 Oct 2021 15:21:31 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by be.cityemail.com with (TLS_AES_128_GCM_SHA256 encrypted) SMTP (3b129494-35a7-11ec-9f03-c7837cb8470e); Mon, 25 Oct 2021 08:21:31 -0700 To: emailcore@ietf.org References: <9B80FA4E8D90E6EF3349B423@PSB> <519bad00-0619-f53f-e474-516b92f687e3@tana.it> <192dd888-a82e-cb52-58d7-2a2fa12d2268@tana.it> <2f429a00-6b8f-a9ba-5638-d78b49708416@wizmail.org> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: Date: Mon, 25 Oct 2021 08:21:30 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <2f429a00-6b8f-a9ba-5638-d78b49708416@wizmail.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 2.2.x-3.x X-MagicMail-UUID: 3b129494-35a7-11ec-9f03-c7837cb8470e X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [Emailcore] The domain name argument in the EHLO command, was rfc5321bis-05 preview and heads-up X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 25 Oct 2021 15:21:39 -0000 On 2021-10-25 8:05 a.m., Jeremy Harris wrote: > On 25/10/2021 10:59, Alessandro Vesely wrote: >> At any rate, since a server can reject an invalid EHLO, the next >> question is going to be what its consequences are.  I think we don't >> want to fail the EHLO command itself. > > I think you will find that this does indeed happen. Yes, we fail at the EHLO stage under certain circumstances. It's the obvious approach for an obvious threat. And of course, all the broken 'bots' out there. However, remember the concept of 'invalid' EHLO has to be flexible enough to allow different MTA's and operators to have their own definition of 'invalid', and it should NOT be too explicit. Eg, there are valid use cases where the EHLO does not match the public PTR, and instead represents an internal networking definition of the 'server name'. But we should be able to agree that at least the EHLO should be a FQDN for MTA->MTA traffic, and that we have to be much more flexible on MTU-MTA traffic, but it should never be undefined.. eg 127.0.0.1. Every MTU should have a host name for instance. But 'invalid' COULD simply be a regex definition that the operator chooses to use. In theory, (not recommending this) an operator could consider any use of a specific TLD as 'invalid' to their operations. But it should be defined as 'fixed', eg a MTU or MTA must NOT use a random value for EHLO. (Just love that bot that keeps doing that, trying to pretend it's different MTU's behind a CGN, use of random EHLO is an automatic block in our world) -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Mon Oct 25 08:41:08 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C9A3A0BF4; Mon, 25 Oct 2021 08:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gm_BTFtM5HL0; Mon, 25 Oct 2021 08:40:52 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9243A0A90; Mon, 25 Oct 2021 08:40:50 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mf25c-000Js8-CU; Mon, 25 Oct 2021 11:40:44 -0400 Date: Mon, 25 Oct 2021 11:40:38 -0400 From: John C Klensin To: Alessandro Vesely , dcrocker@bbiw.net, Pete Resnick , emailcore@ietf.org Message-ID: <81C362FBFCA1E82B614B4DE4@PSB> In-Reply-To: <192dd888-a82e-cb52-58d7-2a2fa12d2268@tana.it> References: <9B80FA4E8D90E6EF3349B423@PSB> <519bad00-0619-f53f-e474-516b92f687e3@tana.it> <192dd888-a82e-cb52-58d7-2a2fa12d2268@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] The domain name argument in the EHLO command, was rfc5321bis-05 preview and heads-up X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 25 Oct 2021 15:41:05 -0000 Ale, (personal opinion, no hat). It seems to me that, whether your ideas are correct or incorrect, you are headed down a new path. First, remember that imposing new requirements in 5321bis takes us very close to the line at which we'd need to reset to Proposed Standard, rather than going to full standard. As I interpret the rules (again personal opinion), such new requirements would be justified in a document going to Internet Standard only if there were clear proof that the absence of those requirements was causing interoperability harm, not that they would make a different protocol work better. =20 FWIW, I think the WG's charter prohibits even getting into that type of issue as far as 5321bis is concerned. I'd appreciate it if the WG Chairs would speak to that. If one sets that concern aside and wants to charge ahead on the subject, then this is, as others have pointed out, really a requirement on what SMTP-senders can put into that field, not something we should be trying to affect by vague comments about what the server might do (much less playing around with how we spell "MaY" or "maY" (presumably different degrees of non-requirement :-( ). However, that would probably push the Internet Standard requirement (and the charter) even further. So, two suggestions, with the understanding that, as a WG participant (even more than as an editor), I want this work, especially the 5321bis/5322bis parts, done and done at a higher rate and with more active participation by more people than I'm seeing,=20 (1) Go silent on this subject until 5321bis is under control, then push for text in the A/S. I don't know whether that document could reasonably impose new requirements either, but it could certainly explain why better quality EHLO arguments would benefit both client and server and strongly encourage them. or, if you want to fix 5321bis... (2) Generate an I-D, right now (ideally making the posting deadline but otherwise begging Murray for permission for a late submission), in Proposed Standard form that modifies RFC 5321 to specify whatever you think needs to be specified, updating the SPF/ DKIM/ etc. documents as needed to clarify the relationships between the EHLO domain or address-literal and other fields. Make sure it describes current practice rather than speculating. Convince Murray (or Francesca) to AD-sponsor it or to add it to the charter of this WG. For the latter case, convince the WG to put 5321bis on hold until your draft is discussed and processed. If you can get it approved as PS and this WG continues at the pace we seem to have adopted, we could easily be still fussing with 5321bis when your six months runs out, you write an implementation report, and then argue that the substance of the I-D should be folded into 5321bis. In either case -- and this may be affecting my personal skepticism -- I'm concerned both about the number of environments in which those who configure SMTP services may not have nearly as much control over those responsible for the local DMS zone as we might like, about clusters of machines that share functions but not addresses, and about an assortment of edge cases that might lead to more use of address literals if we impose more rigid requirements on EHLO domains. I think that would be a step backwards; YMMD. But, right now, in this forum and on this thread, I don't see the discussion as leading anywhere useful wrt 5321bis. Again, just my personal opinion. best, john --On Monday, October 25, 2021 11:59 +0200 Alessandro Vesely wrote: > On Sun 24/Oct/2021 20:19:11 +0200 Dave Crocker wrote: >> On 10/24/2021 11:12 AM, Pete Resnick wrote: >>=20 >>> In this case, we are saying it is permissible for a server >>> receiving the command to do (or not do) the verifications, >>> so we are warning sender of the command that it might be >>> verified (or not). > >> Servers can and do reject sessions for all sorts of >> reasons.=C2=A0 Giving them "permission" for this one case is = in >> the noise, at best.=C2=A0 That is, it's meaningless.=C2=A0 = It's the >> sort of text that looks intuitively reasonable but is not >> actually useful. >=20 >=20 > The point is to stress that the domain name argument in the > EHLO command is an essential identifier. That stress is > needed because, in the past, phrases like "the server MUST NOT > refuse to accept a message on that basis" have been used to > infer that one can write whatever it likes in the EHLO > command. Because of this reason, for example, DMARC discards > the domain name given here. >=20 > Domain alignment becomes more and more important to sort out > email traffic, and reliability of Received: chains depends on > the domain name given in EHLO. It can be verified according > to SPF or iprev methods, defined in their own RFCs. >=20 > To verify that the domain name resolves to the actual IP > address of the remote connection is an obvious method which, > AFAIK, is not described in any standard document. RFC1123 > mentions that such test is possible, but postpones it to > offline checking of Received: fields: >=20 > DISCUSSION: > Including both the source host and the IP > source address > in the Received: line may provide enough > information for > tracking illicit mail sources and eliminate a > need to > explicitly verify the HELO parameter. >=20 > Perhaps, RFC5321-bis could specify in the last paragraph of > Section 2.3.5 that the resolved domain address must match the > connecting IP. Or perhaps the A/S could fully describe this > method and assign an Authentication-Results: keyword to it. > For Section 4.1.4, IMHO, there is no reason why generic > verifications of the domain name argument should be limited to > this method only. >=20 > At any rate, since a server can reject an invalid EHLO, the > next question is going to be what its consequences are. I > think we don't want to fail the EHLO command itself. Should > the spec say that rejections shall reveal themselves when/if > transactions are attempted? >=20 >=20 > Best > Ale > --=20 From nobody Mon Oct 25 10:12:34 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C773A0DF4 for ; Mon, 25 Oct 2021 10:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.429 X-Spam-Level: X-Spam-Status: No, score=-5.429 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=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTcheX6xFWaL for ; Mon, 25 Oct 2021 10:12:23 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id A96E73A0DAE for ; Mon, 25 Oct 2021 10:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1635181941; d=isode.com; s=june2016; i=@isode.com; bh=/tPrFkcXANLd+AiA6v1bx9zswSvD/90wd0Vj0jxHo54=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=AGb5VdT7gqMBe1L/5aUG4OoPdoH+iR8WY4NA9d+/yJVmnCcRmAcrNXtyDUZ0bcNat3ojp1 lv98evKhS+0cQlDcjV8hALzdezF9yS7jlZeztodon9sOHRzEGFQu/r+qFZ1uCJBLkVi5Cc bGAGPUwOpTdfEoBCp/tHmGJqd2M+ftY=; Received: from [192.168.1.222] (host5-81-100-13.range5-81.btcentralplus.com [5.81.100.13]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 25 Oct 2021 18:12:20 +0100 From: Alexey Melnikov To: John C Klensin Cc: emailcore@ietf.org References: <914b4691-cea6-1a88-855d-0f9b19687e4a@isode.com> Message-ID: <710942fc-c3af-a720-f0b4-e6a3f57fcdae@isode.com> Date: Mon, 25 Oct 2021 18:12:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Ticket #7: Better definition for trace header fields (rfc5321bis changes only) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 25 Oct 2021 17:12:32 -0000 Hi John, On 22/10/2021 23:13, John C Klensin wrote: > Alexey, > > Thanks and sorry for the long delay in getting back to this. > > I have tried to implement this as I think you intended, but I > don't think part of it works. See below. > > --On Monday, October 4, 2021 16:33 +0100 Alexey Melnikov > wrote: > >> Hi John, >> >> Below I am summarizing proposed changed to 5321bis to address >> ticket #7. The changes only address trace header fields and >> other tickets remain unaffected. >> >> 1) Move the current content of Section 4.4 into Section 4.4.1. >> Rename it to be "Receive header field" (or similar). >> >> 2) Add the following paragraph to the now empty (other than >> the new subsection) 4.4: >> >> =C2=A0 Trace information is used to provide an audit trail of >> message handling. >> =C2=A0 In addition, it indicates a route back to the sender of >> the message. > Ok, but this leaves a subsection 4.4.1 without a 4.4.2. I > object to that editorially and the RFC Editor usually objects to > it as well. I had several RFCs published with a single subsection, so I personally=20 don't see this as an issue. > Do we need at least a stub 4.4.2 for "Return-path:" > which would solve that editorial problem? Or, IMO less > attractively, we could make the new paragraph 4.4.1 and the > Received text 4.4.2. That would also be acceptable to me, but what you've done in -05 looks=20 very reasonable as well. >> 3) In Section 2.3.10, 1st paragraph, last sentence: >> >> =C2=A0=C2=A0 A "relay" SMTP >> =C2=A0=C2=A0 system (usually referred to just as a "relay") receives >> mail from an >> =C2=A0=C2=A0 SMTP client and transmits it, without modification to >> the message >> =C2=A0=C2=A0 data other than adding trace information >> >> Insert cross reference to section 4.4 here. > Done. > >> =C2=A0=C2=A0 , to another SMTP server for >> =C2=A0=C2=A0 further relaying or for delivery. >> >> 4) In Section 3.6.3 (Message Submission Servers as Relays), >> last paragraph: >> >> =C2=A0=C2=A0 As discussed in Section 6.4, a relay SMTP has no need to >> inspect or >> =C2=A0=C2=A0 act upon the header section or body of the message data >> and MUST NOT >> =C2=A0=C2=A0 do so except to add its own "Received:" header field >> (Section 4.4) >> >> Change "Section 4.4" to "Section 4.4.1". Also add "and >> possibly other trace header fields" after it. > Done. If the "Received" subsection becomes 4.4.2 as in the > not-preferred solution about, this will auto-correct. Sure. >> =C2=A0=C2=A0 and, optionally, to attempt to detect looping in the >> mail system (see >> =C2=A0=C2=A0 Section 6.3).=C2=A0 Of course, this prohibition also appli= es >> to any >> =C2=A0=C2=A0 modifications of these header fields or text (see also >> Section 7.9). >> >> 5) In Section 7.6: >> >> =C2=A0=C2=A0 In some circumstances, such as when mail originates from >> within a LAN >> =C2=A0=C2=A0 whose hosts are not directly on the public Internet, >> trace >> =C2=A0=C2=A0 ("Received") header fields produced in conformance with >> this >> >> Insert "e.g." before "Received". > Done. > >> =C2=A0=C2=A0 specification may disclose host names and similar >> information that >> =C2=A0=C2=A0 would not normally be available.=C2=A0 This ordinarily doe= s >> not pose a >> =C2=A0=C2=A0 problem, but sites with special concerns about name >> disclosure should >> =C2=A0=C2=A0 be aware of it.=C2=A0 Also, the optional FOR clause should >> be supplied >> =C2=A0=C2=A0 with caution or not at all when multiple recipients are >> involved lest >> =C2=A0=C2=A0 it inadvertently disclose the identities of "blind copy" >> recipients >> =C2=A0=C2=A0 to others. As far as I am concerned, you resolved ticket #7 for rfc5321bis. Best Regards, Alexey From nobody Mon Oct 25 11:00:57 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4684B3A1193 for ; Mon, 25 Oct 2021 11:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.45 X-Spam-Level: X-Spam-Status: No, score=-5.45 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=-3.33, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=q/LZsp9U; dkim=pass (1152-bit key) header.d=tana.it header.b=Cq+tukNA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRbX2oSVNE2O for ; Mon, 25 Oct 2021 11:00:42 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36F673A1658 for ; Mon, 25 Oct 2021 10:58:46 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1635184719; bh=bw+FL8+IJGIBQ1x8mGrYVgLw8RdDGxuZvL+ZmU2PaBU=; l=8325; h=Subject:To:References:From:Date:In-Reply-To; b=q/LZsp9Uck1YJdUmJsEgADqLD2Wh//PKbaMJTkyDqG8Km6WKiR6kjLt3XYbmNWsGq F6DRo+oTZ8neMNnuPF7BQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1635184719; bh=bw+FL8+IJGIBQ1x8mGrYVgLw8RdDGxuZvL+ZmU2PaBU=; l=8325; h=To:References:From:Date:In-Reply-To; b=Cq+tukNAFNwZrzabILgMB1q9HiIyvYMt/jvCqhkZbNZ8IQejcH9ba/jbZMIEkbWxN Z4uAaXWx6g0IjSv9AVrGJaFYFH2lBycnxMLTEPOSbbrADjsU3XnqQezlrCAYVzS1bK LVVCj2hh+MElWw9a5EHAU4M4+1IzUkoxzT1J45c5DdYRkMqRz69qI7T1a+w3O 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 00000000005DC0CE.000000006176F04F.00007459; Mon, 25 Oct 2021 19:58:39 +0200 To: John C Klensin , dcrocker@bbiw.net, Pete Resnick , emailcore@ietf.org References: <9B80FA4E8D90E6EF3349B423@PSB> <519bad00-0619-f53f-e474-516b92f687e3@tana.it> <192dd888-a82e-cb52-58d7-2a2fa12d2268@tana.it> <81C362FBFCA1E82B614B4DE4@PSB> From: Alessandro Vesely Message-ID: Date: Mon, 25 Oct 2021 19:58:37 +0200 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: <81C362FBFCA1E82B614B4DE4@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] The domain name argument in the EHLO command, was rfc5321bis-05 preview and heads-up X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 25 Oct 2021 18:00:55 -0000 John, far from me the idea to explore new paths, let alone new requirements. Let me recall that there was a long discussion about checking the EHLO argument on the [ietf-smtp] mailing list, starting 18 September 2020. Its conclusion was that a new edition of SMTP should have relaxed the requirement level of servers reaction to bad EHLO arguments from MUST NOT to SHOULD NOT. When [emailcore] started, I summarized that thread here: https://mailarchive.ietf.org/arch/msg/emailcore/rX4A8_mILuijOt3RzeSMXAq5op0/ I refer that message in order to clarify that the issue is not extraneous to the original path of 5321bis. It's been here since the start. Subsequently, the WG decided that rather than relaxing the requirement, the bulk of the paragraph had better be moved to a newly conceived A/S. So far, so good. However, that way the paragraph sounds much more permissive than the originally proposed SHOULD NOT. Its -05 version implies that the EHLO argument can actually be invalid. The derailment point is there. Indeed, lacking further specification, a naive reader would derive that an invalid argument deserves a 5xx response to EHLO. Don't you agree? IOW, while SHOULD NOT would have left it to the infringer to devise an interoperable behavior, letting servers free to choose their behavior in the face of a bad EHLO argument can be problematic. An invalid argument can be the result of erroneous configuration or temporary hiccups, besides malicious operations. Shouldn't a well specified standard say how to handle such cases? IMHO, the spec could say something around the line of accepting EHLO or HELO whatever the argument and whatever the validation method, but then reject any transaction if the validation failed. I won't attempt to word it any better, let alone write an I-D. Please just ignore this thread if it looks useless. It looks relevant to me, but I may be wrong. Best Ale On Mon 25/Oct/2021 17:40:38 +0200 John C Klensin wrote: > Ale, > > (personal opinion, no hat). > > It seems to me that, whether your ideas are correct or > incorrect, you are headed down a new path. First, remember that > imposing new requirements in 5321bis takes us very close to the > line at which we'd need to reset to Proposed Standard, rather > than going to full standard. As I interpret the rules (again > personal opinion), such new requirements would be justified in a > document going to Internet Standard only if there were clear > proof that the absence of those requirements was causing > interoperability harm, not that they would make a different > protocol work better. > > FWIW, I think the WG's charter prohibits even getting into that > type of issue as far as 5321bis is concerned. I'd appreciate it > if the WG Chairs would speak to that. > > If one sets that concern aside and wants to charge ahead on the > subject, then this is, as others have pointed out, really a > requirement on what SMTP-senders can put into that field, not > something we should be trying to affect by vague comments about > what the server might do (much less playing around with how we > spell "MaY" or "maY" (presumably different degrees of > non-requirement :-( ). However, that would probably push the > Internet Standard requirement (and the charter) even further. > > So, two suggestions, with the understanding that, as a WG > participant (even more than as an editor), I want this work, > especially the 5321bis/5322bis parts, done and done at a higher > rate and with more active participation by more people than I'm > seeing, > > (1) Go silent on this subject until 5321bis is under control, > then push for text in the A/S. I don't know whether that > document could reasonably impose new requirements either, but it > could certainly explain why better quality EHLO arguments would > benefit both client and server and strongly encourage them. > > or, if you want to fix 5321bis... > > (2) Generate an I-D, right now (ideally making the posting > deadline but otherwise begging Murray for permission for a late > submission), in Proposed Standard form that modifies RFC 5321 to > specify whatever you think needs to be specified, updating the > SPF/ DKIM/ etc. documents as needed to clarify the relationships > between the EHLO domain or address-literal and other fields. > Make sure it describes current practice rather than speculating. > Convince Murray (or Francesca) to AD-sponsor it or to add it to > the charter of this WG. For the latter case, convince the WG to > put 5321bis on hold until your draft is discussed and processed. > If you can get it approved as PS and this WG continues at the > pace we seem to have adopted, we could easily be still fussing > with 5321bis when your six months runs out, you write an > implementation report, and then argue that the substance of the > I-D should be folded into 5321bis. > > In either case -- and this may be affecting my personal > skepticism -- I'm concerned both about the number of > environments in which those who configure SMTP services may not > have nearly as much control over those responsible for the local > DMS zone as we might like, about clusters of machines that share > functions but not addresses, and about an assortment of edge > cases that might lead to more use of address literals if we > impose more rigid requirements on EHLO domains. I think that > would be a step backwards; YMMD. > > But, right now, in this forum and on this thread, I don't see > the discussion as leading anywhere useful wrt 5321bis. Again, > just my personal opinion. > > best, > john > > --On Monday, October 25, 2021 11:59 +0200 Alessandro Vesely wrote: >> On Sun 24/Oct/2021 20:19:11 +0200 Dave Crocker wrote: >>> On 10/24/2021 11:12 AM, Pete Resnick wrote: >>> >>>> In this case, we are saying it is permissible for a server >>>> receiving the command to do (or not do) the verifications, >>>> so we are warning sender of the command that it might be >>>> verified (or not). >>> >>> Servers can and do reject sessions for all sorts of >>> reasons.  Giving them "permission" for this one case is in >>> the noise, at best.  That is, it's meaningless.  It's the >>> sort of text that looks intuitively reasonable but is not >>> actually useful. >> >> The point is to stress that the domain name argument in the >> EHLO command is an essential identifier. That stress is >> needed because, in the past, phrases like "the server MUST NOT >> refuse to accept a message on that basis" have been used to >> infer that one can write whatever it likes in the EHLO >> command. Because of this reason, for example, DMARC discards >> the domain name given here. >> >> Domain alignment becomes more and more important to sort out >> email traffic, and reliability of Received: chains depends on >> the domain name given in EHLO. It can be verified according >> to SPF or iprev methods, defined in their own RFCs. >> >> To verify that the domain name resolves to the actual IP >> address of the remote connection is an obvious method which, >> AFAIK, is not described in any standard document. RFC1123 >> mentions that such test is possible, but postpones it to >> offline checking of Received: fields: >> >> DISCUSSION: >> Including both the source host and the IP source address >> in the Received: line may provide enough information for >> tracking illicit mail sources and eliminate a need to >> explicitly verify the HELO parameter. >> >> Perhaps, RFC5321-bis could specify in the last paragraph of >> Section 2.3.5 that the resolved domain address must match the >> connecting IP. Or perhaps the A/S could fully describe this >> method and assign an Authentication-Results: keyword to it. >> For Section 4.1.4, IMHO, there is no reason why generic >> verifications of the domain name argument should be limited to >> this method only. >> >> At any rate, since a server can reject an invalid EHLO, the >> next question is going to be what its consequences are. I >> think we don't want to fail the EHLO command itself. Should >> the spec say that rejections shall reveal themselves when/if >> transactions are attempted? >> >> >> Best >> Ale >> -- > > From nobody Tue Oct 26 09:46:49 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FDB3A156C for ; Tue, 26 Oct 2021 09:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 fWoOBZ-ZEfFe for ; Tue, 26 Oct 2021 09:46:37 -0700 (PDT) Received: from mr85p00im-hyfv06011301.me.com (mr85p00im-hyfv06011301.me.com [17.58.23.184]) (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 E56E03A1565 for ; Tue, 26 Oct 2021 09:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1635266795; bh=wgGhoLxsV+9pj6R900oeMCaWzVoW/9e9qFNQwp364/s=; h=From:Content-Type:Mime-Version:Subject:Date:To:Message-Id; b=dHLiUq/HpQBd3Jq6siEhWyBrTDQTKThNS0ZBoWaIclvSULqDoe3P9tA+CtDt4lazR zE0NgQegrWZbdGItYEuHA95k1awyMPXZF/hTGiTaTJVfZczxkQcOWi/Gorimdcpos0 sguMZWlo4fp0xhjJcU0WUysKieY4DBEXUEaP77Zik4GENcXLcmvukVYTLEKg8crG9w /mwNgLyWhU1DBsPazcIR9qp5Nvm6aWfOugVJt/+lBzXklPZNaZGBCO5s7txlsGW6qz B3/qAmH8msEymLjcz3m6BxQFPKC8xOXIfNlYZjGp6A2tFjGIv6fSTcgvElHjfDzDts ZRjY94TtqwSOg== Received: from [172.16.16.24] (natbox.sabahattin-gucukoglu.com [90.155.50.12]) by mr85p00im-hyfv06011301.me.com (Postfix) with ESMTPSA id BBA825806DF for ; Tue, 26 Oct 2021 16:46:33 +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 12.4 \(3445.104.21\)) Date: Tue, 26 Oct 2021 17:46:31 +0100 References: <87605987-5256-48AA-AFE1-13452412BC79@me.com> To: emailcore@ietf.org In-Reply-To: Message-Id: <6749C1E4-B23B-419D-A711-6107CBE67C84@me.com> X-Mailer: Apple Mail (2.3445.104.21) X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.425,18.0.790,17.0.607.475.0000000_definitions?= =?UTF-8?Q?=3D2021-10-26=5F05:2021-10-25=5F02,2021-10-26=5F05,2020-04-07?= =?UTF-8?Q?=5F01_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 clxscore=1015 spamscore=0 mlxscore=0 mlxlogscore=999 malwarescore=0 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2110260092 Archived-At: Subject: Re: [Emailcore] SMTP-TCP is de facto 8bit (suggested clarity in 5321bis) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 26 Oct 2021 16:46:47 -0000 Thanks for the responses. I agree that 8BITMIME should be made mandatory, although that wasn=E2=80=99= t what I was asking for. I agree that this would make the problem of = undeclared 8bit a non-issue in most cases, however, in the absence of = any definite statement =E2=80=A6 I would still be concerned that 8BITMIME carried semantic burdens that = were harmful. Specifically, I worry that legitimate mail would be lost = or corrupted if receivers were not encouraged to be tolerant of it. = There is undoubtedly a =E2=80=9Cmoral hazard=E2=80=9D in the relaxation, = but I don=E2=80=99t believe it=E2=80=99s worse than the known = consequence of not receiving such mail. The goal, I think, should be to = minimise rather than prevent such aberration, which is already = occurring, and to do this by forbidding senders from *gratuitously* = sending avoidably 8bit content to 7bit hosts. Receivers can benefit from = 8bit, while being careful only to send 7bit, or relying on a true = protocol converter, preferably prior to authenticating outbound messages = with signatures, from a submission service. 8BITMIME is still useful if = it is simply used to negotiate onward transmission of 8bit mail with = complying senders, but it cannot help without some enforcement by = receivers (at the very least, checking that the top bit is set in a = mail, at the absolute minimum) for onward transmission of non-complying = messages, and having essentially variable behaviour in this case = wouldn=E2=80=99t be desirable, especially once 8BITMIME becomes = mandatory and 8bit transmission is possible in practice and in = principle. As to where undeclared 8bit comes from, often it is just 8bit-unaware = senders, e.g. MUAs or scripts that inject 8bit mail without declaring it = 8bit in the envelope. That is surprisingly common even in the = English-speaking world as well, for example when it is generated by = automated systems with interfaces to the mailer that aren=E2=80=99t = using SMTP. I don't intend to die on a hill on this issue. If the consensus is that = 8BITMIME should be mandatory but that the obligation to send MIME = content that is declared as such remains with the originator of the = message, and that any intermediate relays must enforce by rejection or = conversion the 8BITMIME requirement not to forward onward, it is still = preferable to the status quo. At the very least it would strengthen the = case for proper 8BITMIME enforcement , however weakly, to have mandatory = 8BITMIME support which senders can rely on in the general case. Cheers, Sabahattin From nobody Tue Oct 26 11:37:48 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F103A16B1 for ; Tue, 26 Oct 2021 11:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEgYkvyFq6Li for ; Tue, 26 Oct 2021 11:37:41 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07853A16AE for ; Tue, 26 Oct 2021 11:37:40 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id k29so90260qve.6 for ; Tue, 26 Oct 2021 11:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dGiG+mwr3uw7wCEP5UOhL87TGKbBzuirnEclAXtsjho=; b=J0VtqtwD14S7bCNqtsf36hULcUiT/SW5Z7Ti2rwYOSqIMo8jss09LEHt6UmOwQa76f ZPlHU+170j8GrMCZLFscNHWZuG5u+HQiDHzDCfu5horfSTW0fNKu6efm6xToPzuZ6tVU NZ9/4peDsYQTfTJMO8waYQ+y/NVLZ4/3/cNKThZx2bYFEkaPej17kpIkx+3UAO1Dl30T PLufz2HzPKQtK0lWZtxWaPW3tkL613AbAPtU5mUhaE40OXeprCpwPgXWt4OigDkPT9ol w6lBDOsnMr9+SyUJCjxW+hskOKlH7gwAMKcPWyxVxyRAVo3NrRu9kQUdwCizcpmHPOzm ugNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dGiG+mwr3uw7wCEP5UOhL87TGKbBzuirnEclAXtsjho=; b=XLDUAMXZIR2+rbvQq4dxwpimJas7wKWRJPVwmpM5CvvBasvjtLMyH/UKiYezPSp630 OTKK1rzYGt6oZA/UopI66ajksAOjPVLdYdjfXUy50w/tbVM6jBNct+Rnf2lXZS+wWO/c DBLZy+P6P7XpHK1aRmDQCrxteO+5vtW0vAxi9i5aaHxzvNms8+mvJLsz48YDR8bQ0ljB uiYmvrMp/qwLNPfVVUbvEIXb4gWCf/UxdidXv++ddmeLSprMp/BL+TtrmXB8lDl84O7+ g2SaDOXGA8+rufwHYwt50B04imS+KKe2W7e4V8HZO0fzpbCLqoawzt8PNWhlkpWk5keY ozOg== X-Gm-Message-State: AOAM531jJhLFCbfbQ3s4l736lnp2Nmblji6WO2qaTw+QzNz+qRIic6Ah 8LYokKMBQtPoSZ+n17nkTzHJ2XE4sErFUrgpsFkGEfmqrb9Xaw== X-Google-Smtp-Source: ABdhPJym+NZFo08PyH3ROOLLSK7MPB1DvomlabPer7zrpgOSlayL2Y+nEDoJGRSpvV0rzRg+7bWTNUfqMm+Bb20pLSw= X-Received: by 2002:a05:6214:248c:: with SMTP id gi12mr12851377qvb.14.1635273459534; Tue, 26 Oct 2021 11:37:39 -0700 (PDT) MIME-Version: 1.0 References: <73058CDA2857C379A946A785@PSB> In-Reply-To: <73058CDA2857C379A946A785@PSB> From: Todd Herr Date: Tue, 26 Oct 2021 14:37:23 -0400 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000aa9e5705cf45c5b8" Archived-At: Subject: Re: [Emailcore] rfc5321bis-04 and notes from minutes X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 26 Oct 2021 18:37:46 -0000 --000000000000aa9e5705cf45c5b8 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 22, 2021 at 7:21 PM John C Klensin wrote > > >> ### Ticket 30? Erratum 4055 -> remove reference to SPF/DKIM > >> --> Done. Did not remove quite as much as suggested; want > >> to get a consensus call/ ruling from the chairs. > > > > Todd is in charge of this ticket, I will ask him to comment. > > Done per (partially off-list) discussion. For this and the next > item, more work will be needed for the A/S, probably including > either contact information for the Protocol Police when the ISP > supporting a server refuses to supply (or demands a hefty fee > for) reverse mapping to anything but an ITU-style location > identifer or a discussion of why something like > > EHLO be-302-cr11.newark.nj.xxxx.example.net > > would be a good idea. > > See also the two CREFs in the current (rfc5321bis-05) text. > The current text in 5321bis (rev -05) is This specification does not deal with the verification of return paths. Server efforts to verify a return path and actions to be taken under various circumstances are outside the scope of this specification.for use in delivery notifications. Outside of the seemingly extraneous "for use in delivery notifications", I'm fine with that, and will be closing the ticket. > > > >> ### Ticket 19 - requirements for domain name and IP address in > >> EHLO > >> --> Deferred to mailing list. Meeting actions to Viktor and > >> maybe Allessandro. Inserted note about pointer to the > >> A/S. > > > > I think there is specific text suggested in the ticket > > already. Todd should comment as the ticket owner. > > See above. I await further instructions if the text in > rfc5321bis-05 is not sufficient. > > > The proposed text in ticket 19 is: An SMTP server MAY verify that the domain name argument in the EHLO command has an address record matching the IP address of the client. Ale has proposed an alternative of: An SMTP server MAY verify the validity of the domain name argument in the EHLO command. (Ale has also proposed adding "See [A/S] for further discussion." to whichever sentence is ultimately chosen, and I'm in favor of that.) My concern with Ale's proposed text here is that "validity" is not defined in the context of the phrase "validity of the domain name argument". The previous paragraph in 5321bis starts with "The SMTP client MUST, if possible, ensure that the domain parameter to the EHLO command is a primary host name as specified for this command in Section 2.3.5 ." and section 2.3.5 speaks of a requirement "that only fully-qualified domain names appear in SMTP transactions on the public Internet" and that's all a lot of context to go through to suss out what's meant by "validity of the domain name argument in the EHLO command". So how about this? An SMTP server MAY verify that the domain name argument in the EHLO command is a fully-qualified domain name. See [A/S] for further discussion. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000aa9e5705cf45c5b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Oct 22, 2021 at 7:21 PM John C Klensin <john-ietf@jck.com> wrote

>> ### Ticket 30? Erratum 4055 -> remove reference to SPF/DKIM
>>=C2=A0 =C2=A0 --> Done.=C2=A0 Did not remove quite as much as su= ggested; want
>>=C2=A0 =C2=A0 to get a consensus call/ ruling from the chairs.
>
> Todd is in charge of this ticket, I will ask him to comment.

Done per (partially off-list) discussion.=C2=A0 For this and the next
item, more work will be needed for the A/S, probably including
either contact information for the Protocol Police when the ISP
supporting a server refuses to supply (or demands a hefty fee
for) reverse mapping to anything but an ITU-style location
identifer or a discussion of why something like

=C2=A0 =C2=A0EHLO be-302-cr11.newark.nj.xxxx.example.ne= t

would be a good idea.

See also the two CREFs in the current (rfc5321bis-05) text.

The current text in 5321bis (rev -05)= is=C2=A0

=
   This specification does not deal with the verification of return
   paths.  Server efforts to verify a return path and actions to be
   taken under various circumstances are outside the scope of this=C2=A0
=C2=A0 =C2=A0specification.fo=
r use in delivery notifications.

Outside of the seemingly =
extraneous "for use in delivery notifications", I'm fine with=
 that, and will be closing the ticket.





>> ### Ticket 19 - requirements for domain name and IP address in

>>=C2=A0 =C2=A0 EHLO 

>>=C2=A0 =C2=A0--> Deferred to mailing list.=C2=A0 Meeting actions=
 to Viktor and

>>=C2=A0 =C2=A0 =C2=A0 maybe Allessandro.=C2=A0 Inserted note about p=
ointer to the

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0A/S.

> 

> I think there is specific text suggested in the ticket

> already. Todd should comment as the ticket owner.



See above.=C2=A0 I await further instructions if the text in

rfc5321bis-05 is not sufficient.




The proposed text in ticket 19 is:

<=
/div>
An SMTP server MAY verify that the domain name argument in t=
he EHLO command has an address record matching the IP address of the client=
.

Ale has proposed an alternative of:
<=
div>
An SMTP server MAY v= erify the validity of the domain name argument in the EHLO command.=C2=A0=

(Ale has also proposed adding "See [A/S] for further di= scussion." to whichever sentence is ultimately chosen, and I'm in = favor of that.)

My concern with Ale's proposed text here is tha= t "validity" is not defined in the context of the phrase "va= lidity of the domain name argument". The previous paragraph in 5321bis= starts with "The SMTP client MUST, i= f possible, ensure that the domain parameter=C2=A0to the EHLO command is a primary host name as specified for = this=C2=A0command in Section 2.3.5." and section 2.3.5 speaks of a requirement "that only fully-qual= ified domain=C2=A0names appear in SMTP transactions on the public Internet" and that&= #39;s all a lot of context to go through to suss out what's meant by &q= uot;validity of the domain name argument in the EHLO command".<= /div>

So how about thi= s?

An SMTP server M= AY verify that the domain name argument in the EHLO command is a fully-qual= ified domain name. See [A/S] for further discussion.


=
--
<= p dir=3D"ltr" style=3D"line-height:1.656;margin-top:0pt;margin-bottom:0pt">=

Todd Herr | Technical Director, Standards and Ecosystem
m: 703.220.4153

This email and all data transmitted with it contains conf= idential and/or proprietary information intended solely for the use of indi= vidual(s) authorized to receive it. If you are not an intended and authoriz= ed recipient you are hereby notified of any use, disclosure, copying or dis= tribution of the information included in this transmission is prohibited an= d may be unlawful. Please immediately notify the sender by replying to this= email and then delete it from your system.

<= /div>
--000000000000aa9e5705cf45c5b8-- From nobody Tue Oct 26 19:14:51 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E913A07D7 for ; Tue, 26 Oct 2021 19:14:42 -0700 (PDT) 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=D6TAN37W; dkim=pass (2048-bit key) header.d=taugh.com header.b=IfipkSt/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlbQRPfkyM7g for ; Tue, 26 Oct 2021 19:14:37 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02DCC3A05C7 for ; Tue, 26 Oct 2021 19:14:36 -0700 (PDT) Received: (qmail 47064 invoked from network); 27 Oct 2021 02:14:34 -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=b7d6.6178b60a.k2110; bh=zKnefPn68q+4N/5BPYfIF5+tu0iYnhPvcU7v6d1qw00=; b=D6TAN37WRfocW6ixJFX76HHEMrMfhzFyDwWL2z2za3bSsOjkkbtjiAMfYTiy96QhcyAMDX5AF1YBDPgj923+Ki0XEat7Ion+uw1PrJ8DEDYADRH0pOd8RnWqNUQWGnVnFyQbOSDwefs7HoJSezY4srUaw1RR3zJ9ABhD55Bz3+sUzzHwD2tkYQzh1qeSzwjp1V6Q7AEn4RqYYTsCWYbKh53abNK4WbwQKrergv01/vi+bNpgI38x7fxHBB6IFtWc3Laa0n1qLfavylzEqkcG6t7mqBi6EJ5xP5e9/ZCiuQ4GU3VrVRhsZHGp/18dhFxbV1UmK0uUEAQkO6GijEK8Ng== 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=b7d6.6178b60a.k2110; bh=zKnefPn68q+4N/5BPYfIF5+tu0iYnhPvcU7v6d1qw00=; b=IfipkSt/yVbWdhUfTjvx1nN8JK/EXlFci5gYXibedzZoEnwQ6L63IJzMjH8rBHWbg6V2A/y1acSj/2xQunsefhwOdw+oII65gw7riEoakscEWoJJYUbu38LTYBj9aU9wwizSK0dpcMjlZYQM/YpT781uGO9S8yCZUOMBm6KwWand9LtGZ9QgI35ONo5x/PUjzV22cqytuKU4JrSjO/z81h8ukzldHKiPK32cAvmLLDupV1th6uFQFsFqBQhFTwJPdPLigPRvgjWzOxCO1Gom4iKFhygdObMU19lKdOeR1/e7v72gZXt6dQSL20Y5PfGJfbfG9M74YxApSHXHKWdGbQ== 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; 27 Oct 2021 02:14:34 -0000 Received: by ary.qy (Postfix, from userid 501) id B644D2E83134; Tue, 26 Oct 2021 22:14:32 -0400 (EDT) Date: 26 Oct 2021 22:14:32 -0400 Message-Id: <20211027021433.B644D2E83134@ary.qy> From: "John Levine" To: emailcore@ietf.org In-Reply-To: <6749C1E4-B23B-419D-A711-6107CBE67C84@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] SMTP-TCP is de facto 8bit (suggested clarity in 5321bis) X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 27 Oct 2021 02:14:49 -0000 It appears that Sabahattin Gucukoglu said: >I would still be concerned that 8BITMIME carried semantic burdens that were harmful. Specifically, I worry that legitimate mail would be >lost or corrupted if receivers were not encouraged to be tolerant of it. ... IETF standards tell you what to do if you want to interoperate with other people who follow the same standards. We deliberately stay away from offering advice about what to do when other people do not follow the standards, for a variety of reasons. One is that people are infinitely creative when doing things wrong and we could never anticipate, much less deal with, all of the possible mistakes. The other is that if you say do so-and-so if someone makes mistake X, you have now made mistake X a de facto part of the standard. We all know that there are cruddy mail implementations, some clients send 8 bit characters without looking for 8BITMIME, or following the limitations of 8BITMIME, and it mostly works. We don't propose to change that, only to say that if you want to interoperate, your server better support 8BITMIME. R's, John From nobody Fri Oct 29 01:57:30 2021 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95EBE3A0E2D for ; Fri, 29 Oct 2021 01:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=VxkG/Mmd; dkim=pass (1152-bit key) header.d=tana.it header.b=B75wPzGh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiZQhVigh13T for ; Fri, 29 Oct 2021 01:57:21 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988D63A0E61 for ; Fri, 29 Oct 2021 01:57:19 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1635497834; bh=JFI1m4g5JaSm2czBiSEAmCZzEqtE8ac1nZTLIPu0yBg=; l=397; h=To:From:Subject:Date; b=VxkG/MmdLjgrwe4at4LY2IooTE5J0NdXK5MDMdEl6FDK5Zh+LAqvwlc8U+jrRMmA4 0BxxcA3KVYcNDNprB0QAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1635497834; bh=JFI1m4g5JaSm2czBiSEAmCZzEqtE8ac1nZTLIPu0yBg=; l=397; h=To:From:Date; b=B75wPzGhIZBgZ4HxgTjGwG68IfPl3w5W6P1T8/4/VeemglRuJ+R8d9F9Kw7aNkFqL isiYRoZPwsA5cVPPVQuQf0zM1hyAdTYTBqyJy7y9BJ7fqibfh/7GLGGosPzI4IOeoY WY4IHb0EwUGVfq3L6007RUxXpFPNGDZsCpE2BfEcuOBAfSr6/wkwUdZiYoOA4 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.00000000617BB76A.00002887; Fri, 29 Oct 2021 10:57:14 +0200 To: emailcore@ietf.org From: Alessandro Vesely Message-ID: Date: Fri, 29 Oct 2021 10:57:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] Helo, how are you? 5XX Bad Domain X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 29 Oct 2021 08:57:29 -0000 Even if we use lowercase letters to say that an SMTP server may verify the domain name argument, in Section 4.1.4, the difference between RFC 5321 is not something that people won't notice. Will people derive that servers can now reject at HELO? Will that debunk the myth that the HELO argument is nonsense? Will this be a topic for 12:00-14:00 Wednesday Session I? Best Ale --