From nobody Tue Dec 1 11:58:10 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A443A14A5 for ; Tue, 1 Dec 2020 11:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 VBCmQMYVYksJ for ; Tue, 1 Dec 2020 11:58:07 -0800 (PST) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 CE2803A14A1 for ; Tue, 1 Dec 2020 11:58:06 -0800 (PST) Received: by mail-vk1-xa36.google.com with SMTP id w190so732951vkg.13 for ; Tue, 01 Dec 2020 11:58:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=EUG7XcrIjMf26yKK6M2F9xtAg3bpOedeMs32iE9ci3A=; b=H5aCDWGSP12IiCPAJZ8fXiCo4YUnK9Tb6/iFbEiPB+jrflRX7ONArtveTpWs9PHCtx AM5t1VD4wlb3o9WiRcOO7hKSLy6Ctq3dOQh1LNglD5htUzCuhWauSB/sZ2cjMyxaPYaE a3sTPVybf8hN95HFEDm7f0fFeBFLvM+xDQIXKPzMtd0mB3XfBTYAnB8S9CSR3ftaOId9 2F82gg3O2uCy5h8kL07uMZrf3B2Pku35G8Zg7xWZGa9Y5Oh2QPl+Cs4qifgaifEFxcLG sVy/jKgVjQPDhCuC5A+RvA5++Lp3nq0KpiIUffCm4N13KJ71U+QEnmkYogipfXCM6FhD j0Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=EUG7XcrIjMf26yKK6M2F9xtAg3bpOedeMs32iE9ci3A=; b=uV++obmgvIyRwRtbGXOcae20aUATMdDO+pTthSa6JCE2LvqS4Ajr3rHFj08OMoLAPP 3ko/Cvr01Q0aHjlEUd0FaLNS4y67tAIhG2kIvbG1Ht53WmJdTTo14daE3MRRU7Tx4SQh T1DMxk904F5DsXoLd83k5rAYTu6X6FI/hiWf14w4hHSBQ2Bz5rcFu1qklHcUvLkJ0fZb rK56HP3F4vUC21cwwY+RaaDGcnBz+1wQX3OwTDhJfAKg+mWPWDzeaodT3z76ppuqCuFz r6fPDZtwDGhf32YwUdN+GhCKdcFYuUZ/OERT7N894WFpUeuR/skcfXU/VV3ySUpvZtGo qAzw== X-Gm-Message-State: AOAM531JraYybB+x0GRJPcMSt4CGmifv+XaRolscEAl325UU+TM+eKID ou5hCSmkMpqp1y3vnsz1tXbTWwf5WDsJP5wSAFJ8J1MhKJlY0w== X-Google-Smtp-Source: ABdhPJyIezocAj5LWOS2IJLXjr8ASm51JKRwTpwthEkKMhW12mwBIQZyZh2vjv/jbY4fRzGuNF4BrjiuccG9ESWOL8I= X-Received: by 2002:a1f:a314:: with SMTP id m20mr4330613vke.2.1606852685291; Tue, 01 Dec 2020 11:58:05 -0800 (PST) MIME-Version: 1.0 References: <660d8af5-2b83-3507-00aa-a792eb9d2118@dcrocker.net> <20201118024817.19F3A278400F@ary.qy> In-Reply-To: <20201118024817.19F3A278400F@ary.qy> From: Seth Blank Date: Tue, 1 Dec 2020 11:57:54 -0800 Message-ID: To: emailcore@ietf.org Content-Type: multipart/alternative; boundary="00000000000083b7ad05b56c8b46" Archived-At: Subject: Re: [Emailcore] Obnoxious, 11th hour, appeal of the decision to hold an emailcore meeting X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2020 19:58:09 -0000 --00000000000083b7ad05b56c8b46 Content-Type: text/plain; charset="UTF-8" This thread has continued to spiral off-list. Throughout the life of this thread, several participants have been privately admonished, with at least one warning of a potential ban issued. This thread is dead. Abandon it, regardless of venue. Continued discussion is out of scope and will result in more formal actions being taken. Please re-engage on open tickets, we have a lot of work left to complete on 5321bis and 5322bis. Seth, as co-Chair On Tue, Nov 17, 2020 at 6:48 PM John Levine wrote: > In article <660d8af5-2b83-3507-00aa-a792eb9d2118@dcrocker.net> you write: > >The Meetecho folks are great and they tend to make good usability > >choices. But they have never been a serious business. So it is not > >surprising that that industry has run right past them, especially with > >the current usage pressures, driving aggressive enhancement. > > Unfortunate but quite true. > > R's, > John > > -- > Emailcore mailing list > Emailcore@ietf.org > https://www.ietf.org/mailman/listinfo/emailcore > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --00000000000083b7ad05b56c8b46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This thread has continued to spiral off-list. Throughout t= he life of this thread, several participants have been privately admonished= , with at least one warning of a potential ban issued.

This thread i= s dead. Abandon it, regardless of venue. Continued discussion is out of sco= pe and will result in more formal actions being taken.

Please re-eng= age on open tickets, we have a lot of work left to complete on 5321bis and = 5322bis.

Seth, as co-Chair

On Tue, Nov 17, 2020= at 6:48 PM John Levine <johnl@taugh.= com> wrote:
In article <660d8af5-2b83-3507-00aa-a792eb9d2118@dcrocker= .net> you write:
>The Meetecho folks are great and they tend to make good usability
>choices.=C2=A0 But they have never been a serious business. So it is no= t
>surprising that that industry has run right past them, especially with =
>the current usage pressures, driving aggressive enhancement.

Unfortunate but quite true.

R's,
John

--
Emailcore mailing list
Emailcore@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/emailcore


--

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


= This email and all= data transmitted with it contains confidential and/or proprietary informat= ion intended solely for the use of individual(s) authorized to receive it. = If you are not an intended and authorized recipient you are hereby notified= of any use, disclosure, copying or distribution of the information include= d in this transmission is prohibited and may be unlawful. Please immediatel= y notify the sender by replying to this email and then delete it from your = system.

--00000000000083b7ad05b56c8b46-- From nobody Tue Dec 8 10:23:47 2020 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 2A79A3A108E; Tue, 8 Dec 2020 10:23:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: barryleiba@computer.org, emailcore@ietf.org, alexey.melnikov@isode.com, emailcore-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160745182462.15633.2663853584436171327@ietfa.amsl.com> Date: Tue, 08 Dec 2020 10:23:45 -0800 Archived-At: Subject: [Emailcore] emailcore - New Meeting Session Request for IETF 110 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 18:23:45 -0000 A new meeting session request has just been submitted by Alexey Melnikov, a Chair of the emailcore working group. --------------------------------------------------------- Working Group Name: Revision of core Email specifications Area Name: Applications and Real-Time Area Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: extra jmap dmarc uta Technology Overlap: calext dispatch secdispatch Key Participant Conflict: gendispatch wpack People who must be present: Pete Resnick Barry Leiba Alexey Melnikov Dr. John C. Klensin Seth Blank Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Dec 14 03:23:22 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E8E3A0A3D for ; Mon, 14 Dec 2020 03:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 Aa-HeTh7lxuK for ; Mon, 14 Dec 2020 03:23:19 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 35A343A0FE2 for ; Mon, 14 Dec 2020 03:23:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1607944998; d=isode.com; s=june2016; i=@isode.com; bh=qaE9+OC34zkHNxMEiA7BdQIQAJ66CJzIJN/a3/vgpFU=; 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=cSK37gIMA0w7H26zCIstQazmHN0FxXre83z1PPrWXcDAc/DzVDcWtyn9PcGIIG7jHRI9Lp J4OKJuzh91FrwYsdU+xB9XW2VL1fEiAMOd4XrHMNPLxEiLCepHBSqgfsLIS4kwXpasgju1 IjflCmuB5oGwUIHAPHMuvVR4JAEk5oI=; Received: from [192.168.0.5] ((unknown) [176.252.130.164]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 14 Dec 2020 11:23:18 +0000 X-SMTP-Protocol-Errors: NORDNS To: emailcore@ietf.org From: Alexey Melnikov Message-ID: Date: Mon, 14 Dec 2020 11:23:18 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [Emailcore] Ticket #41: G.7.3. Resolvable FQDN in SMTP and private domain names X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2020 11:23:21 -0000 Hi all, I split of the following from the original ticket #9: Splitting the part about "private domain names" from the discussion on=20 whether "resolvable" needs to be in the definition of domain names=20 (ticket #9) 2.3.5. Domain Names =C2=A0 Only resolvable, fully-qualified domain names (FQDNs) are permitted =C2=A0 when domain names are used in SMTP. John Klensin: =C2=A0 Does "in the public DNS" or equivalent need to be added to=20 "resolvable"??? Strawman proposal: I believe "in the public DNS" doesn't reflect how=20 SMTP servers operate, due to existence of private DNS servers/split DNS.=20 So my proposal is to close this ticket as "no change". Comments? Thank you, Alexey From nobody Mon Dec 14 03:29:00 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D693A0FF6 for ; Mon, 14 Dec 2020 03:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 w09qhqqSZmdE for ; Mon, 14 Dec 2020 03:28:56 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAD23A0FF2 for ; Mon, 14 Dec 2020 03:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1607945335; d=isode.com; s=june2016; i=@isode.com; bh=2g/9wd7YdKAFyb1229ohLroa/4kqQVzVMG6ajLyiJdo=; 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=uIlR3FPzDPUyTz2rsd+AeGXR8fxIGJ3JqYI6zyUzmEAhtoRUnNGjjcSFmEnu0G7LlAY4X4 i6iFgjS49Xzty5rkzm+fA6u5mD+Q5lRezxN8LarlgzzItYcTHFtTdIzuwSs6gGXZFZ44f6 fc0YlddzuToRqwyHvcJfmrw7vVhTziY=; Received: from [192.168.0.5] ((unknown) [176.252.130.164]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 14 Dec 2020 11:28:55 +0000 X-SMTP-Protocol-Errors: NORDNS To: emailcore@ietf.org From: Alexey Melnikov Message-ID: <75c91597-de88-d5ab-79ca-14be061569fb@isode.com> Date: Mon, 14 Dec 2020 11:28:55 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [Emailcore] Ticket #23: Erratum 1683: Additional-Registered-Clauses syntax is incorrect X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 14 Dec 2020 11:28:58 -0000 Hi, I just want to confirm consensus on the following change: ------------- Roberto Javier Godoy wrote: Section 4.4 says: =C2=A0 Additional-Registered-Clauses =3D CFWS Atom FWS String It should say: =C2=A0 Additional-Registered-Clauses =3D 1*(CFWS Atom FWS String) Notes: The rule Additional-Registered-Clauses is used by the rule Opt-info=20 (also in section 4.4, page 59) as: =C2=A0 Opt-info =3D [Via] [With] [ID] [For] [Additional-Registered-Clauses] The ABNF comment for Additional-Registered-Clauses states that=20 "Additional standard clauses may be added in this location by future=20 standards and registration with IANA." Each sequence (CFWS Atom FWS String) represents a single clause. ------------- John has already applied this correction to rfc5321bis and I believe it=20 is correct. If I don't hear any objections to the above change, this=20 ticket will be resolved as "fixed" on December 28th. Thank you, Alexey From nobody Mon Dec 14 03:30:50 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E613A0FF7 for ; Mon, 14 Dec 2020 03:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 KB7fskT2jfWf for ; Mon, 14 Dec 2020 03:30:47 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF643A0FF2 for ; Mon, 14 Dec 2020 03:30:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607945445; bh=FyAqaAqaiqWjGi2x4SPaPGGcT5ypSf405nh0VcDHQ5w=; l=814; h=To:References:From:Date:In-Reply-To; b=DkVHyl0MJWYnPkUWV17qeiIYA1pMI6bG/EAHUqO2/PuPEN2r7jN+2UMmy+vVRtHaa PZ0GZ31S3fUigeLst25UJjazWqPQH1IwbsWDRjzWv0W8jp9JKbf6eB1n7UTHYgm7/Q TpbunDJpovgRUWJCDYXuw16v3bN0zvdC9ptuvcuw7PBXrawcoLeH7SZ3W/Hvj 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.000000005FD74CE4.00001995; Mon, 14 Dec 2020 12:30:44 +0100 To: emailcore@ietf.org References: From: Alessandro Vesely Message-ID: <6f2a6f17-1148-62a7-46db-bcdf4861bb0b@tana.it> Date: Mon, 14 Dec 2020 12:30:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #41: G.7.3. Resolvable FQDN in SMTP and private domain names X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2020 11:30:48 -0000 On Mon 14/Dec/2020 12:23:18 +0100 Alexey Melnikov wrote: > Hi all, > > I split of the following from the original ticket #9: > > Splitting the part about "private domain names" from the discussion on whether > "resolvable" needs to be in the definition of domain names (ticket #9) > > 2.3.5. Domain Names > >   Only resolvable, fully-qualified domain names (FQDNs) are permitted >   when domain names are used in SMTP. > > John Klensin: >   Does "in the public DNS" or equivalent need to be added to "resolvable"??? > > Strawman proposal: I believe "in the public DNS" doesn't reflect how SMTP > servers operate, due to existence of private DNS servers/split DNS. So my > proposal is to close this ticket as "no change". Comments? +1, /resolvable/ is enough to relay. Best Ale -- From nobody Mon Dec 14 03:48:29 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6BC3A00D3 for ; Mon, 14 Dec 2020 03:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 KXXtHXfhbUWQ for ; Mon, 14 Dec 2020 03:48:27 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3493A00C9 for ; Mon, 14 Dec 2020 03:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607946504; bh=SSpgaX+a2DNnSi52wK6512hbGJMVvH2QSF1yugKaHvQ=; l=1193; h=To:References:From:Date:In-Reply-To; b=Cpbp16giD3/xNyk1xjEilr1sjaJHKqHin0Xp7k7bmDUTHwdjqPTTFqheTlT5+Gtsh V3Dx3aSdI2R0IXk0vE+7oSRDkE8LFn0XjcUqRDI+3x/ZEciilqynxEDhH1nJ9RGipS hrvmnkdDzYUPezhA1f45I3iyUiAuNcCVhKqGhEUCG2U85mI2rvirGsoh8A8cF 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 00000000005DC0C6.000000005FD75108.00001C24; Mon, 14 Dec 2020 12:48:24 +0100 To: emailcore@ietf.org References: <75c91597-de88-d5ab-79ca-14be061569fb@isode.com> From: Alessandro Vesely Message-ID: Date: Mon, 14 Dec 2020 12:48:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <75c91597-de88-d5ab-79ca-14be061569fb@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #23: Erratum 1683: Additional-Registered-Clauses syntax is incorrect X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 14 Dec 2020 11:48:28 -0000 On Mon 14/Dec/2020 12:28:55 +0100 Alexey Melnikov wrote: > > I just want to confirm consensus on the following change: > > ------------- > > Roberto Javier Godoy wrote: > > Section 4.4 says: > >   Additional-Registered-Clauses = CFWS Atom FWS String > > It should say: >   Additional-Registered-Clauses = 1*(CFWS Atom FWS String) > > Notes: > > The rule Additional-Registered-Clauses is used by the rule Opt-info (also in > section 4.4, page 59) as: >   Opt-info = [Via] [With] [ID] [For] [Additional-Registered-Clauses] > The ABNF comment for Additional-Registered-Clauses states that "Additional > standard clauses may be added in this location by future standards and > registration with IANA." > Each sequence (CFWS Atom FWS String) represents a single clause. > > ------------- > > John has already applied this correction to rfc5321bis and I believe it is > correct. If I don't hear any objections to the above change, this ticket will > be resolved as "fixed" on December 28th. Works for me, albeit the "1" looks redundant (Additional-Registered-Clauses are optional, but if you use them, you have to put at least one of them). Best Ale -- From nobody Mon Dec 14 03:50:52 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F0F3A00D3 for ; Mon, 14 Dec 2020 03:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygIDtvoDKpei for ; Mon, 14 Dec 2020 03:50:50 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id F053D3A017E for ; Mon, 14 Dec 2020 03:50:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1607946649; d=isode.com; s=june2016; i=@isode.com; bh=83se20gFWIxs/UKnfopC1Sk0nnsrwyNBvaaxxcgelp4=; 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=DoqME5hu4/NwQgRhklMqdyFplpn5lj7vLjj8vmRNYLFUTf5Vz8rxGJ+JQ1pE9ZMIN1fSo+ EQZLwSic/shabjzm8kXmgru9KvGINk3wGa7up10pENdpSEfAWencMtt+L9avyEmF4JRvxe NEjl8Jby7xMbCugpFbKjScijNeUNoJY=; Received: from [192.168.0.5] ((unknown) [176.252.130.164]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 14 Dec 2020 11:50:49 +0000 X-SMTP-Protocol-Errors: NORDNS To: emailcore@ietf.org From: Alexey Melnikov Message-ID: Date: Mon, 14 Dec 2020 11:50:48 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------59110D68F9D417C1E1EB2EE3" Content-Language: en-GB Archived-At: Subject: [Emailcore] Ticket #28: Erratum 1851: Location of text about TCP connection has closure/reset X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 14 Dec 2020 11:50:51 -0000 --------------59110D68F9D417C1E1EB2EE3 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi, Alessandro Vesely wrote in the erratum 1851: ------------ Section 4.1.1.5. says: =C2=A0 There are circumstances, contrary to the intent of this =C2=A0 specification, in which an SMTP server may receive an indication tha= t =C2=A0 the underlying TCP connection has been closed or reset. To preserve =C2=A0 the robustness of the mail system, SMTP servers SHOULD be prepared =C2=A0 for this condition and SHOULD treat it as if a QUIT had been receive= d =C2=A0 before the connection disappeared. Notes: That text seems inappropriate in the RESET (RSET) section. It should=20 presumably be moved to section 4.1.1.10. QUIT (QUIT), or, better yet, to=20 section 3.8. Terminating Sessions and Connections. ------------ Strawman proposal: Section 4.1.1.5 is indeed a wrong place for this=20 text. I think Section 3.8 is the right place for it. The last paragraph=20 of 3.8 already contains the following text: SMTP clients that experience a connection close, reset, or other communications failure due to circumstances not under their control (in violation of the intent of this specification but sometimes unavoidable) SHOULD, to maintain the robustness of the mail system, treat the mail transaction as if a 451 response had been received and act accordingly. So I think the text mentioned in the erratum should be moved after the last = paragraph of Section 3.8. Please provide feedback on this strwman proposal. In absence of feedback, th= is issue will be resolved as proposed above. Best Regards, Alexey --------------59110D68F9D417C1E1EB2EE3 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi,

Alessandro Vesely wrote in the erratum 1851:

------------

Section 4.1.1.5. says:

=C2=A0 There are circumstances, contrary to the intent of this
=C2=A0 specification, in which an SMTP server may receive an indicatio= n that
=C2=A0 the underlying TCP connection has been closed or reset. To preserve
=C2=A0 the robustness of the mail system, SMTP servers SHOULD be prepared
=C2=A0 for this condition and SHOULD treat it as if a QUIT had been received
=C2=A0 before the connection disappeared.

Notes:

That text seems inappropriate in the RESET (RSET) section. It should presumably be moved to section 4.1.1.10. QUIT (QUIT), or, better yet, to section 3.8. Terminating Sessions and Connections.

------------

Strawman proposal: Section 4.1.1.5 is indeed a wrong place for this text. I think Section 3.8 is the right place for it. The last paragraph of 3.8 already contains the following text:

   SMTP clients that experience a connect=
ion close, reset, or other
   communications failure due to circumstances not under their control
   (in violation of the intent of this specification but sometimes
   unavoidable) SHOULD, to maintain the robustness of the mail system,
   treat the mail transaction as if a 451 response had been received and
   act accordingly.

So I think the text mentioned in the erratum should be moved after the last =
paragraph of Section 3.8.

Please provide feedback on this strwman proposal. In absence of feedback, th=
is issue will be resolved as proposed above.


Best Regards,
Alexey
--------------59110D68F9D417C1E1EB2EE3-- From nobody Mon Dec 14 03:59:50 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84413A0800 for ; Mon, 14 Dec 2020 03:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 YSmPfSza8IFg for ; Mon, 14 Dec 2020 03:59:46 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id C92DF3A0822 for ; Mon, 14 Dec 2020 03:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1607947186; d=isode.com; s=june2016; i=@isode.com; bh=r0M1EVaq3vWQVyW9E80SkKVIEVhS2v4pDNQcn23TeOo=; 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=T1fRZRX8a7Y59yU2DTvaql8jNc9q50BRrwEGV3N1iktMqUMRbsYkrWhyXAh4BD2ad8uZIU ZLccAnOPhlO9KQfp9PYFfszKfvyGAR1ovStiFPM0QPPOBNwRWanntIuPzkkgFD7gIeBcw4 sLFUudyOkD04VLGLQXE83PIoAThNJV8=; Received: from [192.168.0.5] ((unknown) [176.252.130.164]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 14 Dec 2020 11:59:45 +0000 X-SMTP-Protocol-Errors: NORDNS To: emailcore@ietf.org From: Alexey Melnikov Message-ID: <3a011176-62e6-c6f5-838d-c77dada6572a@isode.com> Date: Mon, 14 Dec 2020 11:59:45 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [Emailcore] RESOLVED: Ticket #24: Erratum 4198: Description error in Section 4.2 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 14 Dec 2020 11:59:48 -0000 Dear WG, This is just to confirm resolution to the erratum 4198: ------------ OLD: =C2=A0 Whenever possible, a receiver-SMTP SHOULD test the first digit =C2=A0 (severity indication) of the reply code. NEW: =C2=A0 Whenever possible, a sender-SMTP SHOULD test the first digit =C2=A0 (severity indication) of a reply code it receives. Note: The "sender" is the entity that issues commands and receives response=20 codes (from the "receiver"). ------------ I think this is a straightforward error that was fixed in the current=20 rfc5321bis draft. Unless there are objections, this ticket will be=20 marked as closed on December 28th. Note that there is a separate ticket about 1st digit of reply codes,=20 which will be discussed separately. Best Regards, Alexey From nobody Mon Dec 14 10:29:41 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288AF3A1294 for ; Mon, 14 Dec 2020 10:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.05 X-Spam-Level: X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.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=l5P4JiTl; dkim=pass (2048-bit key) header.d=taugh.com header.b=QGx0gGqD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mZWOHi2NFcz for ; Mon, 14 Dec 2020 10:29:37 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 664623A1293 for ; Mon, 14 Dec 2020 10:29:36 -0800 (PST) Received: (qmail 33633 invoked from network); 14 Dec 2020 18:29: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=835e.5fd7af0e.k2012; bh=uNNEzSa27PaAKOtHWpu3owpB+oxali2WPzpOriga7oQ=; b=l5P4JiTleskJS1CQgFNN80MnCHMJQdREA9l55IP3AuD+1LW6IvTn7NBgsqdBYQzxA4olvjr47C0O6mZvx3wX5E+L9BGE85TwmCBg/9acPnczr+7sjnXO6iPGPFHGK1qA7mbIDILWmGEjiJwlS2V6RwSGQ16iQd68sEme5qqDWO+yiwvSQ2zA+KDnId9SJBUalNvX5GQz6ZG78CHonsVRz9uXrOzcSM2jfpe5uMsRT2GhNdDbN3fyvKB3e1Y3SCPSXCM2DLsCf8e9Bl9PJabaseXlIdgfuTYAzsO3u4yYYGsEGxpDBcAjpCPpWuk02YjXeR8NJzUtIptQlWILY0Tn1g== 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=835e.5fd7af0e.k2012; bh=uNNEzSa27PaAKOtHWpu3owpB+oxali2WPzpOriga7oQ=; b=QGx0gGqDHi6P3tcqt/OMlxIz2ZQZ9dmaWZ0vymkriiVwC0SzXovLMwRj7lrGd0aIxI5YhxrFxZkjKKUSAnQCUKp1KmJxUvjs10xMX0ecs2xRXGilBDD5vUR6W1WVtTjoFg7zgEDWBQ5GoDowNRtJSxYQuY5U+uUIK/Y+3uyt0JyKMCohPj1blf/uPca1epOTAHzCwATk/J/jSWux3AMaWR9o5cNElckEXK3qqOQRpLit0VWAItQDr44WRVdsKWS483asmmd5Cyt+JpFsMLAUaP9OPhnxmh6xhWE520juhR0PYcaOfaM37VQs00XSGz2aOLKPacBIKWSSXFtGlIDiYA== 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; 14 Dec 2020 18:29:33 -0000 Received: by ary.qy (Postfix, from userid 501) id EFE9C29DDB52; Mon, 14 Dec 2020 13:29:32 -0500 (EST) Date: 14 Dec 2020 13:29:32 -0500 Message-Id: <20201214182932.EFE9C29DDB52@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: alexey.melnikov@isode.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #41: G.7.3. Resolvable FQDN in SMTP and private domain names X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2020 18:29:39 -0000 In article you write: >John Klensin: >   Does "in the public DNS" or equivalent need to be added to >"resolvable"??? > >Strawman proposal: I believe "in the public DNS" doesn't reflect how >SMTP servers operate, due to existence of private DNS servers/split DNS. >So my proposal is to close this ticket as "no change". Comments? No change is fine with me since I think that agrees with the practice. R's, John From nobody Tue Dec 15 02:09:35 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BC73A0E6A for ; Tue, 15 Dec 2020 02:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 if4p7Diqi4wx for ; Tue, 15 Dec 2020 02:09:31 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8065B3A0E68 for ; Tue, 15 Dec 2020 02:09:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608026968; bh=xTd9NpySCJ7xzxyZYLXm+A2Lp1DS3doSDFtzf4QtCrM=; l=1459; h=To:References:From:Date:In-Reply-To; b=BEkifmPb8VKyz4jer5/nDgF7clW/MzNE4cWKD+g+J/Y433Ufm7btu4wm+Lv6Faeud ElzzSEewGENZ0n1OPbdZsMz2L6xGuFcSDKj2LSIX2DJFkRgIMXEUTk/tS7SsfXG8DV 5KIvCxt+7s/AqDE/Xuibg7dM6opZvT186st/1E+g15pc7foeEOp3wnXwJNo2z 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 00000000005DC0C0.000000005FD88B58.00004FCB; Tue, 15 Dec 2020 11:09:28 +0100 To: emailcore@ietf.org References: From: Alessandro Vesely Message-ID: Date: Tue, 15 Dec 2020 11:09:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #28: Erratum 1851: Location of text about TCP connection has closure/reset X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2020 10:09:33 -0000 On Mon 14/Dec/2020 12:50:48 +0100 Alexey Melnikov wrote: > > Section 4.1.1.5. says: > >   There are circumstances, contrary to the intent of this >   specification, in which an SMTP server may receive an indication that >   the underlying TCP connection has been closed or reset. To preserve >   the robustness of the mail system, SMTP servers SHOULD be prepared >   for this condition and SHOULD treat it as if a QUIT had been received >   before the connection disappeared. > > Notes: > > That text seems inappropriate in the RESET (RSET) section. It should presumably > be moved to section 4.1.1.10. QUIT (QUIT), or, better yet, to section 3.8. > Terminating Sessions and Connections. > > ------------ > > Strawman proposal: Section 4.1.1.5 is indeed a wrong place for this text. I > think Section 3.8 is the right place for it. The last paragraph of 3.8 already > contains the following text: > > SMTP clients that experience a connection close, reset, or other > communications failure due to circumstances not under their control > (in violation of the intent of this specification but sometimes > unavoidable) SHOULD, to maintain the robustness of the mail system, > treat the mail transaction as if a 451 response had been received and > act accordingly. > > So I think the text mentioned in the erratum should be moved after the last paragraph of Section 3.8. +1, that's the proper place. Best Ale -- From nobody Tue Dec 15 02:24:37 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D883A0EB5 for ; Tue, 15 Dec 2020 02:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 e0-pk2-UsmTL for ; Tue, 15 Dec 2020 02:24:34 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8CE03A046B for ; Tue, 15 Dec 2020 02:24:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608027871; bh=OkVmNeKSArzHtcG3uvNX6M1CvGHUUlHM9Eb7V2naTis=; l=694; h=To:References:From:Date:In-Reply-To; b=AG76iwzTEgdz4HOKqcDd3DMHHp5dVqKBFvb+WKbAiImSpGtb4XHmK51OBDK8VDulF Uz4ZbwIrLCRi3h8O3Vt2US9fRasiD0JVTlsA0fACHMI94SAVbDKpcdMS1LHKjy+O4i D4dt1brNvx9CeQh0K2hUpjjNT20r2wqDi+3MrVuI/wL/dIqxIgnLvFVGj85ux 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 00000000005DC0D3.000000005FD88EDF.0000517A; Tue, 15 Dec 2020 11:24:31 +0100 To: emailcore@ietf.org References: <3a011176-62e6-c6f5-838d-c77dada6572a@isode.com> From: Alessandro Vesely Message-ID: Date: Tue, 15 Dec 2020 11:24:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <3a011176-62e6-c6f5-838d-c77dada6572a@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] RESOLVED: Ticket #24: Erratum 4198: Description error in Section 4.2 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2020 10:24:36 -0000 On Mon 14/Dec/2020 12:59:45 +0100 Alexey Melnikov wrote: > > OLD: >   Whenever possible, a receiver-SMTP SHOULD test the first digit >   (severity indication) of the reply code. > > NEW: >   Whenever possible, a sender-SMTP SHOULD test the first digit >   (severity indication) of a reply code it receives. > > Note: > > The "sender" is the entity that issues commands and receives response codes > (from the "receiver"). > > ------------ > > I think this is a straightforward error that was fixed in the current > rfc5321bis draft. Unless there are objections, this ticket will be marked as > closed on December 28th. +1 for closing the ticket. Best Ale -- From nobody Wed Dec 16 17:38:42 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375523A0A21 for ; Wed, 16 Dec 2020 17:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFZbzIpw2VRk for ; Wed, 16 Dec 2020 17:38:38 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2DC3A136C for ; Wed, 16 Dec 2020 17:38:38 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kpiFY-000IAh-OF; Wed, 16 Dec 2020 20:38:36 -0500 Date: Wed, 16 Dec 2020 20:38:30 -0500 From: John C Klensin To: Alexey Melnikov , emailcore@ietf.org Message-ID: <6A1255A557C666DF96E19DB9@PSB> In-Reply-To: <3a011176-62e6-c6f5-838d-c77dada6572a@isode.com> References: <3a011176-62e6-c6f5-838d-c77dada6572a@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] RESOLVED: Ticket #24: Erratum 4198: Description error in Section 4.2 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 01:38:40 -0000 Alexey and WG, Thanks for closing this. The corrected text is, as you noted, already present in draft-ietf-emailcore-rfc5321bis-00 as you noted. I have marked it "resolved" in Appendix H.1. However, that text also carries a note from 2014 that reads: "[[Note in Draft: What is that sentence supposed to be tell us? Test the first digit and examine the others only if necessary? Note the interaction between this and various flaps about adding new codes.]]" Is that what you refer to as "about 1st digit of reply codes"? Would it help with that one if we simply added, after "receives.", something like: "It should use information in the other digits of the code and any supplemental codes or information (see RFC 3463) only if it recognizes them and to provide additional information as needed but should rely on that first digit if the additional information is not recognized." I think better phrasing is possible, but I assume that is what we are trying to get at. If there is agreement on that (plus or minus wordsmithing), it should be possible to close the other ticket as well. =20 john --On Monday, December 14, 2020 11:59 +0000 Alexey Melnikov wrote: > Dear WG, >=20 > This is just to confirm resolution to the erratum 4198: >=20 > ------------ >=20 > OLD: > =C2=A0 Whenever possible, a receiver-SMTP SHOULD test the = first > digit > =C2=A0 (severity indication) of the reply code. >=20 > NEW: > =C2=A0 Whenever possible, a sender-SMTP SHOULD test the first > digit > =C2=A0 (severity indication) of a reply code it receives. >=20 > Note: >=20 > The "sender" is the entity that issues commands and receives > response codes (from the "receiver"). >=20 > ------------ >=20 > I think this is a straightforward error that was fixed in the > current rfc5321bis draft. Unless there are objections, this > ticket will be marked as closed on December 28th. >=20 > Note that there is a separate ticket about 1st digit of reply > codes, which will be discussed separately. >=20 > Best Regards, >=20 > Alexey From nobody Wed Dec 16 19:41:56 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB523A13F1 for ; Wed, 16 Dec 2020 19:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=g55Coaar; dkim=pass (2048-bit key) header.d=taugh.com header.b=aG699jQy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rESr_GAiz1JW for ; Wed, 16 Dec 2020 19:41:53 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252B73A13F0 for ; Wed, 16 Dec 2020 19:41:52 -0800 (PST) Received: (qmail 62580 invoked from network); 17 Dec 2020 03:41:51 -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=f46f.5fdad37f.k2012; bh=bivvfajgdnK0WNx0Qwx7pZL/1IRRzu52nlkfofybGwA=; b=g55CoaarOECXLB1JsCQBwZlbtQQy/zbWsMTfVLL0c4HINesQsj7I1bxOvTu5cHbjBRmYM+NkG7lAf+VMScd/MtpFmOZjIGSnAlyzZZO1gUzjRBvOll/K7K5o8aIzkN/fknreesFutE4CPjQNKoUGmW0cRbvaKafa1Ebfm68fHN4POnN4Cl9VNTOP86H1dwL5/ahsY1Am+/yFfi4Kc8FITEo6/WrcDQVVXE9PIFZXQ1LXo7a9OeULQ5Nh6ByA+pDAzKIjAiinz1C/i17fcZL+/xv2/CuQUQDwRwTpycCJIx5RMB3jGoIyU87XA/Ows1kyBqmDzbZoS7/jKdxZ99d0bw== 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=f46f.5fdad37f.k2012; bh=bivvfajgdnK0WNx0Qwx7pZL/1IRRzu52nlkfofybGwA=; b=aG699jQy0p2WlCA5YPMAc7ZCI6Q/Gns6pewCFQY4TpUGYQb8jNesolgPWCeIj6Wq0g+h9YK3UP+TYdZRMBIDe9OyGoIG1uFHfBZ1jTtXlxT0KwSfdj9A1KCpGqrAuKt8CTsU8w6j1euo0XrDkP1WmD/52lzwYbGiS+mp1j0YEe+QgaPKh+OF2qRHDsXnd6tAkDn9LpbfkjWceOE2E73lFLRMDmSKF+5LFxmSXGRNfZqDcD5tgYCjK4I4gmOGVDFivr/KWZdHVIvsT/SmjSaoPgkdXErhxReFtQlEJoI+JMkhSXfG8L/n/s22uIxoKai1+3M7MWMnp/wAJwjgHdErKg== 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 Dec 2020 03:41:51 -0000 Received: by ary.qy (Postfix, from userid 501) id AA9142AC1E50; Wed, 16 Dec 2020 22:41:50 -0500 (EST) Date: 16 Dec 2020 22:41:50 -0500 Message-Id: <20201217034150.AA9142AC1E50@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: john-ietf@jck.com In-Reply-To: <6A1255A557C666DF96E19DB9@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] RESOLVED: Ticket #24: Erratum 4198: Description error in Section 4.2 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 03:41:55 -0000 In article <6A1255A557C666DF96E19DB9@PSB> you write: > "It should use information in the other digits of the > code and any supplemental codes or information (see RFC > 3463) only if it recognizes them and to provide > additional information as needed but should rely on that > first digit if the additional information is not > recognized." That seems utterly obvious, which I suppose means we should be sure to include it. R's, John From nobody Wed Dec 16 19:52:37 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC833A13F7 for ; Wed, 16 Dec 2020 19:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwJk1b3scvFc for ; Wed, 16 Dec 2020 19:52:35 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CFCD3A13F6 for ; Wed, 16 Dec 2020 19:52:35 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kpkLC-000J37-6P; Wed, 16 Dec 2020 22:52:34 -0500 Date: Wed, 16 Dec 2020 22:52:29 -0500 From: John C Klensin To: emailcore@ietf.org cc: Alexey Melnikov Message-ID: <43614EAB7197EC7902FE4C30@PSB> In-Reply-To: <47EF54E0B8D9A53E24071951@PSB> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> <7B76DDDD7606B27CA830E9E9@PSB> <47EF54E0B8D9A53E24071951@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of EHLO X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 03:52:37 -0000 Hi. In late October, before the discussion of repeated use of EHLO forked into several discussions that there seems to be agreement were not properly part of rfc5321bis, I suggested that we fix the text to simply clarify the relationships between EHLO and RSET and mail transactions and those between a new EHLO command and its predecessor. I tentatively made the changes but never circulated them to the WG list. The working version of what will become draft-ietf-emailcore-rfc5321bis-01 now contains: (1) A new second paragraph in Section 3.3 that reads: Mail transactions are also terminated by the RSET command (Section 4.1.1.5), the sending of an EHLO command (Section 3.2), or the sending of a QUIT command (Section 3.8) which terminates both any active mail transaction and the SMTP connection. And, in addition, (2) the third paragraph of Section 4.1.4 has been extended to read: "An EHLO command MAY be issued by a client later in the session. If it is issued after the session begins and the EHLO command is acceptable to the SMTP server, the SMTP server MUST clear all buffers and reset the state exactly as if a RSET command had been issued (specifically, it terminates any mail transaction that was in progress, see Section 3.3). In other words, the sequence of RSET followed immediately by EHLO is redundant, but not harmful other than in the performance cost of executing unnecessary commands. However the response to an additional EHLO command MAY be different from that from prior ones; the client MUST rely only on the responses from the most recent EHLO command." With those changes, the situation should be very clear and consistent with the intention of the text coming out of DRUMS and YAM. I have also annotated Appendix G.2 to discuss these changes. In reviewing them and the related text tonight, I discovered two additional issues. For convenience, I will describe them in a separate note. It also occurs to me that it would be helpful if Alexey's ticket numbers were including in the relevant appendices of 5321bis. I will put them in when an issue is resolved but, if someone has time to compile a small table and send it to me, I'll fix the outstanding ones. john From nobody Wed Dec 16 20:46:38 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D55F3A1439 for ; Wed, 16 Dec 2020 20:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjjuXUJ55r1R for ; Wed, 16 Dec 2020 20:46:36 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F743A1436 for ; Wed, 16 Dec 2020 20:46:36 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kplBS-000JQs-Sf; Wed, 16 Dec 2020 23:46:34 -0500 Date: Wed, 16 Dec 2020 23:46:29 -0500 From: John C Klensin To: John Levine , emailcore@ietf.org Message-ID: <76CF0B1097EB28A5BDE902EE@PSB> In-Reply-To: <20201217034150.AA9142AC1E50@ary.qy> References: <20201217034150.AA9142AC1E50@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] RESOLVED: Ticket #24: Erratum 4198: Description error in Section 4.2 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 04:46:37 -0000 --On Wednesday, December 16, 2020 22:41 -0500 John Levine wrote: > In article <6A1255A557C666DF96E19DB9@PSB> you write: >> "It should use information in the other digits of the >> code and any supplemental codes or information (see RFC >> 3463) only if it recognizes them and to provide >> additional information as needed but should rely on that >> first digit if the additional information is not >> recognized." > > That seems utterly obvious, which I suppose means we should be > sure to include it. The discussion did come up on the mailing list and it is possible --although I admit it is a stretch-- to read "Whenever possible, a sender-SMTP SHOULD test the first digit (severity indication) of a reply code it receives" as meaning "sometimes it should not test even that" or leaving questions about what to do with the test open. I have not yet made the change to the working draft; waiting to hear from the WG. john From nobody Wed Dec 16 21:03:02 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BE73A1450 for ; Wed, 16 Dec 2020 21:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewgRr4sRuUi0 for ; Wed, 16 Dec 2020 21:03:00 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CEC33A144D for ; Wed, 16 Dec 2020 21:03:00 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kplRL-000JYh-AD for emailcore@ietf.org; Thu, 17 Dec 2020 00:02:59 -0500 Date: Thu, 17 Dec 2020 00:02:54 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: <9ABCA62E3E54C4356D09E1EE@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] Two extra issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 05:03:02 -0000 Hi. As mentioned in my note about ticket #2 sent about an hour ago, two additional issues came to my attention (or I was reminded about them) while looking at that issue and looking through the document. I've put them into the working version of what will become draft-ietf-emailcore-rfc5321bis-01 as: ---- G.12. Extension Keywords Starting in 'X-' Section 2.2.2 contains a discussion of SMTP keywords starting in "X". Given general experience with such things and RFC 6648, is there any reason to not deprecate that practice entirely and remove that text? If we do so, should Section 4.1.5 be dropped or rewritten to make clear this is an obsolete practice? G.13. Deprecating HELO RFC 5321 (and 2821 before it) very carefully circle around the status of HELO, even recommending its use as a fallback when EHLO is sent and a "command not recognized" response is received. We are just a few months short of 20 years; is it time to deprecate the thing and clean out some or all of that text? And, given a recent (4Q2020) discussion on the EMAILCORE list, should EHLO be explicitly bound to SMTP over TCP with the older transports allowed only with HELO? While those questions may seem independent, separating them is fairly hard given the way the text is now constructed. Two more things... (1) I think I've figured out how to overlay the ticket numbers from https://trac.ietf.org/trac/emailcore/report/1 onto the relevant lists in 5321bis where they are applicable, so the request for someone to build a table for me is withdrawn -- they will be in the next version. (2) I await guidance from the WG Chairs as to when to post a new version. My personal preference would be to wait until we have at least a few more tickets resolved, but up to them (and the WG). john From nobody Thu Dec 17 05:54:47 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238163A0AFD for ; Thu, 17 Dec 2020 05:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arY1zGKL6LzG for ; Thu, 17 Dec 2020 05:54:39 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56ED63A0849 for ; Thu, 17 Dec 2020 05:54:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608213270; bh=csjEJmI3E6ISvYYmC+rgTbz4ZUpExqmR0hmI0s0wqD8=; l=1482; h=To:References:From:Date:In-Reply-To; b=C6JEkdP/zjosLIb6HMPbmD6lzONjdQHwdXetw7IDrNmc1CuMNEn6Ua2zDqpa6o9de LGOMF1Xs6McjSFe4GUTOjlGQDMWtc0qOB3+JuDRfjvQP/m3yDPul/aiCPQClKHWYB8 Vc+hOyOMVWmGVeuXdaiNbgjN9VW6bfSL28vNE0LfRLzNObpZI2TeDZFWwXoUR Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.000000005FDB6316.00000D41; Thu, 17 Dec 2020 14:54:30 +0100 To: John C Klensin , John Levine , emailcore@ietf.org References: <20201217034150.AA9142AC1E50@ary.qy> <76CF0B1097EB28A5BDE902EE@PSB> From: Alessandro Vesely Message-ID: <47407afa-6e6a-d0d2-a829-67d68fd0ee90@tana.it> Date: Thu, 17 Dec 2020 14:54:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <76CF0B1097EB28A5BDE902EE@PSB> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] RESOLVED: Ticket #24: Erratum 4198: Description error in Section 4.2 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 13:54:46 -0000 On Thu 17/Dec/2020 05:46:29 +0100 John C Klensin wrote: > --On Wednesday, December 16, 2020 22:41 -0500 John Levine wrote: >> In article <6A1255A557C666DF96E19DB9@PSB> you write: >>> "It should use information in the other digits of the >>> code and any supplemental codes or information (see RFC >>> 3463) only if it recognizes them and to provide >>> additional information as needed but should rely on that >>> first digit if the additional information is not >>> recognized." >> >> That seems utterly obvious, which I suppose means we should be >> sure to include it. > > The discussion did come up on the mailing list and it is > possible --although I admit it is a stretch-- to read "Whenever > possible, a sender-SMTP SHOULD test the first digit (severity > indication) of a reply code it receives" as meaning "sometimes > it should not test even that" or leaving questions about what to > do with the test open. Yeah, especially when comparing that SHOULD with the fact that the first digit MUST be checked if the response code is not recognized. As if it were more difficult to check the first digit than the whole response code. Perhaps, reading is easier if "Whenever possible" is replaced by something like "If the sender-SMTP does not know how to deal with a specific response code". Actually, only some response codes are better understood in their entirety, e.g. 421. The rest are for logging and offline pondering. Best Ale -- From nobody Thu Dec 17 10:45:21 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566183A0E77 for ; Thu, 17 Dec 2020 10:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHvYtOjc0KgS for ; Thu, 17 Dec 2020 10:45:17 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 75D013A0408 for ; Thu, 17 Dec 2020 10:45:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1608230716; d=isode.com; s=june2016; i=@isode.com; bh=fU1hCdNVBTlQRLHH6nz6MQoxZij02XZbmQMxjZmBrEY=; 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=bNDzam9bCM1KWSTN3oo9kIXf2vbLcElgqT+OtTrq9EZhICs1CQMDOZPEVH7/m9LEy7mjR/ CU4WpTKizn0riUDYJxrRTycg/OtByE5Hn8+kVLGwFgYVe4DzQsafQtskExaC+ceDKd5BKI zIyLiOSYXqFKoElF+mUgluEpg5QSLJ0=; Received: from [172.27.251.185] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 17 Dec 2020 18:45:16 +0000 To: John C Klensin , emailcore@ietf.org References: <3a011176-62e6-c6f5-838d-c77dada6572a@isode.com> <6A1255A557C666DF96E19DB9@PSB> From: Alexey Melnikov Message-ID: <6b84ad49-62a3-459c-e593-e4d52184a031@isode.com> Date: Thu, 17 Dec 2020 18:43:19 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 In-Reply-To: <6A1255A557C666DF96E19DB9@PSB> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------B15C6C3D4153FE3DF5DCC71E" Content-Language: en-GB Archived-At: Subject: Re: [Emailcore] RESOLVED: Ticket #24: Erratum 4198: Description error in Section 4.2 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 18:45:19 -0000 --------------B15C6C3D4153FE3DF5DCC71E Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable On 17/12/2020 01:38, John C Klensin wrote: > Alexey and WG, > > Thanks for closing this. The corrected text is, as you noted, > already present in draft-ietf-emailcore-rfc5321bis-00 as you > noted. I have marked it "resolved" in Appendix H.1. However, > that text also carries a note from 2014 that reads: > > "[[Note in Draft: What is that sentence supposed to be > tell us? Test the first digit and examine the others > only if necessary? Note the interaction between this and > various flaps about adding new codes.]]" > > Is that what you refer to as "about 1st digit of reply codes"? Yes, this is the ticket #13:=20 : "G.7.7. Does the=20 'first digit only' and/or non-listed reply code text need clarification?" > Would it help with that one if we simply added, after > "receives.", something like: > > "It should use information in the other digits of the > code and any supplemental codes or information (see RFC > 3463) Maybe also reference RFC 5248 which establishes the IANA registry? > only if it recognizes them and to provide > additional information as needed but should rely on that > first digit if the additional information is not > recognized." > > I think better phrasing is possible, but I assume that is what > we are trying to get at. If there is agreement on that (plus or > minus wordsmithing), it should be possible to close the other > ticket as well. Yes, something along the lines of what you suggested above. Best Regards, Alexey > > john > > > > > > --On Monday, December 14, 2020 11:59 +0000 Alexey Melnikov > wrote: > >> Dear WG, >> >> This is just to confirm resolution to the erratum 4198: >> >> ------------ >> >> OLD: >> =C2=A0 Whenever possible, a receiver-SMTP SHOULD test the first >> digit >> =C2=A0 (severity indication) of the reply code. >> >> NEW: >> =C2=A0 Whenever possible, a sender-SMTP SHOULD test the first >> digit >> =C2=A0 (severity indication) of a reply code it receives. >> >> Note: >> >> The "sender" is the entity that issues commands and receives >> response codes (from the "receiver"). >> >> ------------ >> >> I think this is a straightforward error that was fixed in the >> current rfc5321bis draft. Unless there are objections, this >> ticket will be marked as closed on December 28th. >> >> Note that there is a separate ticket about 1st digit of reply >> codes, which will be discussed separately. >> >> Best Regards, >> >> Alexey > --------------B15C6C3D4153FE3DF5DCC71E Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable


On 17/12/2020 01:38, John C Klensin wrote:
Alexey and WG,

Thanks for closing this.  The corrected text is, as you noted,
already present in draft-ietf-emailcore-rfc5321bis-00 as you
noted.  I have marked it "resolved" in Appendix H.1.  However,
that text also carries a note from 2014 that reads:

	"[[Note in Draft:  What is that sentence supposed to be
	tell us? Test the first digit and examine the others
	only if necessary? Note the interaction between this and
	various flaps about adding new codes.]]"

Is that what you refer to as "about 1st digit of reply codes"?

Yes, this is the ticket #13: <https://trac.ietf.org/trac/emailcore/ticket/13><= /a>: "G.7.7. Does the 'first digit only' and/or non-listed reply code text need clarification?"

Would it help with that one if we simply added, after
"receives.", something like:

	"It should use information in the other digits of the
	code and any supplemental codes or information (see RFC
	3463)
Maybe also reference RFC 5248 which establishes the IANA registry?
 only if it recognizes them and=
 to provide
	additional information as needed but should rely on that
	first digit if the additional information is not
	recognized."

I think better phrasing is possible, but I assume that is what
we are trying to get at.  If there is agreement on that (plus or
minus wordsmithing), it should be possible to close the other
ticket as well.

Yes, something along the lines of what you suggested above.

Best Regards,

Alexey


   john





--On Monday, December 14, 2020 11:59 +0000 Alexey Melnikov
<alexey.melnikov@isode.com> wrote:


Dear WG,

This is just to confirm resolution to the erratum 4198:

------------

OLD:
 =C2=A0 Whenever possible, a receiver-SMTP SHOULD test the first
digit
 =C2=A0 (severity indication) of the reply code.

NEW:
 =C2=A0 Whenever possible, a sender-SMTP SHOULD test the first
digit
 =C2=A0 (severity indication) of a reply code it receives.

Note:

The "sender" is the entity that issues commands and receives
response codes (from the "receiver").

------------

I think this is a straightforward error that was fixed in the
current rfc5321bis draft. Unless there are objections, this
ticket will be marked as closed on December 28th.

Note that there is a separate ticket about 1st digit of reply
codes, which will be discussed separately.

Best Regards,

Alexey
--------------B15C6C3D4153FE3DF5DCC71E-- From nobody Thu Dec 17 12:54:19 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE483A100C for ; Thu, 17 Dec 2020 12:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=UjoHwVOH; dkim=pass (2048-bit key) header.d=taugh.com header.b=PdvuSlfz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ldriy55sFY-b for ; Thu, 17 Dec 2020 12:54:16 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62B103A100A for ; Thu, 17 Dec 2020 12:54:15 -0800 (PST) Received: (qmail 125 invoked from network); 17 Dec 2020 20:54:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7b.5fdbc576.k2012; bh=LjHwLrKPBS038eRppbH6hQeOiXeIN/AxfHJ8xE92/7Q=; b=UjoHwVOHCFJT13EEI30Lvo4flnMHwEDwYO7bN3huhrLHjHtVw+KZGhp3TufDCw8tHye4oBwQb/BKeHqvbmHaXTe7bYaOK6BqsIdK0KzOdHK7zBuRGd+4W3GeLaogoWZsg6rJX/C9rXZryxvMsyQ0Dju2w6lFreJV/6NEt77L2tyA42RlL88z/C6CjOxySCqUDw5b/UqmKs+GGbXHkFvo3eE0E+stcUo3ouRrgJ3pmYiNz/SSzl2AoB1wWXTqvWcSB5ORbrMVk5Ud/9p39kyl2JBobMXLrggrqOHJwNcFWur7fvTRH9dGnEOSt0lu0C5pKDRqW+9eNwkmPKiWB9TZoQ== 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=7b.5fdbc576.k2012; bh=LjHwLrKPBS038eRppbH6hQeOiXeIN/AxfHJ8xE92/7Q=; b=PdvuSlfzWzbGFdc9Xlx0rLU24/k73BWVqceWtIJMNYibi3TIWrt9Qe56IWVAN/ioRzgHoAHk3sl2UdIFVO8BBCqhJqbIlz8bZUeB9/+zoKX93eN0Gsvaj5flCLBIm6oqsFZheU1Vfab2fqBFPQNO7Chv9rzHbKMdwMTHZW62JragiLDfSi6+t/tGsKeLfSO2BYGXHMhs3ZZo4cPZ12O/omSE1DAOSnaxX2866+rgDte7rkktTFaD9TRvg8qZo11CVOjFnREXItyop/tuB2l7YmNxwN3HiAt/LklVDq2n7wlznd7fgirGzIHtpGF75zV9tDHzkzytWDQyiU4GlkRuAA== 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 Dec 2020 20:54:14 -0000 Received: by ary.qy (Postfix, from userid 501) id D68C32AC973F; Thu, 17 Dec 2020 15:54:13 -0500 (EST) Date: 17 Dec 2020 15:54:13 -0500 Message-Id: <20201217205413.D68C32AC973F@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: john-ietf@jck.com In-Reply-To: <9ABCA62E3E54C4356D09E1EE@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] Two extra issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 20:54:18 -0000 In article <9ABCA62E3E54C4356D09E1EE@PSB> you write: >Hi. > >As mentioned in my note about ticket #2 sent about an hour ago, >two additional issues came to my attention (or I was reminded >about them) while looking at that issue and looking through the >document. > >I've put them into the working version of what will become >draft-ietf-emailcore-rfc5321bis-01 as: > > ---- > > G.12. Extension Keywords Starting in 'X-' Kill them. > G.13. Deprecating HELO > discussion on the EMAILCORE list, should EHLO be explicitly bound to > SMTP over TCP with the older transports allowed only with HELO? I am pretty sure that all of the other transports described in RFC 821 are dead, or close enough (X.25, where it says to run TCP over it.) Is anyone here aware of running SMTP over anything else, and if so using HELO rather than EHLO? I'm not. R's, John From nobody Thu Dec 17 15:13:56 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C063A0836 for ; Thu, 17 Dec 2020 15:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 Q-1lYNuks_Kv for ; Thu, 17 Dec 2020 15:13:53 -0800 (PST) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771113A083E for ; Thu, 17 Dec 2020 15:13:53 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTABPRJJHS00CS7O@mauve.mrochek.com> for emailcore@ietf.org; Thu, 17 Dec 2020 15:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1608246518; bh=lI1tFkvBOtv2ocM9qPuNNcZfQnEoNyP1V3qbj6HibMQ=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=LI9kck8xxKyOBVXWruDl9y8wxXdfCgKUMGzTGrckCo1wSL9X7Lj9uMdMWBle+D93H oyzFhgHz06SIeXkEuQRNDyWnaTABakIQE6nl9tqwrfzsF8+af8Pdww4qfocQEkqybH qB6gszy5BzGF1gNRcaPlxdyhCDiQsMbGakylIdlQ= 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 <01RSXJS63P28004QVR@mauve.mrochek.com>; Thu, 17 Dec 2020 15:08:15 -0800 (PST) Cc: emailcore@ietf.org, john-ietf@jck.com Message-id: <01RTABPBJB7C004QVR@mauve.mrochek.com> Date: Thu, 17 Dec 2020 15:00:46 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 17 Dec 2020 15:54:13 -0500" <20201217205413.D68C32AC973F@ary.qy> References: <9ABCA62E3E54C4356D09E1EE@PSB> <20201217205413.D68C32AC973F@ary.qy> To: John Levine Archived-At: Subject: Re: [Emailcore] Two extra issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 23:13:55 -0000 > In article <9ABCA62E3E54C4356D09E1EE@PSB> you write: > >Hi. > > > >As mentioned in my note about ticket #2 sent about an hour ago, > >two additional issues came to my attention (or I was reminded > >about them) while looking at that issue and looking through the > >document. > > > >I've put them into the working version of what will become > >draft-ietf-emailcore-rfc5321bis-01 as: > > > > ---- > > > > G.12. Extension Keywords Starting in 'X-' > Kill them. > > G.13. Deprecating HELO > > discussion on the EMAILCORE list, should EHLO be explicitly bound to > > SMTP over TCP with the older transports allowed only with HELO? > I am pretty sure that all of the other transports described in RFC 821 > are dead, or close enough (X.25, where it says to run TCP over it.) I haven't seen an alternate transport in use in a long time. > Is anyone here aware of running SMTP over anything else, and if so > using HELO rather than EHLO? I'm not. There's still quite a few HELO's being sent by IOT stuff that supports email. And I can understand why - when every byte counts, code to fall back from EHLO to HELO isn't going to be written. And as luck would have it only yesterday I had a request for the option in our server to disable client use of EHLO. I guess something couldn't tolerate it. (Yes, I had to look it up.) Ned From nobody Thu Dec 17 17:24:39 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32943A0D74 for ; Thu, 17 Dec 2020 17:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Om6xkRvb; dkim=pass (2048-bit key) header.d=taugh.com header.b=S8Q21Lpa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyhJ6prqmnkv for ; Thu, 17 Dec 2020 17:24:30 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273403A0B37 for ; Thu, 17 Dec 2020 17:24:28 -0800 (PST) Received: (qmail 53300 invoked from network); 18 Dec 2020 01:24:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=d032.5fdc04cb.k2012; i=johnl-iecc.com@submit.iecc.com; bh=euCLwIHoVPEElWe4AU5GtsDtON8y/P00EZp4GP0NwrE=; b=Om6xkRvbwcTaKHLJRHGdA5/aGqZSVnTH5yO17V9QkEZplYgRvTnXWBEkectyKOvQpPlLERQ7IPQzLLNkZ7nhZDbItX/rhx/gyNfOWG/nO4+R0V39tEPB96BTZKrclfar4v3VOxDBjU3BC+jM+sHq5CAEKhvzylIR5S4hO2MAMKTBcJNwiZJJfBlx1kIIC7U5jzmxat+5kZNbAo+NfFoUWyJA53YAMlgsi31KV7iEJ4vynILyCMEKt7GX8ERccjzcE45LfeflOk5GLAkangBMXD6Vd5TxMsFq1S7GpONtMTr0HzrIP9VZ/VrX2D1rmioWVZsTKeFmzfa3T266AKnmQQ== 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=d032.5fdc04cb.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=euCLwIHoVPEElWe4AU5GtsDtON8y/P00EZp4GP0NwrE=; b=S8Q21LpaXtsJfNTCQU8pKSxMGomX5t5fAB/5WgUOFXNxLw/r57ozg8Tr9im2rAP/lwurH+lXAy0JLvQZuTe+e1nnEfSOG/8Eq8H0P/MvxOaMWgsAWd4yXXDlNi8YwKpu2D0d4wS++ZTpL3SEuF4ksj8yF04j2MutxGzOIk0zDJIsgeQ4ec1idkbQgP2D2qSynzepUTsMU2kVwz7iVDdujKXB054es0JqEXHxmzHgCDibs9Seuv4IocGHkEEEz9yl1LETSN7F58ZkqsQ0hV5FGysZAcBCf0w805AdRDpLR76Ja22jJqhS8kCDc86G+ICXOlUVrO4tWwW43l11DFikCw== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 18 Dec 2020 01:24:26 -0000 Date: 17 Dec 2020 20:24:26 -0500 Message-ID: <43b5a838-c94b-7690-c62f-8ef69aeb338@taugh.com> From: "John R Levine" To: "Ned Freed" Cc: emailcore@ietf.org In-Reply-To: <01RTABPBJB7C004QVR@mauve.mrochek.com> References: <9ABCA62E3E54C4356D09E1EE@PSB> <20201217205413.D68C32AC973F@ary.qy> <01RTABPBJB7C004QVR@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] Two extra issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 18 Dec 2020 01:24:38 -0000 On Thu, 17 Dec 2020, Ned Freed wrote: > There's still quite a few HELO's being sent by IOT stuff that supports email. > And I can understand why - when every byte counts, code to fall back from EHLO > to HELO isn't going to be written. Is that SMTP or submission? I think we will continue to tolerate a lot more sloppiness in submission than in SMTP relay. 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 Dec 18 09:23:40 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7FB3A0AF9 for ; Fri, 18 Dec 2020 09:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImDhhM0bct47 for ; Fri, 18 Dec 2020 09:23:38 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE60B3A0AF8 for ; Fri, 18 Dec 2020 09:23:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608312215; bh=Bs4uICMByxcPQ02js2gChGBgR+n/pQcDmwiK1Jmaxk8=; l=878; h=To:References:From:Date:In-Reply-To; b=BNQEnkZN7E0D8fWm6hHLKy2KH72RyZohOiYvmM5k1xeQjVBZMpjX6ctzMi4NTykgE 0OFkwpjhqX8KN/RMzEJqHBl29jhqgda1hvD6APJSQD+rMLxLFEGfcdGR4zUOHMTSin aPLhEdp4cv4ddLJCKV5A1EzzoQpzJyUFpU9hF22zmRqztisetBA6LYCVb5ZPn Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.000000005FDCE597.00000282; Fri, 18 Dec 2020 18:23:35 +0100 To: emailcore@ietf.org References: <9ABCA62E3E54C4356D09E1EE@PSB> <20201217205413.D68C32AC973F@ary.qy> <01RTABPBJB7C004QVR@mauve.mrochek.com> <43b5a838-c94b-7690-c62f-8ef69aeb338@taugh.com> From: Alessandro Vesely Message-ID: <7d8d3332-209e-85d9-957c-dec9c0e4c830@tana.it> Date: Fri, 18 Dec 2020 18:23:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <43b5a838-c94b-7690-c62f-8ef69aeb338@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Two extra issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 18 Dec 2020 17:23:40 -0000 On Fri 18/Dec/2020 02:24:26 +0100 John R Levine wrote: > On Thu, 17 Dec 2020, Ned Freed wrote: >> There's still quite a few HELO's being sent by IOT stuff that supports email. >> And I can understand why - when every byte counts, code to fall back from EHLO >> to HELO isn't going to be written. > > Is that SMTP or submission?  I think we will continue to tolerate a lot more > sloppiness in submission than in SMTP relay. What is going to be gained by not tolerating HELO on port 25 any more? The server code is not going to shrink considerably, especially if the same code also supports port 587. Sometimes I use HELO for a quick test with telnet[*] if for some reason I don't want the terminal window to scroll by the amount of lines that EHLO responses imply. Best Ale -- [*] Telnet: another candidate to historic which still comes in handy. From nobody Fri Dec 18 09:45:48 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB763A0B18 for ; Fri, 18 Dec 2020 09:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=rJwwNhYL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UVLV9ArK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKGdIil6tzri for ; Fri, 18 Dec 2020 09:45:43 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AEC43A0957 for ; Fri, 18 Dec 2020 09:45:43 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 960BE9E2; Fri, 18 Dec 2020 12:45:42 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Fri, 18 Dec 2020 12:45:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=4lzy+8Aw+RjSRDGZjiazJTIFN3HAUTk t8YJ4XQiFCvw=; b=rJwwNhYLOLxvFYXzoTgpUqZuE4RQmrLvaGxiI8VXXP/XWiv jY1F/qYovdGyq9uyA+8jInOuDSlGNmiugmi7+BitfthVFyAc2Al35pafVbBaNcvh T2EepT+gochpcfVpEUazAi+Vqt9gNZJ/Sqxoa2zPnTnYuMbYBXaULgrLjTEXrrPR MClJoK30AoDpSepnO3F6OEjYVJbLHcREVAXyWLOcI8ybB8qeQ9UaHmqxVVWN912E jzW1imNMDXoT5W74jTTUz3n2ZLSjlfcZg8paUVkU4OsrvUAOnfpMQKb4IuRZdfBE 1s4fous2F2+lZMDXCFyqIc23jTYIRn2YHeMKU8Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=4lzy+8 Aw+RjSRDGZjiazJTIFN3HAUTkt8YJ4XQiFCvw=; b=UVLV9ArKkcQyZbNUF48bsx sWtnvV4z1heOvFs8+/SiujkR/a/MTSJ6rKUZvrcF3fAq2ROJGEv5hgdyVQ/qO0cL saOKX7pz3lbgOcWP/t+Q36jWWk1gmTz7n7q+3KsPdFmxF4c5SVYG+6LATIJ6bcPN Src0Ux3civV+LUx8dGiSYaqlm1s9PKHe81F4uY5rrPg4RKaipwDNhkzNdpNq6gX+ UEhAqYtlwtMzW1jZhzEf+H5/yEXlkTaISJhCSbbcRIBzqPBe/10xFyXpHfwmH2hk +PNf9jArUbABOtsr/tLaZsDK/5kGLjGmqGEkvn5sQRsf9EXiR5ub6oOPziHGrTQw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeliedguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepfdetlhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghm vghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghrnheplefftd fghfevueduiefhffejlefgtdduhfdvtedtheeftedthfeghfefiefggeffnecuffhomhgr ihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EC0B16F60065; Fri, 18 Dec 2020 12:45:08 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: <6c4c5b51-69df-49be-b7b0-9a35f76c0e78@www.fastmail.com> In-Reply-To: <9ABCA62E3E54C4356D09E1EE@PSB> References: <9ABCA62E3E54C4356D09E1EE@PSB> Date: Fri, 18 Dec 2020 17:43:21 +0000 From: "Alexey Melnikov" To: "John C Klensin" , emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Two extra issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 18 Dec 2020 17:45:46 -0000 Hi John, On Thu, Dec 17, 2020, at 5:02 AM, John C Klensin wrote: > Hi. > > As mentioned in my note about ticket #2 sent about an hour ago, > two additional issues came to my attention (or I was reminded > about them) while looking at that issue and looking through the > document. > > I've put them into the working version of what will become > draft-ietf-emailcore-rfc5321bis-01 as: > > ---- > > G.12. Extension Keywords Starting in 'X-' > > Section 2.2.2 contains a discussion of SMTP keywords starting > in "X". > Given general experience with such things and RFC 6648, is > there any > reason to not deprecate that practice entirely and remove > that text? > If we do so, should Section 4.1.5 be dropped or rewritten to > make > clear this is an obsolete practice? New ticket: > G.13. Deprecating HELO > > RFC 5321 (and 2821 before it) very carefully circle around > the status > of HELO, even recommending its use as a fallback when EHLO is > sent > and a "command not recognized" response is received. We are > just a > few months short of 20 years; is it time to deprecate the > thing and > clean out some or all of that text? And, given a recent > (4Q2020) > discussion on the EMAILCORE list, should EHLO be explicitly > bound to > SMTP over TCP with the older transports allowed only with > HELO? > While those questions may seem independent, separating them > is fairly > hard given the way the text is now constructed. New ticket: > Two more things... > > (1) I think I've figured out how to overlay the ticket numbers > from https://trac.ietf.org/trac/emailcore/report/1 onto the > relevant lists in 5321bis where they are applicable, so the > request for someone to build a table for me is withdrawn -- they > will be in the next version. > > (2) I await guidance from the WG Chairs as to when to post a new > version. My personal preference would be to wait until we have > at least a few more tickets resolved, but up to them (and the > WG). I agree, you should wait until a few more issues are resolved. Best Regards, Alexey From nobody Fri Dec 18 09:49:52 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B173E3A0B32 for ; Fri, 18 Dec 2020 09:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=GId4YYXo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=h/HT1qJJ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLwsIT14kK8B for ; Fri, 18 Dec 2020 09:49:49 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674573A0B2D for ; Fri, 18 Dec 2020 09:49:49 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id D5432B01 for ; Fri, 18 Dec 2020 12:49:48 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Fri, 18 Dec 2020 12:49:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=ROPjy zbm9SrVo17puK0t1DW7/x3EW9SAOHDbqVtysC8=; b=GId4YYXodx2KvK3xdkK2m 6yV5ki5BoEPZ0UA4m52bYj4UID5/ntdiU2yz5qTkWX/nnP4cbaYNH37xUUPlTJsg cLeg89TzAc1rtNmFicqu0R3dEVQ5hAR9In2pdiJuDhwzta9qbiNr6wGN0U/M97eT 5y4Xc3Y34tdiO8ujAlcjCPc3v5O9ze1K5CruZ4LmG7VX6jPzEyucxHJM7mo+d7cM sz96tXxm3XXkRJfQLcGeQI2t9QSHexuMKaqQBzPb21q2BsC2Aiio2Lrx9RWLnE2B HEwBTdnFmlxefUb0IPw7lZ/81gwyrsjvyTt2esZ+tUIqCu2gHyci6kOg1Odz6/Vp w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=ROPjyzbm9SrVo17puK0t1DW7/x3EW9SAOHDbqVtys C8=; b=h/HT1qJJWd/Uos6e2Vc4a9lPOjG4v+tj2OnFAAJWtZ4KrrayWV1O2svuh wfaP3Z2Fb1xoIGogNn2UilmpT/ogHmB0frdCrpAxmflqeEPd+X2yDlcCmiDNY7jJ plC4Xtt+9q77HohupB+TYDKLJl7WZJGckOXrJDpc0xVqx+XEbaH9RJdIDqrPUXW1 35x0owbDdkf+mbiXr6IGbDCAX4MAaGzo+WUoq1ogvcrtRBWjYXWSDQDAPMNrTVgM 4UjN+WFlzSywse9MK5KLscyKKqWZqnDk8e16o3ZLPuoiDI9/DAEmI0JseJuKiLhv qCxzdZTSGb+zcAaiCMqpP1KjPsTzg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeliedguddtiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedftehlvgigvgihucfovghlnhhikhhovhdfuceorggr mhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtthgvrhhnpeelie ffleeuueefkeeljeefieehgeejtddvtdduffeufeevveeftdefkeeuudevffenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikh hovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 90A826F60060; Fri, 18 Dec 2020 12:49:14 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: In-Reply-To: <7d8d3332-209e-85d9-957c-dec9c0e4c830@tana.it> References: <9ABCA62E3E54C4356D09E1EE@PSB> <20201217205413.D68C32AC973F@ary.qy> <01RTABPBJB7C004QVR@mauve.mrochek.com> <43b5a838-c94b-7690-c62f-8ef69aeb338@taugh.com> <7d8d3332-209e-85d9-957c-dec9c0e4c830@tana.it> Date: Fri, 18 Dec 2020 17:47:26 +0000 From: "Alexey Melnikov" To: emailcore@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Two extra issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 18 Dec 2020 17:49:51 -0000 On Fri, Dec 18, 2020, at 5:23 PM, Alessandro Vesely wrote: > On Fri 18/Dec/2020 02:24:26 +0100 John R Levine wrote: > > On Thu, 17 Dec 2020, Ned Freed wrote: > >> There's still quite a few HELO's being sent by IOT stuff that suppo= rts email. > >> And I can understand why - when every byte counts, code to fall bac= k from EHLO > >> to HELO isn't going to be written. > >=20 > > Is that SMTP or submission?=C2=A0 I think we will continue to tolera= te a lot more=20 > > sloppiness in submission than in SMTP relay. >=20 >=20 > What is going to be gained by not tolerating HELO on port 25 any more?= The=20 > server code is not going to shrink considerably, especially if the sam= e code=20 > also supports port 587. >=20 > Sometimes I use HELO for a quick test with telnet[*] if for some reaso= n I don't=20 > want the terminal window to scroll by the amount of lines that EHLO re= sponses=20 > imply. [As a participant] For reasons stated by Alessandro and Ned I have a weak preference to lea= ve HELO as is in rfc5321bis. Best Regards, Alexey From nobody Fri Dec 18 12:24:32 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62663A0115 for ; Fri, 18 Dec 2020 12:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HbUWydo_A9j for ; Fri, 18 Dec 2020 12:24:30 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD12B3A00F7 for ; Fri, 18 Dec 2020 12:24:30 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kqMIf-0007Js-B0; Fri, 18 Dec 2020 15:24:29 -0500 Date: Fri, 18 Dec 2020 15:24:22 -0500 From: John C Klensin To: Alexey Melnikov , emailcore@ietf.org Message-ID: In-Reply-To: References: <9ABCA62E3E54C4356D09E1EE@PSB> <20201217205413.D68C32AC973F@ary.qy> <01RTABPBJB7C004QVR@mauve.mrochek.com> <43b5a838-c94b-7690-c62f-8ef69aeb338@taugh.com> <7d8d3332-209e-85d9-957c-dec9c0e4c830@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] Two extra issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 18 Dec 2020 20:24:32 -0000 --On Friday, December 18, 2020 17:47 +0000 Alexey Melnikov wrote: > On Fri, Dec 18, 2020, at 5:23 PM, Alessandro Vesely wrote: >> On Fri 18/Dec/2020 02:24:26 +0100 John R Levine wrote: >> > On Thu, 17 Dec 2020, Ned Freed wrote: >> >> There's still quite a few HELO's being sent by IOT stuff >> >> that supports email. And I can understand why - when every >> >> byte counts, code to fall back from EHLO to HELO isn't >> >> going to be written. >> >=20 >> > Is that SMTP or submission?=C2=A0 I think we will continue = to >> > tolerate a lot more sloppiness in submission than in SMTP >> > relay. >>=20 >>=20 >> What is going to be gained by not tolerating HELO on port 25 >> any more? The server code is not going to shrink >> considerably, especially if the same code also supports port >> 587. >>=20 >> Sometimes I use HELO for a quick test with telnet[*] if for >> some reason I don't want the terminal window to scroll by >> the amount of lines that EHLO responses imply. >=20 > [As a participant] >=20 > For reasons stated by Alessandro and Ned I have a weak > preference to leave HELO as is in rfc5321bis. (As a participant and for the same reasons) I share that preference (And, as author) I recommend that the bar for making substantive changes, even to drop things previously required or allowed, should be fairly high. My inclusion of that item was because I found it in my notes from prior suggestions and comments; it was not a recommendation for any particular action. john From nobody Sun Dec 20 11:48:29 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B00F3A1176 for ; Sun, 20 Dec 2020 11:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YT8VPCVykM5t for ; Sun, 20 Dec 2020 11:48:26 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319113A1174 for ; Sun, 20 Dec 2020 11:48:26 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kr4gq-000MXQ-OZ for emailcore@ietf.org; Sun, 20 Dec 2020 14:48:24 -0500 Date: Sun, 20 Dec 2020 14:48:18 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Emailcore] rfc5321bis: SEND, SOML, and SAML X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 20 Dec 2020 19:48:27 -0000 Hi. Just to make and extra check and be sure no one is surprised: After a review of the text and a brief conversation with Alexey, I have removed the comments and parenthetical notes about SEND, SAML, and SOML from the body of the document, leaving only the discussion in Appendix F.6. That means, among other things, that as far as 5321bis is concerned (i.e., barring extensions), the MAIL command is the only way to open a mail transaction. Two questions/ requests: (1) If anyone objects to taking those comments and notes out, please speak up ASAP. Otherwise, they will be gone from draft-ietf-emailcore-rfc5321bis-01, which I hope to have posted before the end of the week. (2) There is an editor's note in the middle of F.6. Please check it and, if you think anything else is needed, please say so and, ideally, supply/specify text and where to put it. I will probably not drop the note in -01 but, if there are no comments RSN, it will disappear no later than -02 (and I might change my mind about -01). General comment for information: As I work my way back and forth through rfc5321bis, I am adding crossreferences to places where similar topics or overlaps occur. That seems second-best to the complete rewrite that I would prefer in principle but that, for the same pragmatic reasons we avoided it with DRUMS and YAM, isn't going to happen. If anyone objects in principle to more crossreferences, please speak up now. Also note that my effort to get them in is not systematic. If anyone sees areas where crossreferences should be added, I'd appreciate them being pointed out (and, unless the WG wants to review each one separately, an off-list note, ideally one with "5321bis crossreference" included in the subject line, would be fine). Moving forward. john From nobody Fri Dec 25 12:12:01 2020 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 537353A02BD; Fri, 25 Dec 2020 12:11:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emailcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emailcore@ietf.org Message-ID: <160892711929.4490.14068706251390275750@ietfa.amsl.com> Date: Fri, 25 Dec 2020 12:11:59 -0800 Archived-At: Subject: [Emailcore] I-D Action: draft-ietf-emailcore-rfc5321bis-01.txt X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Dec 2020 20:11:59 -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-01.txt Pages : 111 Date : 2020-12-25 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 as an Internet Standard.]] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5321bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-emailcore-rfc5321bis-01 https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emailcore-rfc5321bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 25 12:32:14 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C973A0762 for ; Fri, 25 Dec 2020 12:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MdostZ-GXp8 for ; Fri, 25 Dec 2020 12:32:10 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF093A07B1 for ; Fri, 25 Dec 2020 12:32:10 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kstkv-000Egl-D2 for emailcore@ietf.org; Fri, 25 Dec 2020 15:32:09 -0500 Date: Fri, 25 Dec 2020 15:32:03 -0500 From: John C Klensin To: emailcore@ietf.org Message-ID: <659BA66AB52033780E76E21B@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Emailcore] draft-ietf-emailcore-rfc5321bis-01 X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 25 Dec 2020 20:32:12 -0000 Hi. As I promised in my note posted on 20 December, draft-ietf-emailcore-rfc5321bis-01 has been posted. Important changes and loose ends (there is a more comprehensive list of changes, with better explanations, in Appendix H, Section H.3.5): (1) There are now no references to SEND, SAML, or SOML except in Appendix F, Section F.6 and in the Index. Any thoughts about whether the title of F.6 should be revised to make it clear that it is discussing those commands would be welcome. (2) I've made a few additions to the Index, including fixing what was just an error that had not been caught since RFC 5321 was published, and as mentioned on December 20, added some cross-references. (3) I've added the ticket numbers from https://trac.ietf.org/trac/emailcore/report/1 to the document. I've also added several subsections to Appendices G and H to better align with the ticket list. It occurs to me that I could create an index of the tickets that would list them in numerical order and provide page (!) references. It would require some effort so those who think it would be worth it, please speak up. (4) Please see the Editor's note in the middle of F.6 mentioned in my December 20th note. I have heard nothing from the list. Given the holiday season, I'm not ready to interpret silence as "nothing else needed" yet but probably will if no one speaks up in the next couple of weeks. (5) Several new questions and odds and ends. Again, see H.3.5. Alexey has asked that I start marked "Resolved" issues into the ticket list. I'm willing to try to do it, but believe that may be error-prone so, if someone else would like to volunteer as Keeper of the Tickets, I am sure I, and I assume the co-chairs, would appreciate it. Best wishes for anything you might be celebrating and Happy New Year. john From nobody Sat Dec 26 01:57:21 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B31E3A0FB1 for ; Sat, 26 Dec 2020 01:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKn0aJDpWMSB for ; Sat, 26 Dec 2020 01:57:16 -0800 (PST) Received: from denver.dinauz.org (denver.dinauz.org [37.59.56.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D691B3A0FB6 for ; Sat, 26 Dec 2020 01:57:15 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id B9BD160584 for ; Sat, 26 Dec 2020 10:57:11 +0100 (CET) Received: from denver.dinauz.org ([127.0.0.1]) by localhost (denver.dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iIaWAJO0_Qm for ; Sat, 26 Dec 2020 10:57:11 +0100 (CET) Received: from macbook-pro-de-julien.home (lfbn-idf3-1-527-171.w86-252.abo.wanadoo.fr [86.252.110.171]) by denver.dinauz.org (Postfix) with ESMTPSA id 962B860582 for ; Sat, 26 Dec 2020 10:57:11 +0100 (CET) X-Mozilla-News-Host: news://news.gmane.org:119 To: emailcore@ietf.org From: =?UTF-8?Q?Julien_=c3=89LIE?= Message-ID: <18c6afab-7766-9e2c-a913-02259c4afec2@trigofacile.com> Date: Sat, 26 Dec 2020 10:55:55 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: [Emailcore] Gatewaying references X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2020 09:57:19 -0000 Hi all, About gatewaying, couldn't explicit references to other RFCs be added? I would especially see RFC 5537 (Netnews Architecture and Protocols) that could be worth referencing. Notably its Section 3.10 "Duties of a Gateway". It contains useful information about outgoing and incoming Netnews gateways, that can be read in conjunction with Section 3.7 "Mail Gatewaying" of RFC 5321. Possible places where to mention Netnews gatewaying in RFC 5321: * Section 2.1. Basic Structure An SMTP server may be either the ultimate destination or an intermediate "relay" (that is, it may assume the role of an SMTP client after receiving the message) or "gateway" (that is, it may transport the message further using some protocol other than SMTP). * Section 2.3.10. Originator, Delivery, Relay, and Gateway Systems [[CREF7: [5321bis] [[Note in draft/Placeholder: There has been a request to expand this section, possibly into a more extensive model of Internet mail. Comments from others solicited. In particular, does RFC 5598 make that suggestion OBE?]] ]] Naturally, references to other protocols gatewaying mails could be added too. -- Julien ÉLIE « Je suis né trop tard dans un monde trop antique. » (Astérix) From nobody Sat Dec 26 01:57:47 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F053A0FB3 for ; Sat, 26 Dec 2020 01:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yZ7FIBD_B2E for ; Sat, 26 Dec 2020 01:57:44 -0800 (PST) Received: from denver.dinauz.org (denver.dinauz.org [37.59.56.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28233A0FB1 for ; Sat, 26 Dec 2020 01:57:43 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id 25DC360584 for ; Sat, 26 Dec 2020 10:57:42 +0100 (CET) Received: from denver.dinauz.org ([127.0.0.1]) by localhost (denver.dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeOSzZaFript for ; Sat, 26 Dec 2020 10:57:42 +0100 (CET) Received: from macbook-pro-de-julien.home (lfbn-idf3-1-527-171.w86-252.abo.wanadoo.fr [86.252.110.171]) by denver.dinauz.org (Postfix) with ESMTPSA id 041BA60582 for ; Sat, 26 Dec 2020 10:57:42 +0100 (CET) To: emailcore@ietf.org References: From: =?UTF-8?Q?Julien_=c3=89LIE?= Message-ID: Date: Sat, 26 Dec 2020 10:56:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Ticket #28: Erratum 1851: Location of text about TCP connection has closure/reset X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2020 09:57:46 -0000 Hi all, > SMTP clients that experience a connection close, reset, or other > communications failure due to circumstances not under their control > (in violation of the intent of this specification but sometimes > unavoidable) SHOULD, to maintain the robustness of the mail system, > treat the mail transaction as if a 421 response had been received and > act accordingly. > > So I think the text mentioned in the erratum should be moved after the last paragraph of Section 3.8. > > Please provide feedback on this strwman proposal. In absence of feedback, this issue will be resolved as proposed above. A bit earlier in the same Section 3.8, we have: o After detecting the need to shut down the SMTP service and returning a 421 reply code. This reply code can be issued after the server receives any command or, if necessary, asynchronously from command receipt (on the assumption that the client will receive it after the next command is issued). I'm wondering whether the part in parenthesis really occurs in practice, notably when the closure is asynchronous from command receipt. Maybe it should be reworded this way: "on the assumption that the client will receive it after the next command is issued or read it before closing the connection at its side"? Another suggestion for the new paragraph: SMTP clients that experience a connection close, reset, or other communications failure due to circumstances not under their control (in violation of the intent of this specification but sometimes unavoidable) SHOULD, to maintain the robustness of the mail system, + try to read a possible asynchronous reply from the SMTP server, and + otherwise treat the mail transaction as if a 421 response had been received and act accordingly. Naturally, if you think it makes sense. Just opening the discussion. -- Julien ÉLIE « Les trois journées de 1830 ont renversé 89. » From nobody Sat Dec 26 05:34:33 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0F43A1086 for ; Sat, 26 Dec 2020 05:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfCeIEpF_skQ for ; Sat, 26 Dec 2020 05:34:30 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694F73A1085 for ; Sat, 26 Dec 2020 05:34:30 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kt9iG-000K1L-Lf; Sat, 26 Dec 2020 08:34:28 -0500 Date: Sat, 26 Dec 2020 08:34:23 -0500 From: John C Klensin To: =?UTF-8?Q?Julien_=C3=89LIE?= , emailcore@ietf.org Message-ID: <7265708FBD5716E86851BF58@PSB> In-Reply-To: <18c6afab-7766-9e2c-a913-02259c4afec2@trigofacile.com> References: <18c6afab-7766-9e2c-a913-02259c4afec2@trigofacile.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] Gatewaying references X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2020 13:34:32 -0000 Julien, (speaking as an individual) I am very hesitant about starting to reference other protocols in 5321bis, especially at a time when we are talking about changing or removing discussion of other transports (see G.13). Even if one went down the path of using mail systems as examples, Netnews might be a particularly difficult example. It might be interesting to have an an annotated bibliography of documentation of email conventions or protocols but I don't think that belongs in 5321bis either. Perhaps in the A/S, but my guess is that it really should be a separate piece of work (if only because of the time it is likely to take). Have you considered writing one? But others may disagree. john --On Saturday, December 26, 2020 10:55 +0100 Julien =C3=89LIE wrote: > Hi all, >=20 > About gatewaying, couldn't explicit references to other RFCs > be added? >=20 > I would especially see RFC 5537 (Netnews Architecture and > Protocols) that could be worth referencing. Notably its > Section 3.10 "Duties of a Gateway". > It contains useful information about outgoing and incoming > Netnews gateways, that can be read in conjunction with Section > 3.7 "Mail Gatewaying" of RFC 5321. >=20 > Possible places where to mention Netnews gatewaying in RFC > 5321: >=20 > * Section 2.1. Basic Structure >=20 > An SMTP server may be either the ultimate destination or = an > intermediate "relay" (that is, it may assume the role of > an SMTP > client after receiving the message) or "gateway" (that is, > it may > transport the message further using some protocol other > than SMTP). >=20 > * Section 2.3.10. Originator, Delivery, Relay, and Gateway > Systems >=20 > [[CREF7: [5321bis] [[Note in draft/Placeholder: There has > been a > request to expand this section, possibly into a more > extensive model > of Internet mail. Comments from others solicited. In > particular, > does RFC 5598 make that suggestion OBE?]] ]] >=20 >=20 >=20 > Naturally, references to other protocols gatewaying mails > could be added too. >=20 > --=20 > Julien =C3=89LIE >=20 > =C2=AB=C2=A0Je suis n=C3=A9 trop tard dans un monde trop = antique.=C2=A0=C2=BB > (Ast=C3=A9rix) From nobody Sat Dec 26 08:13:46 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505563A09B5 for ; Sat, 26 Dec 2020 08:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=GFCoGC36; dkim=pass (2048-bit key) header.d=taugh.com header.b=kayBmkna Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HWyPr9CUvaH for ; Sat, 26 Dec 2020 08:13:40 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809B73A09CD for ; Sat, 26 Dec 2020 08:13:38 -0800 (PST) Received: (qmail 72394 invoked from network); 26 Dec 2020 16:13:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=11ac6.5fe76131.k2012; bh=l1oJb85UVGhHPAq/AyBQ0uc9moRol+r/SLgTnROm/K0=; b=GFCoGC36sPwlc/bTv9cq17kTcK0/Y3khD/S9DJwACPajRuBc6P8c7uk5BEtIJHXh3KEZM2aKbGRsk6+ltj8H2vEfbxDXRzGPt0mha4m21HQr8v786e2pnaEZdCxpWJMAj8ryG1rd557L/Qn5rWTPBa1oZbhBd1JKOmY72+YZUpD+ePSbHYiDL54/2yogDaqY/9uhTars0nbJD4kz3p4vqyZSNTwa/aEhnTrqhmFGZWUXXvTWlGZCqCi3nvmhhw9NjUQAr8gPm2sSbCoY6mKLN2qftdtb0Jc7Ol1GLZIBI7sk+OnlIsiXq5lrR8uELnOuq8xLomeyGnh22cXqW0eXiQ== 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=11ac6.5fe76131.k2012; bh=l1oJb85UVGhHPAq/AyBQ0uc9moRol+r/SLgTnROm/K0=; b=kayBmknaqeqOBRtr+I6ypkhNqH5ksQVx0oeQtvAkIywb3Gd+p/Izh6oQKfKQgEJbID1wgDewsrRzQaP/FgTiWysXVPSdQLEh6cxBPOunbUhVGCcOubCfEUxudVShE8JY02tFebOs+mf3+/9JdsgIHkPsaRMn0Pfxj0m2PqQ4unKgFReaFASomR184wHHh7AtC3EefVeW8O6T06UyqOa09O9DWUUwMX6FuGRtSYw0wJnienzd55Sh7syNkSzb97o1T7/o1Gtmg0MqMa472rxe77AcF70cDAlP+xCfqzSfTm7BiM41EiBFWE15InkDsvv1/Onv1JnM/5fovTSA77mHKw== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 26 Dec 2020 16:13:36 -0000 Received: by ary.qy (Postfix, from userid 501) id 471B92B6A777; Sat, 26 Dec 2020 11:13:35 -0500 (EST) Date: 26 Dec 2020 11:13:35 -0500 Message-Id: <20201226161336.471B92B6A777@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: john-ietf@jck.com In-Reply-To: <7265708FBD5716E86851BF58@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] Gatewaying references X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2020 16:13:44 -0000 In article <7265708FBD5716E86851BF58@PSB> you write: >But others may disagree. Even though I run a netnews gateway, I agree with you. Gateways are a pretty marginal feature these days, and the details are quite specific to what's on the other side. If I were going to use an example it wouldn't be netnews since it's too sasy, since its message format was deliberately designed to be almost the same as 822. R's, John >--On Saturday, December 26, 2020 10:55 +0100 Julien ÉLIE > wrote: > >> Hi all, >> >> About gatewaying, couldn't explicit references to other RFCs >> be added? >> >> I would especially see RFC 5537 (Netnews Architecture and >> Protocols) that could be worth referencing. Notably its >> Section 3.10 "Duties of a Gateway". >> It contains useful information about outgoing and incoming >> Netnews gateways, that can be read in conjunction with Section >> 3.7 "Mail Gatewaying" of RFC 5321. >> >> Possible places where to mention Netnews gatewaying in RFC >> 5321: >> >> * Section 2.1. Basic Structure >> >> An SMTP server may be either the ultimate destination or an >> intermediate "relay" (that is, it may assume the role of >> an SMTP >> client after receiving the message) or "gateway" (that is, >> it may >> transport the message further using some protocol other >> than SMTP). >> >> * Section 2.3.10. Originator, Delivery, Relay, and Gateway >> Systems >> >> [[CREF7: [5321bis] [[Note in draft/Placeholder: There has >> been a >> request to expand this section, possibly into a more >> extensive model >> of Internet mail. Comments from others solicited. In >> particular, >> does RFC 5598 make that suggestion OBE?]] ]] >> >> >> >> Naturally, references to other protocols gatewaying mails >> could be added too. >> >> -- >> Julien ÉLIE >> >> « Je suis né trop tard dans un monde trop antique. » >> (Astérix) > > From nobody Sat Dec 26 09:12:23 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADDA3A0B17 for ; Sat, 26 Dec 2020 09:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoiB1sJFZDok for ; Sat, 26 Dec 2020 09:12:20 -0800 (PST) Received: from denver.dinauz.org (denver.dinauz.org [37.59.56.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F083A0B16 for ; Sat, 26 Dec 2020 09:12:20 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id 5F45160584 for ; Sat, 26 Dec 2020 18:12:16 +0100 (CET) Received: from denver.dinauz.org ([127.0.0.1]) by localhost (denver.dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CasxzZD1l8kd for ; Sat, 26 Dec 2020 18:12:16 +0100 (CET) Received: from macbook-pro-de-julien.home (lfbn-idf3-1-527-171.w86-252.abo.wanadoo.fr [86.252.110.171]) by denver.dinauz.org (Postfix) with ESMTPSA id 3EB5E60582 for ; Sat, 26 Dec 2020 18:12:16 +0100 (CET) To: emailcore@ietf.org References: <18c6afab-7766-9e2c-a913-02259c4afec2@trigofacile.com> <7265708FBD5716E86851BF58@PSB> From: =?UTF-8?Q?Julien_=c3=89LIE?= Message-ID: <20dc9669-f500-ac9b-f508-c8f6dbd780c5@trigofacile.com> Date: Sat, 26 Dec 2020 18:10:58 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <7265708FBD5716E86851BF58@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Emailcore] Gatewaying references X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2020 17:12:22 -0000 Hi John, > I am very hesitant about starting to reference other protocols > in 5321bis, especially at a time when we are talking about > changing or removing discussion of other transports (see G.13). All right, thanks for your answer. > It might be interesting to have an an annotated bibliography of > documentation of email conventions or protocols but I don't > think that belongs in 5321bis either. Perhaps in the A/S, but > my guess is that it really should be a separate piece of work > (if only because of the time it is likely to take). Have you > considered writing one? I still have not considered writing one. What I had in mind with my remark about gatewaying was not that extensive but only 5 lines max, just to give more substance to the following sentence, giving examples of gateways. An SMTP server may be either the ultimate destination or an intermediate "relay" (that is, it may assume the role of an SMTP client after receiving the message) or "gateway" (that is, it may transport the message further using some protocol other than SMTP). I'm fine with not changing anything. It's just a detail. -- Julien ÉLIE « Tant qu'il y a des marmites, il y a de l'espoir ! » (Astérix) From nobody Sat Dec 26 09:48:56 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0603A0B92 for ; Sat, 26 Dec 2020 09:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avDiUXhgbCPY for ; Sat, 26 Dec 2020 09:48:53 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1493A0B8F for ; Sat, 26 Dec 2020 09:48:52 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ktDgR-000LbX-Ik; Sat, 26 Dec 2020 12:48:51 -0500 Date: Sat, 26 Dec 2020 12:48:45 -0500 From: John C Klensin To: =?UTF-8?Q?Julien_=C3=89LIE?= , emailcore@ietf.org Message-ID: <3099C5731A105B7CB16F261D@PSB> In-Reply-To: <20dc9669-f500-ac9b-f508-c8f6dbd780c5@trigofacile.com> References: <18c6afab-7766-9e2c-a913-02259c4afec2@trigofacile.com> <7265708FBD5716E86851BF58@PSB> <20dc9669-f500-ac9b-f508-c8f6dbd780c5@trigofacile.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] Gatewaying references X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2020 17:48:55 -0000 --On Saturday, December 26, 2020 18:10 +0100 Julien =C3=89LIE wrote: > Hi John, >=20 >> I am very hesitant about starting to reference other = protocols >> in 5321bis, especially at a time when we are talking about >> changing or removing discussion of other transports (see >> G.13). >=20 > All right, thanks for your answer. >=20 >=20 >> It might be interesting to have an an annotated bibliography >> of documentation of email conventions or protocols but I = don't >> think that belongs in 5321bis either. Perhaps in the A/S, = but >> my guess is that it really should be a separate piece of work >> (if only because of the time it is likely to take). Have you >> considered writing one? >=20 > I still have not considered writing one. > What I had in mind with my remark about gatewaying was not > that extensive but only 5 lines max, just to give more > substance to the following sentence, giving examples of > gateways. >=20 > An SMTP server may be either the ultimate destination or = an > intermediate "relay" (that is, it may assume the role of > an SMTP > client after receiving the message) or "gateway" (that is, > it may > transport the message further using some protocol other > than SMTP). Understood. Let me borrow from John Levine's comment to further explain why I'm reluctant to start down that path. If one were to pick a single example, the Netnews gateway would probably not be it because it was designed to use 822-like headers. If one did this, one might prefer to use a come complex In addition, it is essentially a redistribution service not user to user email on both directions: discussing it would possibly drag us into issues with rewriting backward-pointing addresses. Because it is really interpersonal mail rather than distro lsit to person or person to distro list and while it is little used today, one might want to cite RFC 2156 and some of the supplemental specifications instead or in addition to Netnews. The reason for going into the above is not to push back on your specific suggestion, just to point out how complicated simple and seemingly-obvious suggestions such as yours can get very complex (and expand well beyond five lines) very quickly. =20 > I'm fine with not changing anything. It's just a detail. Thanks. john From nobody Sat Dec 26 11:52:39 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F4E3A0EF8 for ; Sat, 26 Dec 2020 11:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQQF5IIPtvhr for ; Sat, 26 Dec 2020 11:52:35 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04A93A0EF6 for ; Sat, 26 Dec 2020 11:52:35 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTMPBK3U7400D0LW@mauve.mrochek.com> for emailcore@ietf.org; Sat, 26 Dec 2020 11:47:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1609012051; bh=063Wc47vyxQi8WQ4lc6/KOT5IXtTNT6WWHgHdoaDHoA=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=BW8nYSrOsnwrvGNN1VR1SYaTcVUqDvvEmamMCemh9OpXLNMi2spBFo5A64+NxagMa VGxJBd25opKTnM8Dew966H8JrIS1eULfdZTHjmyPa9gZLtCh8mn4VDm/YWAdq8825c 6rFhNK3LW9luMx7xLI/dMRUY/49a4/6pr3rsGqvU= 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 <01RTJOWYX49S004QVR@mauve.mrochek.com>; Sat, 26 Dec 2020 11:47:29 -0800 (PST) Cc: emailcore@ietf.org, john-ietf@jck.com Message-id: <01RTMPBHLJNG004QVR@mauve.mrochek.com> Date: Sat, 26 Dec 2020 11:31:43 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sat, 26 Dec 2020 11:13:35 -0500" <20201226161336.471B92B6A777@ary.qy> References: <7265708FBD5716E86851BF58@PSB> <20201226161336.471B92B6A777@ary.qy> To: John Levine Archived-At: Subject: Re: [Emailcore] Gatewaying references X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2020 19:52:37 -0000 > In article <7265708FBD5716E86851BF58@PSB> you write: > >But others may disagree. > Even though I run a netnews gateway, I agree with you. Gateways are a > pretty marginal feature these days, Actually it's just the opposite - far from vanishing, email gatwways have gone mainstream. The obvious example is gateways to and from various notification services, but application gateways are also fairly commmon. What has gotten marginalized are gateways to things the IETF has taken to be within its purview, including other email systems and netnews. > and the details are quite specific > to what's on the other side. In some senses yes, others not so much. You have to think pretty generally when you gateway to something that in turn connects to all sorts of other stuff. > If I were going to use an example it > wouldn't be netnews since it's too sasy, since its message format was > deliberately designed to be almost the same as 822. Gateways are interesting architecturally because of the different ways they can interact with submission and final delivery. But since we can't even get agreement on how to deal with these things within the homogeneous email world, I think this is a potential rathole we'd best steer clear of. And aside from noting they exist, I don't really see them as being in scope for the core email specifications. Ned From nobody Sat Dec 26 12:08:18 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECB13A0EF8 for ; Sat, 26 Dec 2020 12:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXRbTP4bUECB for ; Sat, 26 Dec 2020 12:08:15 -0800 (PST) Received: from cockroach.ash.relay.mailchannels.net (cockroach.ash.relay.mailchannels.net [23.83.222.37]) (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 395F03A08AE for ; Sat, 26 Dec 2020 12:08:13 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D2D04541F91; Sat, 26 Dec 2020 20:08:09 +0000 (UTC) Received: from nl-srv-smtpout2.hostinger.io (100-96-5-83.trex.outbound.svc.cluster.local [100.96.5.83]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 27EBA541FBA; Sat, 26 Dec 2020 20:08:08 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout2.hostinger.io ([UNAVAILABLE]. [145.14.159.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Sat, 26 Dec 2020 20:08:09 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Lettuce-Obese: 26456ea52669f0ca_1609013289468_840255840 X-MC-Loop-Signature: 1609013289468:3276642445 X-MC-Ingress-Time: 1609013289467 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout2.hostinger.io (smtp.hostinger.com) with ESMTPSA id ACE6B333EFB7; Sat, 26 Dec 2020 20:08:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1609013286; bh=oCbIRyq+L7h8HSLQGerLb7Zz1+88Cgk9S7oQheUQw1E=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=L4RcEWW07IvUunwRl2ajpEMo5SB0XJ7W+CEhml0WG26G0YrFdwrL22F9ALg/y3oM6 pY8bfSKyH54cgP2PBV9RUejoBZeYrCAx4bCIO0XwgE01huDZ2lgfJqiyFi587YoH+b xv8VjIzIY7sPoLS390hXzgL7GzHPDv5CC7yH1OrvY3VPk8KNEhAtzqYu8hXlKW41OH PG4+C2ZAmFqt9K2TYJWa/ZAx8yTt8LfySQhQ3d1YrPFos+mhaC4dXqB8UwVA9Gvtuv mXOPRMRScUafMG8t0N6ep8PfsXXAr7bzU/fOzD9QhdKaqkBwSj5x8Sfiy84t6RnymJ yWI0cP4adTDlQ== Reply-To: dcrocker@bbiw.net To: Ned Freed , John Levine Cc: john-ietf@jck.com, emailcore@ietf.org References: <7265708FBD5716E86851BF58@PSB> <20201226161336.471B92B6A777@ary.qy> <01RTMPBHLJNG004QVR@mauve.mrochek.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <0f19f818-54ee-8f4a-0cda-dce6dd994e7a@dcrocker.net> Date: Sat, 26 Dec 2020 12:08:00 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <01RTMPBHLJNG004QVR@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Gatewaying references X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2020 20:08:17 -0000 On 12/26/2020 11:31 AM, Ned Freed wrote: > Gateways are interesting architecturally because of the different ways they can > interact with submission and final delivery. But since we can't even get > agreement on how to deal with these things within the homogeneous email world, > I think this is a potential rathole we'd best steer clear of. > > And aside from noting they exist, I don't really see them as being in scope > for the core email specifications. Exactly. SMTP provides a basic relaying capability, within a homegenous service. The SMTP specification is not the place for broader discussion of all things email. Let's get clarity about the scope of this document -- hopefully a narrow scope -- and remove portions that are outside of that. Gatewaying (and mailing lists, and...) are obvious examples. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Dec 26 12:25:42 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C283A0F00 for ; Sat, 26 Dec 2020 12:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=jsctVbbo; dkim=pass (2048-bit key) header.d=taugh.com header.b=j5oQ8RSh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiZv3JQYs1NU for ; Sat, 26 Dec 2020 12:25:38 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E52C3A0EFF for ; Sat, 26 Dec 2020 12:25:38 -0800 (PST) Received: (qmail 38129 invoked from network); 26 Dec 2020 20:25:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=94ee.5fe79c41.k2012; i=johnl-iecc.com@submit.iecc.com; bh=cxJO5mzMWM4wFAbByTlsVmdnawywKFfDoKIttthGSmU=; b=jsctVbboN1VXbnLU5sOC6SQtOImNhnxB4cb279Gi00ZHR38zd6rMex80uEpCSGqP/Nh2K6dQAl3xNansjjVlB7Z0NuT7r7AyCjiFY3AuZQ6+ssOBOqQ9EVP5IAskCCibcj6oHN1YcMZlisFdS2NbgqPqqd9kFcuS8dnpFC5wWVDn/MNS+pYkRybhdwWeO7uGR/GTX2siQWHxhB0awjJjT8yq1pSMSogI3yB854+FEa2E6AhqKzgCuYtrx49QCrp4ynONa94umG6WenpaOk1DE/kPzFKnoyiAWUo4EcaNcIZRD4sFz513rcXdWUTDiMiMMy2n0w2rpxtlauZ/lCLWvA== 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=94ee.5fe79c41.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=cxJO5mzMWM4wFAbByTlsVmdnawywKFfDoKIttthGSmU=; b=j5oQ8RShk0HwszEz77SHbAF6wiysMNCzR1LGdwRw1ZGSTOYB+7voIdIYlQ2nXj2miScM7M9oNbH0cHsvzOtiW/3et5h+2XGgNGWROEJZI0SM5kpettSbDdbbdBy3Kbm9g0j57xQlRHBfv33KsNwXHFPeAVrZweDUtVI/HHWDciULgSL4R6OZeA6FAAzenlgFuo02UVf910W1O2hZ9kJDHtVWcdLqdgwoxOg07jwXbyNtIuC8N1ggVWIyXqc6oU8N6ip6/G4oiAPawPVP7dxSIXB29f6KlMmQag9CY/7EWeL5C6bPq2ZmLOo2nk7HSMDtBUY2Y+bSJfxRWVD2sTWpRA== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 26 Dec 2020 20:25:37 -0000 Date: 26 Dec 2020 15:25:36 -0500 Message-ID: <348d6daf-cd2e-775-3554-a05fb9c0f247@taugh.com> From: "John R Levine" To: "Ned Freed" Cc: emailcore@ietf.org In-Reply-To: <01RTMPBHLJNG004QVR@mauve.mrochek.com> References: <7265708FBD5716E86851BF58@PSB> <20201226161336.471B92B6A777@ary.qy> <01RTMPBHLJNG004QVR@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] Gatewaying references X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2020 20:25:40 -0000 On Sat, 26 Dec 2020, Ned Freed wrote: >> pretty marginal feature these days, > > What has gotten marginalized are gateways to things the IETF has taken > to be within its purview, including other email systems and netnews. You are certainly correct. On my tiny system I have at least a dozen service gateways to things that do stuff with the message contents, but only the mailing lists pass them along as something like a message. > And aside from noting they exist, I don't really see them as being in scope > for the core email specifications. Yup. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Dec 28 06:35:39 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32B13A0BDE for ; Mon, 28 Dec 2020 06:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Q8f873HdBxVf for ; Mon, 28 Dec 2020 06:35:35 -0800 (PST) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4C33A0BD7 for ; Mon, 28 Dec 2020 06:35:35 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTP6U4H6JK005BWY@mauve.mrochek.com> for emailcore@ietf.org; Mon, 28 Dec 2020 06:30:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1609165827; bh=Z0jAPInptHIHZbaX29hnkR8N/7rY5db6l7eW7toy+Lg=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=eP/UUBHPd1Ru6sv7EgbUY3BZO8fmSqrQRum6Ha2hkLjEtSwUmRjTAl28qc4hPWgrD px+VJ0hSome3C/Vmhw4OkgaCXMvBNrYJVuvl4zxqTllB/A4cVVSbcsk7+YW2L+3Pzb pPwser6/fijSd6txhFTBXpkVMoj38W8hd6q9VF00= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTJOWYX49S004QVR@mauve.mrochek.com>; Mon, 28 Dec 2020 06:30:22 -0800 (PST) Cc: Ned Freed , John Levine , john-ietf@jck.com, emailcore@ietf.org Message-id: <01RTP6TZ9LJY004QVR@mauve.mrochek.com> Date: Mon, 28 Dec 2020 06:14:50 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sat, 26 Dec 2020 12:08:00 -0800" <0f19f818-54ee-8f4a-0cda-dce6dd994e7a@dcrocker.net> References: <7265708FBD5716E86851BF58@PSB> <20201226161336.471B92B6A777@ary.qy> <01RTMPBHLJNG004QVR@mauve.mrochek.com> <0f19f818-54ee-8f4a-0cda-dce6dd994e7a@dcrocker.net> To: Dave Crocker Archived-At: Subject: Re: [Emailcore] Gatewaying references X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 28 Dec 2020 14:35:37 -0000 > On 12/26/2020 11:31 AM, Ned Freed wrote: > > Gateways are interesting architecturally because of the different ways they can > > interact with submission and final delivery. But since we can't even get > > agreement on how to deal with these things within the homogeneous email world, > > I think this is a potential rathole we'd best steer clear of. > > > > And aside from noting they exist, I don't really see them as being in scope > > for the core email specifications. > Exactly. > SMTP provides a basic relaying capability, within a homegenous service. > The SMTP specification is not the place for broader discussion of all > things email. > Let's get clarity about the scope of this document -- hopefully a narrow > scope -- and remove portions that are outside of that. Gatewaying (and > mailing lists, and...) are obvious examples. I'm afraid I have to disagree. Getting rid of any specific discussions about gateways is fine because that can, and should, be left to the specifications for those gateways, e.g., RFC 2156 and RFC 5536. But this doesn't work with mailing lists. You might, and I emphasize might, be able to get rid of discussion of mailing lists if there was a separate standards-track document specifying how they operate them that could be referenced. But AFAIK there isn't, and like it or not, mailing list are deeply ingrained in the fabric of the current email service. This is a practical concern, not a theoretical one, and no amount of architectural maneuvering can eliminate it. The only approach I can think of given the current state of the standards that could possibly make it acceptable to eliminate the discussion of mailing lists would be to reference the descriptions of mailing lists in both RFC 5321 and the NOTARY specifications. But I have to say I find the idea of doing this extremely distasteful. Ned From nobody Mon Dec 28 06:50:12 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8123A0BF2 for ; Mon, 28 Dec 2020 06:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7RvyIcNDcWy for ; Mon, 28 Dec 2020 06:50:09 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1653A0BF0 for ; Mon, 28 Dec 2020 06:50:09 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kttqS-000BaG-QC; Mon, 28 Dec 2020 09:50:00 -0500 Date: Mon, 28 Dec 2020 09:49:54 -0500 From: John C Klensin To: Ned Freed , Dave Crocker cc: John Levine , emailcore@ietf.org Message-ID: In-Reply-To: <01RTP6TZ9LJY004QVR@mauve.mrochek.com> References: <7265708FBD5716E86851BF58@PSB> <20201226161336.471B92B6A777@ary.qy> <01RTMPBHLJNG004QVR@mauve.mrochek.com> <0f19f818-54ee-8f4a-0cda-dce6dd994e7a@dcrocker.net> <01RTP6TZ9LJY004QVR@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Gatewaying references X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 28 Dec 2020 14:50:10 -0000 --On Monday, December 28, 2020 06:14 -0800 Ned Freed wrote: >... > The only approach I can think of given the current state of > the standards that could possibly make it acceptable to > eliminate the discussion of mailing lists would be to > reference the descriptions of mailing lists in both RFC 5321 > and the NOTARY specifications. But I have to say I find the > idea of doing this extremely distasteful. Specifically, removing the text from 5321bis but referencing 5321 would imply that 5321bis could not properly obsolete 5321 _and_ would make it harder for people to answer the questions "what are the core email specs" and "to what is conformance specified". To me, that would cancel out most of the purpose of this exercise. Put differently, instead of doing 5321bis, we could create a new document specifying only changes to 5321 and then move them to Internet Standard as a pair, still creating more complexity for the reader, but at least not confusing as to status. And, btw, I agree with everything else Ned wrote. john I agree with everything else From nobody Mon Dec 28 10:33:29 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB46E3A0CE3 for ; Mon, 28 Dec 2020 10:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=HqzYGnjK; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=ooLd+lrW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGallGiAINQS for ; Mon, 28 Dec 2020 10:33:26 -0800 (PST) Received: from mail.winserver.com (unknown [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27283A0CE0 for ; Mon, 28 Dec 2020 10:33:25 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2282; t=1609180404; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=ezbyBo2M1PTCcCe31z3JUsjiwyVQ BOg7AUnVEXQGERU=; b=HqzYGnjKUANZEaVKZi6fq6BJg+9D2FiJlEsY05K1g6ST dY3Lutbw4aHClTSmo0fVV9TWKa3g4DUv7gU9AilYCfQDX/TCP85mSID8GvJ6PnVk V8Wdk41oXHEwefzihr5egRtUpyOOGhTOuCpn8h00/X50TKUfucywehhsKuu0KNg= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Mon, 28 Dec 2020 13:33:24 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2620469104.16935.3248; Mon, 28 Dec 2020 13:33:22 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2282; t=1609180034; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ezbyBo2 M1PTCcCe31z3JUsjiwyVQBOg7AUnVEXQGERU=; b=ooLd+lrWUpvHXQ+BJkSzXhN 32SBro/CsKYlXFCNl/TBmgukmRhnx4SeVtg9Bsf5mEazpUt4H4YBbw3iJbq1s736 FsriOlh+yPhXhEbmRSChlRiJigWoIr/RUGSPEcygo2zMo+qjDFnJXqO0x+tgGhq2 CxtPqJ3BKjTn6/xxhM3Y= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for emailcore@ietf.org; Mon, 28 Dec 2020 13:27:14 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2487338392.1.21528; Mon, 28 Dec 2020 13:27:13 -0500 Message-ID: <5FEA24F1.2090508@isdg.net> Date: Mon, 28 Dec 2020 13:33:21 -0500 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Ned Freed CC: john-ietf@jck.com, emailcore@ietf.org References: <7265708FBD5716E86851BF58@PSB> <20201226161336.471B92B6A777@ary.qy> <01RTMPBHLJNG004QVR@mauve.mrochek.com> In-Reply-To: <01RTMPBHLJNG004QVR@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Gatewaying references X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.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, 28 Dec 2020 18:33:28 -0000 On 12/26/2020 2:31 PM, Ned Freed wrote: > Actually it's just the opposite - far from vanishing, email gatwways have gone > mainstream. The obvious example is gateways to and from various notification > services, but application gateways are also fairly common. +1, email gateways continues be used in all sorts of ways, besides just email to nntp (NetNews). We still allow for non-SMTP transports using UUCP-style Inbound (X/D) / Outbound (XQT/CMD/DAT) queuing system. In terms of Mail Gateways, we will always have a need for transformation support for heterogeneous mail/file/data networks. Not everything is 822/2822/5322 format and in growing instances and needs, you don't need the the massive growing overhead in RFC5322 headers, and its not even necessary overhead anymore but junk and bunch of tracers that when things are normal, its redundant overhead. IMO, what has been #1 requirement or need to make a gateway work is the make sure there is a two-way network reply protocol in place, regardless of the transformation which may contribute to impurities. So identification and outlining the key mail identities for the transformation would be a useful exercise for this work. Imo, these are essential mail identities for the basic mail I/O conversation: Date: From: To/cc: Subject: [Network-Reply-Address] [Network-To-Address] The network addresses could be hidden if not shown in Display. We did this for Fidonet, QWK, UTI and other networks like the RFC822 format. We now have RFC5322 becoming the essential format to use, to display and also transport data and we have pressures to use JSON or XML formats too. What about this JMAP? I haven't been involved but it seems there is a push there. Before that can prosper, it will need to deal with backward compatibility and gateways as well. Overall, I welcome this exercise in discussing "Gateways." What are the new identities legacy systems may have to deal with? PS: I had this public email to nntp (NetNews) gateway for a long time (more than 10 years) for the IETF Drafts. This is how I see this and browse the drafts. news://publicnews.winserver.com/ietf-drafts -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Thu Dec 31 06:45:32 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE1B3A0CCC for ; Thu, 31 Dec 2020 06:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=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 W8MKUQ3yDLnq for ; Thu, 31 Dec 2020 06:45:29 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA6E3A0CC7 for ; Thu, 31 Dec 2020 06:45:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609425925; bh=DodoMsm3HODpAk/K8RmtvBHnAayPmB9xhKjszIBXKDw=; l=636; h=To:From:Date; b=Con6pR4kPIA1IroHtQEi7VnourQ4nDD9L6VFGtqLA0XQgTO1YYV9OCQO3xhWD/vQH oYoisGjWClB7nzWPD8/0zx2yXllAu8eT3z5G+1B84u0Df6MwaGlHY9HPJgqajvav5y AIz1KeMzFvJWTSGnZsBdJ+vJXxGE1Bxe6x6mUMdVX1t29yysaKMEUiBtlpoVj 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.000000005FEDE405.0000123F; Thu, 31 Dec 2020 15:45:25 +0100 To: emailcore@ietf.org From: Alessandro Vesely Message-ID: <101f868f-b277-2ff3-56dc-44f721dc2f78@tana.it> Date: Thu, 31 Dec 2020 15:45:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] Spurious gatewaying reference X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 14:45:30 -0000 Hi, Section 4.5.5 starts with the paragraph: There are several types of notification messages that are required by existing and proposed Standards to be sent with a null reverse-path, namely non-delivery notifications as discussed in Section 3.7, other kinds of Delivery Status Notifications (DSNs, RFC 3461 [33]), and Message Disposition Notifications (MDNs, RFC 3798 [37]). All of Now, Section 3.7 is "Mail Gatewaying". What is it referenced for here? Perhaps, the paragraph should refer to Section 3.6.3, "Message Submission Servers as Relays", which discusses non-delivery notifications. Best Ale -- From nobody Thu Dec 31 07:50:57 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66693A0D50 for ; Thu, 31 Dec 2020 07:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=e39MEqeB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KEOnUkuX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OsUwis99EYp for ; Thu, 31 Dec 2020 07:50:55 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79F223A0D4B for ; Thu, 31 Dec 2020 07:50:55 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B8EF15C00E2; Thu, 31 Dec 2020 10:50:54 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Thu, 31 Dec 2020 10:50:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=cddBhb9ec4swf/LUUVZbs/ToUi5PSix AGGdN2ZmQ/Xo=; b=e39MEqeBofiNUsMwhHgeZQTWV2gNZC+O4iwKWn5XV6F64uH ewSkkf2KW5VgQLfyrE9FmlNB1iRkyyKm8FNyLNnnBqAl4LuyGhlNA5ayKYgr71W0 dTqi96lfEy38M9R+B57TkvZ5P7oZTXNOwiYtIsVskjel0mgArOfuyzefhWJi4AHj Jc+JPJH34cgUVVr4zGaQpLEiLBCFRLuTtRRYhXpPiJH03FyZ/+sHuVWKPVpsSCyq 9gHvxOCSd68wqOVFJtklxekfNkA4NybxICdZTlR90lqLtbLvim8ZtaS040OK44e5 Q6x2l9ByUIsuM6IgjcpFG3oYh22p7Efr8iDWdcA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=cddBhb 9ec4swf/LUUVZbs/ToUi5PSixAGGdN2ZmQ/Xo=; b=KEOnUkuXy11VOoVCIa0Dhw 7dmbhVmDhhj9ULpnti+DEurHWWxzLpfNyvxUcPtEFsxA+EsLFFAInue2Ug+oMo2D b+ZcjC1dBIsoeNX5uW6OgC0/G4hBDSwRT+U7LYp6XoA3f9CZujD91bKlSsAKepWQ sjxPwIiBIUG1DKVBnzZtoBmFyOdGB/84wAlA2PKOj6EMloUZMf/7glg0PyKolHRv Q8PaD4hJ84uzh5q1ocbsH8uR4CUVI8EyJegk+XywoOFBgJ9YgextpLWhhvMsC5m4 sfBLdiX1WHKTbmBXw0b8YVvn0CzCMbhPaQ4pQaZODr7Pk5P8UHakFgqsh+QE6zvg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddvhedgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedftehlvgigvgihucfovghlnhhikhhovhdfuceorggrmhgv lhhnihhkohhvsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtthgvrhhnpeefveetke effeetteegtdeghfeigeeiteeghfekiefgudfhgfejvdduudekjeefieenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovh esfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 43FB26F60152; Thu, 31 Dec 2020 10:50:07 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: In-Reply-To: <43614EAB7197EC7902FE4C30@PSB> References: <20201015180935.DBE31237B8C7@ary.qy> <765c8465-8aa0-450f-9d7e-7ba540410f74@www.fastmail.com> <5F89DC39.9040505@isdg.net> <1575474d-fb98-5a88-eeed-d39c922ce8ac@tana.it> <5b01b27b-fa8c-4dce-b0d1-98a48029901b@www.fastmail.com> <7B76DDDD7606B27CA830E9E9@PSB> <47EF54E0B8D9A53E24071951@PSB> <43614EAB7197EC7902FE4C30@PSB> Date: Thu, 31 Dec 2020 15:50:33 +0000 From: "Alexey Melnikov" To: "John C Klensin" , emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Ticket #2: Repeated Use of EHLO X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 15:50:57 -0000 Hi John, On Thu, Dec 17, 2020, at 3:52 AM, John C Klensin wrote: > Hi. > > In late October, before the discussion of repeated use of EHLO > forked into several discussions that there seems to be agreement > were not properly part of rfc5321bis, I suggested that we fix > the text to simply clarify the relationships between EHLO and > RSET and mail transactions and those between a new EHLO command > and its predecessor. I tentatively made the changes but never > circulated them to the WG list. The working version of what > will become draft-ietf-emailcore-rfc5321bis-01 now contains: > > (1) A new second paragraph in Section 3.3 that reads: > > Mail transactions are also terminated by the RSET command > (Section 4.1.1.5), the sending of an EHLO command (Section > 3.2), or > the sending of a QUIT command (Section 3.8) which terminates > both any > active mail transaction and the SMTP connection. > > And, in addition, (2) the third paragraph of Section 4.1.4 has > been extended to read: > > "An EHLO command MAY be issued by a client later in the > session. If it is issued after the session begins and the > EHLO command is acceptable to the SMTP server, the SMTP > server MUST clear all buffers and reset the state exactly > as if a RSET command had been issued (specifically, it > terminates any mail transaction that was in progress, see > Section 3.3). In other words, the sequence of RSET followed > immediately by EHLO is redundant, but not harmful other > than in the performance cost of executing unnecessary > commands. However the response to an additional EHLO > command MAY be different from that from prior ones; the > client MUST rely only on the responses from the most recent > EHLO command." > > With those changes, the situation should be very clear and > consistent with the intention of the text coming out of DRUMS > and YAM. Yes, these changes look good to me and I will close this ticket now. Best Regards, Alexey From nobody Thu Dec 31 07:55:36 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9237B3A0D64 for ; Thu, 31 Dec 2020 07:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=d12PXyH1; dkim=pass (2048-bit key) header.d=taugh.com header.b=ggmyBgdv Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLjBtxoy1wPk for ; Thu, 31 Dec 2020 07:55:33 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96A23A0D5D for ; Thu, 31 Dec 2020 07:55:32 -0800 (PST) Received: (qmail 10281 invoked from network); 31 Dec 2020 15:55:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type; s=2825.5fedf473.k2012; i=johnl-iecc.com@submit.iecc.com; bh=jfrhmQphhZKDs2ZskCBd4PKU2PxOkWZTF6G0r9tdJKc=; b=d12PXyH1+pePO5uU1xSGZV1LV6vWoz/zCVa4EjDvnSXKXWCqyV2por7WAljsu747NR0S6aahBP0iWq8faVdBoeaH5KCFLF2z0bmz/i2jxPBQLn1gw202EA39aGgxL3llD3V+Q8OvzUKqHxx5rbqurNDyPEfb791/Oby4g2SMQ+2uiEVJId7KX2pgGBVNPHF0Rvbh8NzzaUTyD2r/6PoeSP+o2QpvaxSsCNlwCPdWKWPpFC25EV7Pvi8cNu86rZan88ZBR8WYgP68If7ykJWW2U7OGVbVQ21DNglzbcG274pOJAMlbbGYpDATAOS0Z/Xqe1tJNgkrPD1ddt+vFlWu7w== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type; s=2825.5fedf473.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=jfrhmQphhZKDs2ZskCBd4PKU2PxOkWZTF6G0r9tdJKc=; b=ggmyBgdvimUWMQGmBnzZBkWG6praFvt26YPNo495M0v5WoSxHyUVZ3xuUQB5Fmsf2ZuWwCPWPsI1SG6xmSeX01O1bKgBjW7Uf8qpbkXZuv0BdCqYp6Nk62JCMwjV0mWxpdOagwsjIoz8kLVGPPZcaHsM2/bJHQkk+do4a1n3vn5gftbGMXrpc77MjomqXsUW5LPiLYt0YkEsdXw664AbQXmtRpVI4pmL/3lJw8bxAlWh4DV4o9hht6OSvyP8l6awAtr5drGoNkjROn3qLorH4QSKwhdwKgddbi41rcjl6gwakfz5FpmWwcn7cpXz/8QQ68sNTEcBHYeBm5CpRO3dUg== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 31 Dec 2020 15:55:31 -0000 Date: 31 Dec 2020 10:55:31 -0500 Message-ID: From: "John R Levine" To: emailcore@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: [Emailcore] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 15:55:35 -0000 RFC5321 says that when a message is delivered the envelope MAIL FROM address goes into a Return-Path header, but says nothing about the RCPT TO address. Many MTAs put that in a Delivered-To header and have done so for a long time. I know that Postfix and qmail do. It shows up in examples in RFCs 5293 and 7681. I think this is sufficiently established that we can add it to 5321bis. We could say that the delivery SMTP server SHOULD insert a Delivered-To line when it inserts a Return-Path line, and SHOULD NOT remove existing Delivered-To lines. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Dec 31 08:03:33 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9603A0D6F for ; Thu, 31 Dec 2020 08:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlbLYm246Hr0 for ; Thu, 31 Dec 2020 08:03:29 -0800 (PST) Received: from mail-ob3.cityemail.com (mail-ob3.cityemail.com [104.128.152.20]) by ietfa.amsl.com (Postfix) with ESMTP id DBBF13A0D45 for ; Thu, 31 Dec 2020 08:03:29 -0800 (PST) Received: (qmail 4034 invoked from network); 31 Dec 2020 16:03:29 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe3.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (b91157b0-4b81-11eb-821e-1fddda61ae50); Thu, 31 Dec 2020 08:03:29 -0800 To: emailcore@ietf.org References: From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <57c8838f-e8fe-abdb-f86c-029655319921@linuxmagic.com> Date: Thu, 31 Dec 2020 08:03:29 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: b91157b0-4b81-11eb-821e-1fddda61ae50 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] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 16:03:31 -0000 On 2020-12-31 7:55 a.m., John R Levine wrote: > RFC5321 says that when a message is delivered the envelope MAIL FROM > address goes into a Return-Path header, but says nothing about the RCPT > TO address.  Many MTAs put that in a Delivered-To header and have done > so for a long time.  I know that Postfix and qmail do.  It shows up in > examples in RFCs 5293 and 7681. > > I think this is sufficiently established that we can add it to 5321bis. > We could say that the delivery SMTP server SHOULD insert a Delivered-To > line when it inserts a Return-Path line, and SHOULD NOT remove existing > Delivered-To lines. This one may not be a simple as that. Delivered-To gets populated sometimes enroute to it's final distination, eg when local forwarding rules or email processors operate on the message before it's final destination. You could have multiple Delivered To in those cases. The business rules and logic on WHEN a MAIL FROM gets put into a Return-Path is/could be different than the logic for placing a Delivered-To ... Speaking of which, more emphasis should be placed on servers NOT forwarding emails with a Return-Path in place, it was only meant to be placed at the final destination.. or at least, if you are going to make the decision late that you are not the final destination, remember to strip the Return-Path that your systems added before redirecting.. -- "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 Thu Dec 31 08:08:42 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F21D3A0D73 for ; Thu, 31 Dec 2020 08:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=qdGIcO/p; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oQ2Nx9Fl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0x3OkxsIaj5 for ; Thu, 31 Dec 2020 08:08:39 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 309B33A0D71 for ; Thu, 31 Dec 2020 08:08:39 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7492E5C0129; Thu, 31 Dec 2020 11:08:38 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Thu, 31 Dec 2020 11:08:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=KJA1z 4KW2+1atKVWia1XpRik/iVRKDIIj77GmmpC82U=; b=qdGIcO/poMlLA34cGH8xQ UuVx1RWhswG0p3YNghvzjv+3cw1F2Rry8sEo3Zdk26bv6+bfFvjEIvqMX5LdE7jG Egozj3fBRxZhGj1ZUEUuAXRkxYvLE5tSZtQQpX05N3Puq5RjYoibwOR02sp8ZQ11 QyZuSqV4vjtcaK5/0D8gZI3Y2Q7BZt2EcAtD0bbR6HNvPykQ3ySoD3WtuwsBYGe/ ZlxGGJG3Y9XVS/aW2pygxaQWavyvO1wlTnwKAZKB687tCH8rx2JwQp4DJ+37+Rui ulsiobQ03B4Phcl3Loc8al1aWMYvXCYcnIqcidNpFfUercLBYN3cpuwz9LiRTc6T g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=KJA1z4KW2+1atKVWia1XpRik/iVRKDIIj77GmmpC8 2U=; b=oQ2Nx9Fl4WRqu1s45Qs+Gn4iJ/kY6lStNNBlAEwZedyU4JkrlzHNBMwG5 Dbjs+SN+ngj8YMSE68EUGdUSLHllUMQZwaM0TDHjhXhXPRVPqBMACObPrn/NDMxl izetpQM1OA28cmAG9XNz2FhxEOj43uKY07vkB5WWgOsKBMCcQumRkP+66zH3QC0j fLcPs3rDD+VxucIPBKkAc826DUvxuFzfJGURBGrj2DMTacnOLU5+ZWflL/ga3S0Q eEPGnuscOwbEZf/0toBU68VMPOLACnnDrpkcMx9Vw3RZzSsMrbcvOqCTmViAIdw0 e5MM5MWQpFJXPcIbB34jT/Ot9dqng== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddvhedgkeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedftehl vgigvgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhmqeenucggtffrrghtthgvrhhnpeelieffleeuueefkeeljeefieehgeejtddvtddu ffeufeevveeftdefkeeuudevffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 80FFC6F601CC; Thu, 31 Dec 2020 11:07:51 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: <59447e97-5446-401b-8b40-e0d09118acb2@www.fastmail.com> In-Reply-To: References: Date: Thu, 31 Dec 2020 16:08:18 +0000 From: "Alexey Melnikov" To: =?UTF-8?Q?Julien_=C3=89LIE?= , emailcore@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] =?utf-8?q?Ticket_=2328=3A_Erratum_1851=3A_Location_o?= =?utf-8?q?f_text_about_TCP_connection_has_closure/reset?= X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 16:08:41 -0000 Hi Julien, On Sat, Dec 26, 2020, at 9:56 AM, Julien =C3=89LIE wrote: > Hi all, >=20 > > SMTP clients that experience a connection close, reset, or other= > > communications failure due to circumstances not under their cont= rol > > (in violation of the intent of this specification but sometimes > > unavoidable) SHOULD, to maintain the robustness of the mail syst= em, > > treat the mail transaction as if a 421 response had been receive= d and > > act accordingly. > >=20 > > So I think the text mentioned in the erratum should be moved after t= he last paragraph of Section 3.8. > >=20 > > Please provide feedback on this strwman proposal. In absence of feed= back, this issue will be resolved as proposed above. >=20 > A bit earlier in the same Section 3.8, we have: >=20 > o After detecting the need to shut down the SMTP service and > returning a 421 reply code. This reply code can be issued afte= r > the server receives any command or, if necessary, asynchronousl= y > from command receipt (on the assumption that the client will > receive it after the next command is issued). >=20 > I'm wondering whether the part in parenthesis really occurs in practic= e,=20 > notably when the closure is asynchronous from command receipt. Maybe = it=20 > should be reworded this way: "on the assumption that the client will=20= > receive it after the next command is issued or read it before closing=20= > the connection at its side"? I think we should open a separate ticket on this. > Another suggestion for the new paragraph: >=20 > SMTP clients that experience a connection close, reset, or other > communications failure due to circumstances not under their contro= l > (in violation of the intent of this specification but sometimes > unavoidable) SHOULD, to maintain the robustness of the mail system= , > + try to read a possible asynchronous reply from the SMTP server, and= > + otherwise > treat the mail transaction as if a 421 response had been received = and > act accordingly. Personally I am fine with this addition. > Naturally, if you think it makes sense. Just opening the discussion. Best Regards, Alexey From nobody Thu Dec 31 08:09:07 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD953A0D71 for ; Thu, 31 Dec 2020 08:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=riHhLUxA; dkim=pass (2048-bit key) header.d=wizmail.org header.b=hvk5VcLV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFCR8xK215Um for ; Thu, 31 Dec 2020 08:09:03 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735643A0D73 for ; Thu, 31 Dec 2020 08:09:02 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=lt80jfz5rMt023lYukuc0cQcncx1q9vLikbT8k/2//4=; b=riHhLUxAGeevveUHGBazEN95aS bXO2/eFNu5rYm/OxYW0hRGMqv9GGy98PKwDxesKsAiTMUOVCdloudhp1IlAw==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=lt80jfz5rMt023lYukuc0cQcncx1q9vLikbT8k/2//4=; b=hvk5VcLVk7BTSallOi5FPhLHPz fNyxauwJlHHQsVVrzeHKOqsLfqhC07VsGnpVoyauXirk/yJVIcsS3rukH/ImM6OaXPcR0taXLAUsB JNUC7qCwQyID1p8rOeOC5ECkS3K2UiKALXNaOKFvpE46/tJNXD/OiP0VBMQpx5PWCjdsxRjUAeiPc Kz33m7v4GqdcoX8fF/FULoeRj0ofzfK4dUnRPyeUvHQY/hNUU2h0qlEvMAIlId3fOrgPKceQAENkp 20EcLL1JaTHR5lToT69qNo3pqNdf6M8r4w583kCNVYkKFWfXK/U8k373fwRgstdlZvPhqPb1V3Lzs O0WASEdw==; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=46.33.133.68; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [46.33.133.68] (helo=lap.dom.ain) (from_AS 51561) by wizmail.org (Exim 4.94.110) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1kv0VW-007i6t-QZ for emailcore@ietf.org (return-path ); Thu, 31 Dec 2020 16:08:58 +0000 To: emailcore@ietf.org References: From: Jeremy Harris Message-ID: <53f54c70-889b-9a55-6829-340069fbe37e@wizmail.org> Date: Thu, 31 Dec 2020 16:08:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Emailcore] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 16:09:05 -0000 On 31/12/2020 15:55, John R Levine wrote: > RFC5321 says that when a message is delivered the envelope MAIL FROM address goes into a Return-Path header, but says nothing about the RCPT TO address.  Many MTAs put that in a Delivered-To header and have done so for a long time.  I know that Postfix and qmail do.  It shows up in examples in RFCs 5293 and 7681. > > I think this is sufficiently established that we can add it to 5321bis. We could say that the delivery SMTP server SHOULD insert a Delivered-To line Just because some (and not all) MTAs do? Better justification needed, I think. -- Cheers, Jeremy From nobody Thu Dec 31 08:13:07 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990933A08D6 for ; Thu, 31 Dec 2020 08:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=spodhuis.org header.b=CBLo3GNz; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=spodhuis.org header.b=Zok7c1oa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Mi2CrjaEQYJ for ; Thu, 31 Dec 2020 08:13:04 -0800 (PST) Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2a02:898:31:0:48:4558:736d:7470]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4173A0D71 for ; Thu, 31 Dec 2020 08:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d202011; h=OpenPGP:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:To:From:Date:From:Reply-To:Subject:Date:To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:OpenPGP:Organization ; bh=cCwy71n6Zm4yv2M1EMwqRGnkxuCsRNiGxW/RG2P8p0I=; t=1609431184; x=1610640784 ; b=CBLo3GNzakyPJ2Y5JkzejvFLs29IvBLIWOo/1UiG3HuzwrgsF2kcs1w+fjdzTGabm9KgkOWPD ZxQAyq6Zg5x20Np2JII+XFn+hi24cH2sUTSkMzg22EZrruHD0xcc32KSSAGq+q0yxsgpFooS9mjv2 wS0zUpvohbfpBYCE+jZrlKqGRl34CrnN+JFCOK81tquBA7OSJQ3elL5b4qlMfnIMccfCXYLkqY92T 5y62paX6esM1KCnr43Tvr5Q9mFZ9xe2Ym0Rfz0bd+8P9ifQtg2QXTyDVhyNz6mJYuQbRLeodCgGIc Fk6boqc6ztSbmzfsh8yIPhZkCGGUaHVkCqnozg==; DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d202011e2; h=OpenPGP:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:To:From:Date:From:Reply-To:Subject:Date:To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:OpenPGP:Organization ; bh=cCwy71n6Zm4yv2M1EMwqRGnkxuCsRNiGxW/RG2P8p0I=; t=1609431184; x=1610640784 ; b=Zok7c1oaZC/GWuuDwevQxYdKM8bQEzCLCqNhnuOZQ9cR0hNmOjrgUlctF9JUOtUz02F/YkUwe E2oXvI54DGpCQ==; Received: from authenticated user by smtp.spodhuis.org with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) id 1kv0ZR-000Du1-PB; Thu, 31 Dec 2020 16:13:02 +0000 Date: Thu, 31 Dec 2020 11:12:58 -0500 From: Phil Pennock To: emailcore@ietf.org Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: OpenPGP: url=https://www.security.spodhuis.org/PGP/keys/keys-2013rsa-2020cv25519.asc Archived-At: Subject: Re: [Emailcore] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 16:13:07 -0000 On 2020-12-31 at 10:55 -0500, John R Levine wrote: > RFC5321 says that when a message is delivered the envelope MAIL FROM address > goes into a Return-Path header, but says nothing about the RCPT TO address. > Many MTAs put that in a Delivered-To header and have done so for a long > time. I know that Postfix and qmail do. It shows up in examples in RFCs > 5293 and 7681. > > I think this is sufficiently established that we can add it to 5321bis. We > could say that the delivery SMTP server SHOULD insert a Delivered-To line > when it inserts a Return-Path line, and SHOULD NOT remove existing > Delivered-To lines. Exim spells this "Envelope-to:" and it's not enabled by default in the code but the sample configurations set it by default for delivery to files. By contrast, the `envelope_to_remove` option defaults to true, so that if this header is seen then folks can have confidence it's local. My initial gut reaction (therefore wrong) is that how mail is stored locally is out-of-scope for the specification of SMTP and how mail is transferred between systems. Against that, a common pattern of what behavior folks can count on would make sense for ensuring data can gateway _back_ to SMTP cleanly. Yet with some mailbox formats perhaps better suited to this flow, this is persisted outside of the main headers and restored cleanly without header parsing. What's the rationale for leaving alone the existing Delivered-To: headers? Is this a Trace header which must always be prepended, so folks should always use the first one seen scanning from the top? -Phil From nobody Thu Dec 31 08:15:06 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55063A0D73 for ; Thu, 31 Dec 2020 08:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=DSTdBVH8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=niaxcE/1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0JIpOvQoKoQ for ; Thu, 31 Dec 2020 08:15:02 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058C43A0D71 for ; Thu, 31 Dec 2020 08:15:01 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4F9795C0164 for ; Thu, 31 Dec 2020 11:15:01 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Thu, 31 Dec 2020 11:15:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=cbcxBk4OisXk0LpRh/DYWthck89aniH GZHmRFLZnp3s=; b=DSTdBVH8o3N2rFzpU+SYV6yyqGACpwmUg+ISV1fQPsoAutf cELxl6NZB8KyxTFPqqcHZbrw3cBpc9C2TehBJhae8yGxcKRB+9IK+gXTRRGB2LU1 KHaqvHWpJWqOOvdVJ+ScQgQBO82HbobVJAS0fAbjbhSKwRzRPZxx6zrUxHKB33Di 7oeQOQwWh53VIbJNTbznGR/jSQ+46mRDuq7sH53NS9iNpE1A2wGNoWbGzqs+J8NW QvoQ6trTaHnvbmTLvGPQSc8Cl2Z5OOBpWPIMerD7D5MWFzZIn36ljwTcXB4J9fHC L3hUOdzXyvLc/FtFYXDvzCwqmcFK2NiQl2Q4aUQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=cbcxBk 4OisXk0LpRh/DYWthck89aniHGZHmRFLZnp3s=; b=niaxcE/1zXl6o5Sj55YlH/ uR58/E3WVeajOY8sY1aJqfYck+bPhm1051CxWKtmsUpAuIA0GdrE3jTxdfHeDSkX sNMLX0GqxaIsS84Bp2/JXPkgUapUVy6txq2KjiEj0r4Si0oYIKRgMitBDlMMbZmZ eEKzx550MV1QO/JDeLEdRMUg6x/Glv0WbH96zK0rDkhsfzCVK8A2pRChXuhh/46z 9YNZEho5cQmI/Jdggq76AYfkEgUBRnsXSgXyxXYJHY0dHtLxnaQ/abFvNPVw3hm9 mCJj7NgnLHuX/8m/lRFdS8fl7DI1g/21cuFDMlm4h4NW+E5k0pgCBYC7mD8B9zAQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddvhedgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedftehlvgigvgihucfovghlnhhikhhovhdfuceorggrmhgv lhhnihhkohhvsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtthgvrhhnpeelffdtgf fhveeuudeihfffjeelgfdtudfhvdettdehfeettdfhgefhfeeigfegffenucffohhmrghi nhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5210B6F601D0; Thu, 31 Dec 2020 11:14:14 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: <128d48b0-1464-4a8c-a8d8-7899a2c5e7a8@www.fastmail.com> In-Reply-To: References: Date: Thu, 31 Dec 2020 16:14:38 +0000 From: "Alexey Melnikov" To: emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 16:15:04 -0000 On Thu, Dec 31, 2020, at 3:55 PM, John R Levine wrote: > RFC5321 says that when a message is delivered the envelope MAIL FROM > address goes into a Return-Path header, but says nothing about the RCPT TO > address. Many MTAs put that in a Delivered-To header and have done so for > a long time. I know that Postfix and qmail do. It shows up in examples > in RFCs 5293 and 7681. > > I think this is sufficiently established that we can add it to 5321bis. > We could say that the delivery SMTP server SHOULD insert a Delivered-To > line when it inserts a Return-Path line, and SHOULD NOT remove existing > Delivered-To lines. https://trac.ietf.org/trac/emailcore/ticket/44 From nobody Thu Dec 31 08:17:09 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321223A0D76 for ; Thu, 31 Dec 2020 08:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=UdyKY4rm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cm2ESUpw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 151A_bNm5jB3 for ; Thu, 31 Dec 2020 08:17:07 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 187F43A0D75 for ; Thu, 31 Dec 2020 08:17:07 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2CBFA5C017E for ; Thu, 31 Dec 2020 11:17:06 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Thu, 31 Dec 2020 11:17:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=IIU70 MmtfY6XAbAyRZ88G5DO8/kbnrS+oXXKqxAK0oA=; b=UdyKY4rmPl7aTSdyf+kfx Hjb2RsHXL6EQkM2jOzGT7MJHFef75krE/sJafGu9csgjp1jxOQUxv04lIhzx6aXY d/KJtA4KydkIzCntcD9wM6+O+aIlQHMdBTtfuaopR/GleE65OzpVD2/nWSA5T7nT zjeuIgOVdASvKKkZoKifMsIA+JN3XZJ1k5rEiedF+SWyaBBkimQxM8SH8se4BSk2 M3uYA4LH1B+TMhuCaVvQP0LpN2YAdfq91nq8QPCaExfIpYAF5k/JIUSY7JBZG+if t+MRpK1SSQ8ZZSwyy/pnbjLlokBlsmCYEvkqs277u1iXG1cOFupHmS3+eMh2DQ5F A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=IIU70MmtfY6XAbAyRZ88G5DO8/kbnrS+oXXKqxAK0 oA=; b=cm2ESUpwIFhKLqfDDZl3U6/Gm9SRFGAIDCidG7FaiOMyGkRNldTC9C4MY E7fazXPa/T6z6LGF3QgDIimJhPbGq6Z4tyg6kMy3aonh45CoRHIaulv/QEJCSHsW MkReiY6XSMJDIbH98d1h+wxTepn30udLKlI4Ks+uByKNM2DEeWKmSJu22rHjwxw3 bbmNNzXMWJqD1mIyxryOMTB2ZmBoElDgvIAKNY/XRJN5B2cQyuWZNFBvYuM3ohps Z+KuvjQSfV/ZRC2vGBP5CBkWcXRWB5F1v98vt/Gd4d/mKYHqm0SFlTSac7gecQ8V OjRsDEXsbIkWTpHuP/O72FablNwNA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddvhedgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdetlhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghm vghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghrnhepleeiff elueeufeekleejfeeiheegjedtvddtudffueefveevfedtfeekueduveffnecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkoh hvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0FEDA6F601D2; Thu, 31 Dec 2020 11:16:19 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: <9e62a274-59ed-4594-89c3-3807c10fb9c7@www.fastmail.com> In-Reply-To: <53f54c70-889b-9a55-6829-340069fbe37e@wizmail.org> References: <53f54c70-889b-9a55-6829-340069fbe37e@wizmail.org> Date: Thu, 31 Dec 2020 16:16:44 +0000 From: "Alexey Melnikov" To: emailcore@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 16:17:08 -0000 On Thu, Dec 31, 2020, at 4:08 PM, Jeremy Harris wrote: > On 31/12/2020 15:55, John R Levine wrote: > > RFC5321 says that when a message is delivered the envelope MAIL FROM= address goes into a Return-Path header, but says nothing about the RCPT= TO address.=C2=A0 Many MTAs put that in a Delivered-To header and have = done so for a long time.=C2=A0 I know that Postfix and qmail do.=C2=A0 I= t shows up in examples in RFCs 5293 and 7681. > >=20 > > I think this is sufficiently established that we can add it to 5321b= is. We could say that the delivery SMTP server SHOULD insert a Delivered= -To line >=20 > Just because some (and not all) MTAs do? > Better justification needed, I think. Speaking as a participant: I think SHOULD allows implementations not to = add it, so the proposed text seems to be fine as is. From nobody Thu Dec 31 08:19:16 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84823A0D76 for ; Thu, 31 Dec 2020 08:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eAcJ3jjVdCi for ; Thu, 31 Dec 2020 08:19:13 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63623A0CEE for ; Thu, 31 Dec 2020 08:19:13 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kv0fQ-000DZs-HI; Thu, 31 Dec 2020 11:19:12 -0500 Date: Thu, 31 Dec 2020 11:19:07 -0500 From: John C Klensin To: John R Levine , emailcore@ietf.org Message-ID: <9732DDE6FFFBAF7276838AF8@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] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 16:19:15 -0000 --On Thursday, December 31, 2020 10:55 -0500 John R Levine wrote: > RFC5321 says that when a message is delivered the envelope > MAIL FROM address goes into a Return-Path header, but says > nothing about the RCPT TO address. Many MTAs put that in a > Delivered-To header and have done so for a long time. I know > that Postfix and qmail do. It shows up in examples in RFCs > 5293 and 7681. > > I think this is sufficiently established that we can add it to > 5321bis. We could say that the delivery SMTP server SHOULD > insert a Delivered-To line when it inserts a Return-Path line, > and SHOULD NOT remove existing Delivered-To lines. If we take the rules seriously, the moment you do that, existing implementations that don't do that become nonconforming and rfc5321bis goes to Proposed. Alternate suggestion: Make sure it the header field is registered in the appropriate registry (I'm fairly sure it is but don't have time to go check today). Then make this a strong recommendation in the A/S. john From nobody Thu Dec 31 08:32:52 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F26B3A0D9A for ; Thu, 31 Dec 2020 08:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=VWGkvlx0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Wr28ZDGk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veX9qfIhos0u for ; Thu, 31 Dec 2020 08:32:49 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8681F3A0D98 for ; Thu, 31 Dec 2020 08:32:49 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 165155C018F; Thu, 31 Dec 2020 11:32:48 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Thu, 31 Dec 2020 11:32:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=QGB4WfnJlx26/7qBzUnFg8ZUN6FFWwC bc6SefPMQklQ=; b=VWGkvlx0I7lclv0RVprhX4NUlnNwwDSY27fJX0Y/JspSF13 +F3mPBi34tD/CenL9mzBkG2chQ0415/XL4UECbS5RIev66p96g9kdwqhMuzF07mm vCz3h3eSf+1iySjI68B9hfCud0u9cqRvRrZRmw6X1iju/BO+6lA4X1+3Mgwy1M0m lnEsrHPbtGtzm0IL9ED6AT6ufkqyO2zK5LrXg5+zi0NbKXjx75VboWtYIW+THuQM SZ5QyyZoqbQo3Mk7QvCiB7HZelqA9GT0uaQKOkKwybU9Kw9dDxAagO2mxpUCG2b1 zXlyyYiitJ3n9lJVWcLc/+C8eXsdXpjO7IOoCKA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=QGB4Wf nJlx26/7qBzUnFg8ZUN6FFWwCbc6SefPMQklQ=; b=Wr28ZDGkXW8MfOjJEczRuW HQBFMOpQ1PfUxyLrNAVXgm7U+8ixO4dS5t+GeqG74vrDTBopcn7Ig5yoG3SVLZnV uVr5QnJRTiXg19gY0AZqShAJfTTMRE3irYJJIZRgUBw6Zvh225JFQPpO9TuxCbOy ZU/ZiO7Sqc1ZV/iJWa/8zCl3TKg77sbSCUeaVKqW/cN/31nakpAllb7ADVU67ROA 2UUlei2jqBPXG0dgbrL3Teh1KasKlKhaixgzWRsUQZFMtC3+VDjDQjoPacIteDLZ cYTc/mZzt6XuB/HAdeFTi1gxFMRePdrQZMvcg/9vji271JkcnFYaHA+n7IrzZMIQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddvhedgkeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuggftrfgrthhtvghrnheplefftdfghfevueduiefhffejlefgtdduhfdvtedt heeftedthfeghfefiefggeffnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhho vhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DB9546F601D0; Thu, 31 Dec 2020 11:32:00 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: <520b541d-e34d-43b0-8ad7-d844dbf7c024@www.fastmail.com> In-Reply-To: <101f868f-b277-2ff3-56dc-44f721dc2f78@tana.it> References: <101f868f-b277-2ff3-56dc-44f721dc2f78@tana.it> Date: Thu, 31 Dec 2020 16:32:27 +0000 From: "Alexey Melnikov" To: "Alessandro Vesely" , emailcore@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Emailcore] Spurious gatewaying reference X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 16:32:51 -0000 On Thu, Dec 31, 2020, at 2:45 PM, Alessandro Vesely wrote: > Hi, > > Section 4.5.5 starts with the paragraph: > > There are several types of notification messages that are required by > existing and proposed Standards to be sent with a null reverse-path, > namely non-delivery notifications as discussed in Section 3.7, other > kinds of Delivery Status Notifications (DSNs, RFC 3461 [33]), and > Message Disposition Notifications (MDNs, RFC 3798 [37]). All of > > > Now, Section 3.7 is "Mail Gatewaying". What is it referenced for here? I read 3.7 and 4.5.5 and I agree that referencing 3.7 seems odd. New ticket: > Perhaps, the paragraph should refer to Section 3.6.3, "Message Submission > Servers as Relays", which discusses non-delivery notifications. From nobody Thu Dec 31 08:33:32 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9453A0D9A for ; Thu, 31 Dec 2020 08:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzY5hYT3x2l1 for ; Thu, 31 Dec 2020 08:33:29 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938F03A0D98 for ; Thu, 31 Dec 2020 08:33:29 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kv0tE-000Del-CC; Thu, 31 Dec 2020 11:33:28 -0500 Date: Thu, 31 Dec 2020 11:33:22 -0500 From: John C Klensin To: Alexey Melnikov , emailcore@ietf.org Message-ID: <4B8AAB6A791D30475D970482@PSB> In-Reply-To: <9e62a274-59ed-4594-89c3-3807c10fb9c7@www.fastmail.com> References: <53f54c70-889b-9a55-6829-340069fbe37e@wizmail.org> <9e62a274-59ed-4594-89c3-3807c10fb9c7@www.fastmail.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] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 16:33:31 -0000 --On Thursday, December 31, 2020 16:16 +0000 Alexey Melnikov wrote: > On Thu, Dec 31, 2020, at 4:08 PM, Jeremy Harris wrote: >> On 31/12/2020 15:55, John R Levine wrote: >> > RFC5321 says that when a message is delivered the envelope >> > MAIL FROM address goes into a Return-Path header, but says >> > nothing about the RCPT TO address.=C2=A0 Many MTAs put that = in >> > a Delivered-To header and have done so for a long = time.=C2=A0 I >> > know that Postfix and qmail do.=C2=A0 It shows up in = examples >> > in RFCs 5293 and 7681. >> >=20 >> > I think this is sufficiently established that we can add it >> > to 5321bis. We could say that the delivery SMTP server >> > SHOULD insert a Delivered-To line >>=20 >> Just because some (and not all) MTAs do? >> Better justification needed, I think. >=20 > Speaking as a participant: I think SHOULD allows > implementations not to add it, so the proposed text seems to > be fine as is. Please reread 2119. SHOULD implies that an implementation needs a reason to not add it (and to not spell it that way) and that the reason should be better than "didn't feel like it" or "have been doing something similar for decades and my users don't like changes to fields to which they have become accustomed". If adding it were discretionary with the implementation, that is spelled "MAY" followed by some encouragement. =20 Unless there is a strong, substantive, reason for doing this, as Jeremy put it, "Just because some (and not all) MTAs do" is not sufficient justification for adding a new requirement to 5321bis, especially since there is no way to guarantee that no one will object to moving the resulting document to Internet Standard because it _is_ a new requirement and convince enough of the IESG to tie this effort in knots. IMO, the only justifications for new requirements in 5321bis or 5322bis (and taking that risk) are to recognize something that _substantially all_ implementations are doing already and doing in the same way or to specify the (already extensively tested) remedy for major security or other issue that has shown up in many places in the wild and demonstrated to have been a significant problems. john From nobody Thu Dec 31 08:45:02 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FDC3A09E8 for ; Thu, 31 Dec 2020 08:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lZpChsFa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=a67+FqrC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAXKtfkabdcr for ; Thu, 31 Dec 2020 08:44:59 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0CAE3A09B7 for ; Thu, 31 Dec 2020 08:44:59 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E9F4B5C01CA; Thu, 31 Dec 2020 11:44:58 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Thu, 31 Dec 2020 11:44:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=TgjtB e6ffWGFEc0kE2cgjZAjwcvDJ+/n/mbaY2IxQ9E=; b=lZpChsFa+i00fEGJoMzJs rE49nPnCuMq1Ph6/SbDcSNL4U5mjvtqatj75inEpJdAozOk7Sr6B2Kz2wm+p59xl SaJQDNjrpjLB7LGJoemwRkfzytgQez+PwUjjULpyEJgQt0XAVlAEVWlht7nrWJxv 8s6F2X0a1NbpdHT2Nqbk5EDzZAdyYb4D+eTPhUI8RMPrntlkKyVIsBrJFjYIZ1uy lutv0aj4HDD6En0m42yzi4qqP4woNhGukLveKuhJutZeUFoYan/L6vA2n8iaO7uz 6Gn7gbPCwG9PLnnqxuUXQo3ZgYeYcL6/YhtwzPfBqcs6U4q5yhUxHHiDhAy8PqwU Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=TgjtBe6ffWGFEc0kE2cgjZAjwcvDJ+/n/mbaY2IxQ 9E=; b=a67+FqrC/3V6+DszDd+KuVHx5jmccS88qrUAQf+yDom6bQToWBGH56ZyE 7XT+V2ysRwd/xrqZcFGse49CaB0hzXcRowLbnElGdVqz7TivJAcqYPfoCqR2RDcH eHf1sbSSeK+GdNVauevpTCkoDfQWz9y3c4tQdKHr4gZ58eHFXqK7ZGRtTK/sea50 pyiD+T/iwgP0yPOvplKOsjiY4y+dRQqDt8A262bd2bkdO5CddC43h7FL0Oleu5MA qaO7eQvZs5RsZvDEuSyL3JRgLNL+eKmr0DlnwW5BKKFMbZ5ecaf/eq8v3ycErzpw UNBkyLlL8yS//xcoUrMBMs2SaANnA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddvhedgleefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdetlhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghm vghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghrnhepleeiff elueeufeekleejfeeiheegjedtvddtudffueefveevfedtfeekueduveffnecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkoh hvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F029E6F601D0; Thu, 31 Dec 2020 11:44:11 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: In-Reply-To: <4B8AAB6A791D30475D970482@PSB> References: <53f54c70-889b-9a55-6829-340069fbe37e@wizmail.org> <9e62a274-59ed-4594-89c3-3807c10fb9c7@www.fastmail.com> <4B8AAB6A791D30475D970482@PSB> Date: Thu, 31 Dec 2020 16:44:18 +0000 From: "Alexey Melnikov" To: "John C Klensin" , emailcore@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Emailcore] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 16:45:01 -0000 Hi John, On Thu, Dec 31, 2020, at 4:33 PM, John C Klensin wrote: >=20 > --On Thursday, December 31, 2020 16:16 +0000 Alexey Melnikov > wrote: >=20 > > On Thu, Dec 31, 2020, at 4:08 PM, Jeremy Harris wrote: > >> On 31/12/2020 15:55, John R Levine wrote: > >> > RFC5321 says that when a message is delivered the envelope > >> > MAIL FROM address goes into a Return-Path header, but says > >> > nothing about the RCPT TO address.=C2=A0 Many MTAs put that in > >> > a Delivered-To header and have done so for a long time.=C2=A0 I > >> > know that Postfix and qmail do.=C2=A0 It shows up in examples > >> > in RFCs 5293 and 7681. > >> >=20 > >> > I think this is sufficiently established that we can add it > >> > to 5321bis. We could say that the delivery SMTP server > >> > SHOULD insert a Delivered-To line > >>=20 > >> Just because some (and not all) MTAs do? > >> Better justification needed, I think. > >=20 > > Speaking as a participant: I think SHOULD allows > > implementations not to add it, so the proposed text seems to > > be fine as is. >=20 > Please reread 2119. SHOULD implies that an implementation needs > a reason to not add it (and to not spell it that way) and that > the reason should be better than "didn't feel like it" or "have > been doing something similar for decades and my users don't like > changes to fields to which they have become accustomed". If > adding it were discretionary with the implementation, that is > spelled "MAY" followed by some encouragement. =20 Yes, you are right. I was being a bit of devil's advocate without being = explicit about that. I think I would like to see some quick discussion about: How widespread adding Delivered-To is? Are there any reasons (security or otherwise) for adding or not adding D= elivered-To. > Unless there is a strong, substantive, reason for doing this, as > Jeremy put it, "Just because some (and not all) MTAs do" is not > sufficient justification for adding a new requirement to > 5321bis, especially since there is no way to guarantee that no > one will object to moving the resulting document to Internet > Standard because it _is_ a new requirement and convince enough > of the IESG to tie this effort in knots. >=20 > IMO, the only justifications for new requirements in 5321bis or > 5322bis (and taking that risk) are to recognize something that > _substantially all_ implementations are doing already and doing > in the same way or to specify the (already extensively tested) > remedy for major security or other issue that has shown up in > many places in the wild and demonstrated to have been a > significant problems. From nobody Thu Dec 31 08:57:02 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701E83A0DCF for ; Thu, 31 Dec 2020 08:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNryFgsL9eTU for ; Thu, 31 Dec 2020 08:56:59 -0800 (PST) Received: from mail-ob1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id 42FC13A0DCC for ; Thu, 31 Dec 2020 08:56:58 -0800 (PST) Received: (qmail 6872 invoked from network); 31 Dec 2020 16:56:58 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (31f51b42-4b89-11eb-917d-ff93949c4808); Thu, 31 Dec 2020 08:56:58 -0800 To: emailcore@ietf.org References: <53f54c70-889b-9a55-6829-340069fbe37e@wizmail.org> <9e62a274-59ed-4594-89c3-3807c10fb9c7@www.fastmail.com> <4B8AAB6A791D30475D970482@PSB> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <79a0b645-e6c0-5192-a14b-5ebc1378945f@linuxmagic.com> Date: Thu, 31 Dec 2020 08:56:58 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-MagicMail-OS: Windows 7 or 8 X-MagicMail-UUID: 31f51b42-4b89-11eb-917d-ff93949c4808 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] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 16:57:00 -0000 On 2020-12-31 8:44 a.m., Alexey Melnikov wrote: > Yes, you are right. I was being a bit of devil's advocate without being explicit about that. > > I think I would like to see some quick discussion about: > > How widespread adding Delivered-To is? > > Are there any reasons (security or otherwise) for adding or not adding Delivered-To. Wide spread enough ;) All our platforms use it, and it is critically used for various aspects of email delivery. I also believe it is still in use in all Qmail based email platforms, among others.. Delivered-To is a trace header, it couple have multiple records, depending on how the email is processed internally at destination. And from a security aspect, only those headers that are inserted by a receiving mail system would be trusted. Normally, for instance those entries in the header above the last trusted Received line. There COULD be other ramifications.. you always get some people who throw up the 'privacy' ramifications, (the final recipient gets to see in interim destination) but usually that is important, and valid information to the recipient. (eg, the email WAS actually delivered to my mailbox, and came via a delivery route of a role address) A message COULD be injected into an IMAP mailbox, with forged Delivered-To headers of course, but the absence of that header is a distinct indication that the message did not transverse an expected delivery path. -- "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 Thu Dec 31 09:16:40 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429C83A0DEF for ; Thu, 31 Dec 2020 09:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Ii6HV0dO; dkim=pass (2048-bit key) header.d=taugh.com header.b=QgNNkeHQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ww7VO71LJJ1 for ; Thu, 31 Dec 2020 09:16:36 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC1E3A0DF4 for ; Thu, 31 Dec 2020 09:16:35 -0800 (PST) Received: (qmail 33110 invoked from network); 31 Dec 2020 17:16:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=8153.5fee0772.k2012; i=johnl-iecc.com@submit.iecc.com; bh=tTzJFYAgj+EmgEl6yHzJhruE1Fzsr/49NiUVJwHcU7Q=; b=Ii6HV0dO0r062zLxBJ5CrxRPMCn5raP0OmLUlU/fJTASr50qK1nNJxg9IPXPit5CtG0z8mbvAzFVJ29qQt29wqfZGFHOmHYWrT5QZlLkSOODLuH7+FMTcq75HcywTzxe0YN9IRLJgBHAJx37+jlsKXNxaSZKG263ni1KjDOK/VEZJE58NxWH8E/SCDz9hfmvEoLvfSmfRqk2KkvVTjgIMdEvus5fMCB06eVVUssPaJxYZE1mya/r2FgPIsyQ5eLZMOzPtdf1kYTkYPCyWSBbtAWbSKev3AxeGYse0fr5zqt8R/qdRF1t/qEyAL3kuXNf8jIc5EzDWtBO8AUDpqwcig== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=8153.5fee0772.k2012; olt=johnl-iecc.com@submit.iecc.com; bh=tTzJFYAgj+EmgEl6yHzJhruE1Fzsr/49NiUVJwHcU7Q=; b=QgNNkeHQvvFcgV3SAIxNtVDToN4EhGKo1GqoctlFi+kwozTCAw49uYvDlR1QDFOFJ8zy+6WC4jjPFt+fcjCsrtD5GSEbhLLt3LVN72L5O3ty2v7+GrwgR1yeCDP+Vdx54IaWhV1qCQJx5RdlA/wH84tyW8yFZXnbjwbvwiCqqo/gdHnxhWnaJZACDzJUR3bUaSUbhVGUdFMai5Fx0YQcnuTwT17dDb/dbCawVZHqpgWIstdI85msd9HOgHFH2ASMThPWxOYb1ZQBlYNmh5LfYC8wAmmd9dtNaLJ47pjZ/bOaD5ApF/dPnkKFnKQgy7H1h71cmFC0Bxw9aQzIt5mIjw== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 31 Dec 2020 17:16:34 -0000 Date: 31 Dec 2020 12:16:33 -0500 Message-ID: From: "John R Levine" To: "John C Klensin" , emailcore@ietf.org In-Reply-To: <9732DDE6FFFBAF7276838AF8@PSB> References: <9732DDE6FFFBAF7276838AF8@PSB> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 17:16:38 -0000 > If we take the rules seriously, the moment you do that, existing > implementations that don't do that become nonconforming and > rfc5321bis goes to Proposed. Hmmn. > Alternate suggestion: Make sure it the header field is > registered in the appropriate registry (I'm fairly sure it is > but don't have time to go check today). Then make this a > strong recommendation in the A/S. It's not registered, which surprised me and is why I'd like to put it in 5321bis. How about if we add it as a MAY ? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Dec 31 09:26:12 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FAB3A0DF7 for ; Thu, 31 Dec 2020 09:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=p3DSCLXR; dkim=pass (2048-bit key) header.d=taugh.com header.b=lsOxER3o Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXQhp8XwZOcd for ; Thu, 31 Dec 2020 09:26:09 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 733763A0DF6 for ; Thu, 31 Dec 2020 09:26:09 -0800 (PST) Received: (qmail 36153 invoked from network); 31 Dec 2020 17:26:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=8d37.5fee09b0.k2012; bh=M1nyxFUks4eWZJuZvfWC+QqU5SkZAgj3Q2tXbaa8Afo=; b=p3DSCLXRHFjTaa7Ep9EV51h7KiiDOXzJKuZFy5rtOQyBfwHOiGgy8lvaL6g+lQkOKR5dTMvVd3L3B3JmQTa1wLC4Onf7cwbh33dmK+sFEvO9Y8zBkQP+6OwSOnjHgSCiKojvobg25mPOp7+hkf4WWQzD7ExqO+PnNsRyEOryITfZ5UywFjJfFgQlhOvaYlj4sIlpeWxZqp6oZqsqSGvpvW0vSlBIshMHrlrbK0QcUWQiY8Ne3gDYI/LX+6RsgFVyf2T4HIF8dq6fpZU4aRpRa2l/6zLM0M2S0G+HjjPi7s8G3naSGInzzux3zJOT5RFs2+5W39Ug69fTtJ3XgPal/A== 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=8d37.5fee09b0.k2012; bh=M1nyxFUks4eWZJuZvfWC+QqU5SkZAgj3Q2tXbaa8Afo=; b=lsOxER3oQLcBGchqEHG1ut4IItN/rgF8wtPlhy0B2KbA251WwbsUysA28OaQOFfdevD8chx2D4uDN4Fk4IAGhT/rW1yqYRJHRKpU2RtylvkQzjrFMPahrgRDXubj85q3vVaendITPNzgAoo65DnF5ap2a6FfyJtnT9HDGeJsx7O3Zzles8pNl6jrcfMqwqEgj0pqeUUGcpYi867CFSnbXTVTs4ffTlNmXtbIwpo37U6GFbceOogboZwBozAJwsSpnAu/3mazYbBFelfEUPDGTa8s9UyzHe8LmjG+uJJtJZHrV/Q9wPloS6VTrxPOzA7VWQ3Ptuwoc4aaMs4Ce6O+HA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 31 Dec 2020 17:26:07 -0000 Received: by ary.qy (Postfix, from userid 501) id 8A8C23F00058; Thu, 31 Dec 2020 12:26:06 -0500 (EST) Date: 31 Dec 2020 12:26:06 -0500 Message-Id: <20201231172607.8A8C23F00058@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: ietf-emailcore-phil@spodhuis.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 17:26:11 -0000 In article you write: >My initial gut reaction (therefore wrong) is that how mail is stored >locally is out-of-scope for the specification of SMTP and how mail is >transferred between systems. That argument was over in 1981 when RFC 788 said to add Return-Path when mail is delivered. >What's the rationale for leaving alone the existing Delivered-To: >headers? Is this a Trace header which must always be prepended, so >folks should always use the first one seen scanning from the top? Yes. That's the existing practice. R's, John From nobody Thu Dec 31 09:52:29 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F963A0DFF for ; Thu, 31 Dec 2020 09:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pgZy5_5i6OU for ; Thu, 31 Dec 2020 09:52:27 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C50393A0DFE for ; Thu, 31 Dec 2020 09:52:26 -0800 (PST) Received: (qmail 45089 invoked from network); 31 Dec 2020 17:52:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=b01f.5fee0fd9.k2012; i=johnl-iecc.com@submit.iecc.com; bh=98naY/dE3jRPrcxw5nU0i+Ke0uPVqG173hY+1cvFXRI=; b=dnrJzRelXTiN7QwvFBYzxtcSWu64F5Uq16AUUOPRHiH37MikFY93VTLQ+r+83y9KD5oZLm4cUPO6Mvd/BTklSxYptfdnf15sSq6Da3xo4QTf4xA4SgCgSm8wF++dAqqFes6CDj2UlB8qPGSoqSQfdgiDlLixoGrGhZx9DTIum5K+gM04LVSBC0Ld5+nQ68xLx9kw0Fo/+bTfNeKXRRGzuma0y0LlFrItBTGiPnRE/uTVUHRCWgxQ1Q3/fuDKZ6NCWIG916VIMk6b30xNfpeQc9eDI5wRvaADvxoZkNh/K7F1KsGj/t94XU8VRHlJxT9bSk89lqTelva4nMUh8VMn8A== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 31 Dec 2020 17:52:25 -0000 Date: 31 Dec 2020 12:52:25 -0500 Message-ID: <9963648-bb55-88dd-e7ae-66afc5ac546@iecc.com> From: "John R. Levine" To: "Jeremy Harris" , emailcore@ietf.org In-Reply-To: <53f54c70-889b-9a55-6829-340069fbe37e@wizmail.org> References: <53f54c70-889b-9a55-6829-340069fbe37e@wizmail.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 17:52:28 -0000 >> I think this is sufficiently established that we can add it to 5321bis. We >> could say that the delivery SMTP server SHOULD insert a Delivered-To line > > Just because some (and not all) MTAs do? > Better justification needed, I think. Postfix and qmail add it, and have for decades. Gmail adds it. It's shown up in examples in RFCs. I think Exim is in the rough here. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Dec 31 10:12:18 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BBF3A0E1C for ; Thu, 31 Dec 2020 10:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBhof2rE618C for ; Thu, 31 Dec 2020 10:12:15 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58053A0E1B for ; Thu, 31 Dec 2020 10:12:14 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kv2Qn-000E6u-DC; Thu, 31 Dec 2020 13:12:13 -0500 Date: Thu, 31 Dec 2020 13:12:07 -0500 From: John C Klensin To: John R Levine , emailcore@ietf.org Message-ID: <61B05B4A19336FE3AA68E78B@PSB> In-Reply-To: References: <9732DDE6FFFBAF7276838AF8@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 18:12:16 -0000 John, Briefly as I have to run. If it isn't in the registry, probably adding it is a first step. Probably Envelope-to should be added to the header registry too, with appropriate notes about how the two might be the same or different. However, that relationship, the question of what to do if multiple copies of the field are present, potential privacy issues with intermediate deliveries, possible implications for SMTP-level forwarding or redistribution, and so on suggest that this is not going to be a trivial change to get right. Speaking both personally and as Editor and because we have so often found that everything is connected to everything else, I'm going to resist _any_ additional details or requirements (even MAY is normative language) in 5321bis absent compelling needed. But I will, of course, put in whatever the WG specifies. john --On Thursday, December 31, 2020 12:16 -0500 John R Levine wrote: >> If we take the rules seriously, the moment you do that, >> existing implementations that don't do that become >> nonconforming and rfc5321bis goes to Proposed. > > Hmmn. > >> Alternate suggestion: Make sure it the header field is >> registered in the appropriate registry (I'm fairly sure it is >> but don't have time to go check today). Then make this a >> strong recommendation in the A/S. > > It's not registered, which surprised me and is why I'd like to > put it in 5321bis. How about if we add it as a MAY ? From nobody Thu Dec 31 10:16:45 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC14B3A0E1D for ; Thu, 31 Dec 2020 10:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7QPSVIZYXCA for ; Thu, 31 Dec 2020 10:16:36 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A653A0E1B for ; Thu, 31 Dec 2020 10:16:36 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kv2V1-000E7z-96; Thu, 31 Dec 2020 13:16:35 -0500 Date: Thu, 31 Dec 2020 13:16:29 -0500 From: John C Klensin To: John Levine , emailcore@ietf.org cc: ietf-emailcore-phil@spodhuis.org Message-ID: <929E4CBBA2DC4AA5B20D1F25@PSB> In-Reply-To: <20201231172607.8A8C23F00058@ary.qy> References: <20201231172607.8A8C23F00058@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] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 18:16:44 -0000 --On Thursday, December 31, 2020 12:26 -0500 John Levine wrote: >... >> What's the rationale for leaving alone the existing >> Delivered-To: headers? Is this a Trace header which must >> always be prepended, so folks should always use the first one >> seen scanning from the top? > > Yes. That's the existing practice. If we are going to add it to 5321bis, even as a "MAY", it seems to me that we need to agree, not just that it is the existing practice, but that it is a good idea. Again, I'm not violently opposed to the addition, just concerned that we not put it in and create loose ends... and that trying to discuss it not open up cans of worms. john From nobody Thu Dec 31 10:34:55 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74273A0E43 for ; Thu, 31 Dec 2020 10:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 z9G86_0iSKiQ for ; Thu, 31 Dec 2020 10:34:51 -0800 (PST) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9273A0E3D for ; Thu, 31 Dec 2020 10:34:51 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTTM2W9LU800BXD8@mauve.mrochek.com> for emailcore@ietf.org; Thu, 31 Dec 2020 10:29:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1609439387; bh=zPA5TJGlAWQeKMJF8wzdEQf6XqZr6iJDDrHYChA3kMc=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Y1T2MkaRt1TaYNCieNisAcP/nA4ZOL8fR5k1k58GVL20M3ehWvpRURHw3CmlSZXNu qGiVxAVDx8jCSqVvCWPPneQy7EqKmFO5irhBKukJoIpEz0MfQ+DYThH2LYxas68fkd 9Q+TrFochuGKRgoo6rWSxaRBtJ4UZhe46OwXRlDM= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTJOWYX49S004QVR@mauve.mrochek.com>; Thu, 31 Dec 2020 10:29:45 -0800 (PST) Cc: emailcore@ietf.org Message-id: <01RTTM2UBC2E004QVR@mauve.mrochek.com> Date: Thu, 31 Dec 2020 09:53:10 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 31 Dec 2020 10:55:31 -0500" References: To: John R Levine Archived-At: Subject: Re: [Emailcore] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 18:34:53 -0000 > RFC5321 says that when a message is delivered the envelope MAIL FROM > address goes into a Return-Path header, but says nothing about the RCPT TO > address. Many MTAs put that in a Delivered-To header and have done so for > a long time. I know that Postfix and qmail do. According to their documentation both qmail and PostFix primarily use Delivered-To: as a loop prevention mechanism; it's use as a means of providing information about the RCPT TO address is secondary. Additionally, we already have a standardized means of delivering this information: The "for" clause in the Received: field. We also have language describing the issues it has when delivering to multiple recipients. I note in passing that it's not sufficiently useful that we've ever been asked to generate it. > It shows up in examples in RFCs 5293 and 7681. You might want to look at those examples a little more closely. The example in RFC 5293, a proposed standard, shows removal of the first Delivered-To: field when it has a particular value. No context is given, but it sure looks like is it's being done to prevent bad behavior on the part of PostFix or qmail. Not exactly a shining example of interoperability... The example in RFC 7691, an informational RFC, is in a message in "traditional" - which seems to mean obsolete - format. > I think this is sufficiently established that we can add it to 5321bis. > We could say that the delivery SMTP server SHOULD insert a Delivered-To > line when it inserts a Return-Path line, and SHOULD NOT remove existing > Delivered-To lines. How do you propose handling messages delivered to multiple recipients? What do you propose be done about the additional semantics qmail and Postfix have for Delivered-to:? Describe those semantics and tell others to implement them? I'm sorry, but it seems to me that Delivered-to: has "hack" written all over it. Ned From nobody Thu Dec 31 10:34:58 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D8B3A0E3D for ; Thu, 31 Dec 2020 10:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 RBZxlbyHAY2x for ; Thu, 31 Dec 2020 10:34:51 -0800 (PST) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D739C3A0E3F for ; Thu, 31 Dec 2020 10:34:51 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTTM8ZMU6800CFU6@mauve.mrochek.com> for emailcore@ietf.org; Thu, 31 Dec 2020 10:34:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1609439682; bh=Uv5hyZtBR94ImNxuw9vjXCNk3rkZtZrIm/uEXnksWMs=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=q1d7aY1dFxn+gFtOzXht7hNzBRc8oOaU79dNr4kxKYjmD4cTp24EGfIqIB1v3WGQe fLCaw14NqVxxpqQLGikuGVQnOtpTcbdZr+mAPDwHakUTk/3SSD92kJXJ+GAmADW52I EWDjHBdB/8jwCyrEJskko6Vd000kyO34MG4TSdCc= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTJOWYX49S004QVR@mauve.mrochek.com>; Thu, 31 Dec 2020 10:34:40 -0800 (PST) Cc: emailcore@ietf.org Message-id: <01RTTM8Y21FS004QVR@mauve.mrochek.com> Date: Thu, 31 Dec 2020 10:30:41 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 31 Dec 2020 08:03:29 -0800" <57c8838f-e8fe-abdb-f86c-029655319921@linuxmagic.com> References: <57c8838f-e8fe-abdb-f86c-029655319921@linuxmagic.com> To: Michael Peddemors Archived-At: Subject: Re: [Emailcore] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 18:34:53 -0000 > On 2020-12-31 7:55 a.m., John R Levine wrote: > > RFC5321 says that when a message is delivered the envelope MAIL FROM > > address goes into a Return-Path header, but says nothing about the RCPT > > TO address.  Many MTAs put that in a Delivered-To header and have done > > so for a long time.  I know that Postfix and qmail do.  It shows up in > > examples in RFCs 5293 and 7681. > > > > I think this is sufficiently established that we can add it to 5321bis. > > We could say that the delivery SMTP server SHOULD insert a Delivered-To > > line when it inserts a Return-Path line, and SHOULD NOT remove existing > > Delivered-To lines. > This one may not be a simple as that. Delivered-To gets populated > sometimes enroute to it's final distination, eg when local forwarding > rules or email processors operate on the message before it's final > destination. You could have multiple Delivered To in those cases. That's specifically the intent - you then check to see if values are being repeated. If they are you have a loop. > The business rules and logic on WHEN a MAIL FROM gets put into a > Return-Path is/could be different than the logic for placing a Delivered-To Good point. Yes, the rules are indeed different. > ... > Speaking of which, more emphasis should be placed on servers NOT > forwarding emails with a Return-Path in place, it was only meant to be > placed at the final destination.. or at least, if you are going to make > the decision late that you are not the final destination, remember to > strip the Return-Path that your systems added before redirecting.. It's something submission servers should do. What I haven't seen is submission servers removing Delivered-to: which TBH surprises me. OTOH, it's one line of configuration to do it in our server, so it's entirey possible for it to be widely implemented on our platform without me knowing about it. Ned From nobody Thu Dec 31 10:43:17 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9423A00C9 for ; Thu, 31 Dec 2020 10:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 pYOlQSWPdPa6 for ; Thu, 31 Dec 2020 10:43:14 -0800 (PST) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190173A0062 for ; Thu, 31 Dec 2020 10:43:14 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTTMDAIM2O00BKTV@mauve.mrochek.com> for emailcore@ietf.org; Thu, 31 Dec 2020 10:38:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1609439890; bh=qR9vrwticHz5VV+uApAcF3Ylrvzi2NmFIxMOI/pJlxk=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=jb4LxrivZCnaWtV8JUzFeBwMSAjIMWA8nq23Jm9vw6vzjtCYRZb5N03fOO27ptJIo V+STm90xwvDoRHcp96oFq94AEXhwlwl229EIdhX2v/PXuug7C0OoKceUR7hscT1AUq XdTzoLqdLhsBod4o16EfvagHa6ZXqZegCO1cZR+4= 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 <01RTJOWYX49S004QVR@mauve.mrochek.com>; Thu, 31 Dec 2020 10:38:08 -0800 (PST) Cc: emailcore@ietf.org Message-id: <01RTTMD8O3WW004QVR@mauve.mrochek.com> Date: Thu, 31 Dec 2020 10:36:08 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 31 Dec 2020 11:12:58 -0500" References: To: Phil Pennock Archived-At: Subject: Re: [Emailcore] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 18:43:15 -0000 > On 2020-12-31 at 10:55 -0500, John R Levine wrote: > > RFC5321 says that when a message is delivered the envelope MAIL FROM address > > goes into a Return-Path header, but says nothing about the RCPT TO address. > > Many MTAs put that in a Delivered-To header and have done so for a long > > time. I know that Postfix and qmail do. It shows up in examples in RFCs > > 5293 and 7681. > > > > I think this is sufficiently established that we can add it to 5321bis. We > > could say that the delivery SMTP server SHOULD insert a Delivered-To line > > when it inserts a Return-Path line, and SHOULD NOT remove existing > > Delivered-To lines. > Exim spells this "Envelope-to:" and it's not enabled by default in the > code but the sample configurations set it by default for delivery to > files. By contrast, the `envelope_to_remove` option defaults to true, > so that if this header is seen then folks can have confidence it's > local. That's exactly what our MTA does, except the header is X-Envelope-To: > My initial gut reaction (therefore wrong) is that how mail is stored > locally is out-of-scope for the specification of SMTP and how mail is > transferred between systems. > Against that, a common pattern of what behavior folks can count on would > make sense for ensuring data can gateway _back_ to SMTP cleanly. Yet > with some mailbox formats perhaps better suited to this flow, this is > persisted outside of the main headers and restored cleanly without > header parsing. > What's the rationale for leaving alone the existing Delivered-To: > headers? Is this a Trace header which must always be prepended, so > folks should always use the first one seen scanning from the top? It's a loop prevention mechanism, not an informational trace field. Ned From nobody Thu Dec 31 10:44:03 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305E73A00C9 for ; Thu, 31 Dec 2020 10:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IwpcRjq9-RC for ; Thu, 31 Dec 2020 10:44:00 -0800 (PST) Received: from aye.elm.relay.mailchannels.net (aye.elm.relay.mailchannels.net [23.83.212.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 234713A0062 for ; Thu, 31 Dec 2020 10:43:59 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 59AA1481420; Thu, 31 Dec 2020 18:43:59 +0000 (UTC) Received: from nl-srv-smtpout1.hostinger.io (100-96-27-97.trex.outbound.svc.cluster.local [100.96.27.97]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 50B21480F84; Thu, 31 Dec 2020 18:43:58 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout1.hostinger.io ([UNAVAILABLE]. [185.224.136.7]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Thu, 31 Dec 2020 18:43:59 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Squirrel-Imminent: 32b7c11c5fd5d9d1_1609440239022_203105722 X-MC-Loop-Signature: 1609440239022:1756431682 X-MC-Ingress-Time: 1609440239022 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout1.hostinger.io (smtp.hostinger.com) with ESMTPSA id 2EB2B2B78A9D; Thu, 31 Dec 2020 18:43:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1609440236; bh=dnPTW9H8Otx/I0oBOIx9ZlyDpzapL52HtacwHpzvWE4=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=A6UCmMLiIPNFDrEEbxMo6TNeIzNu60AbpHQjUs482aDiN0OEak5nmS5IzxeAfj61T 4l3lS1jGChDK57fgSxiVart2I1lSHfFPT34psEWChS1dK2fG/9trKWpWZTBaJnpiPf tz6xbYXWwWscWbLmdLZv6z2TwlFJF/8Q4si1lCSMWQjvWNU9FHdSSkRWF4G7Afq1iU eg7A2dO4mxESc1AEPVwGzAEABwrp2fx38u1mfUG+9GRUBYNmSTea6wLweNfp5TmmFe 82gI21ByMFPDt0g0XXSi3x6bW+MLx4Zoxy4GPsNm6fWeD5709jnfIMnSzx2ygL6+0g KALvI9GIHvDyw== Reply-To: dcrocker@bbiw.net To: Alexey Melnikov , emailcore@ietf.org References: <128d48b0-1464-4a8c-a8d8-7899a2c5e7a8@www.fastmail.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Thu, 31 Dec 2020 10:43:52 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <128d48b0-1464-4a8c-a8d8-7899a2c5e7a8@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 18:44:02 -0000 On 12/31/2020 8:14 AM, Alexey Melnikov wrote: >> I think this is sufficiently established that we can add it to 5321bis. >> We could say that the delivery SMTP server SHOULD insert a Delivered-To >> line when it inserts a Return-Path line, and SHOULD NOT remove existing >> Delivered-To lines. > > https://trac.ietf.org/trac/emailcore/ticket/44 We have competing constraints here. I think there's a solomonesque way to navigate this... 1. It is helpful -- and sometimes extremely helpful -- for a message to document what address it was delivered to. Multiple accounts and forwarding addresses, can make it unclear what address was used for rcpto. 2. The delivery address is not recorded, at the time of delivery, with any reliability. Nor is there exactly one place used to record it. a) SMTP's Received header field parameters (Section 4.4, ) permits -- but does not require -- use of a FOR clause, with either or . Oddly, I am not finding an actual definition of its semantics, in the spec, though I often consult that parameter to see what the delivery address was. b) Some systems use Deliver-To. Apparently it's not formally documented (presumably outside of system software documentation.) c) Exim uses Evenlope-To. d) It wouldn't be suprising to find other variants 3. The working group charter does not permit adding new things to SMTP: "The limited review is restricted to corrections and clarifications only, with a strong emphasis on keeping these minimal and avoiding broader changes to terminology or document organization." and, as noted, trying to add something puts the goal of full standard at risk. Still... There seems to be a considerable base of appreciation for the function of having a message document what address it was delivered to. (I certainly would like it to be more reliably present.) So I propose the interim step of creating a separate document to specify a standard for indicating the delivery address and, separately, getting it made Proposed Standard. If there is support for this, I'm glad to do the documenting grunge. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 31 10:45:35 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F289D3A00C9 for ; Thu, 31 Dec 2020 10:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_JfqnqH-Q8q for ; Thu, 31 Dec 2020 10:45:31 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C974B3A0062 for ; Thu, 31 Dec 2020 10:45:31 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kv2wy-000EFN-0K; Thu, 31 Dec 2020 13:45:28 -0500 Date: Thu, 31 Dec 2020 13:45:22 -0500 From: John C Klensin To: Alexey Melnikov , Alessandro Vesely , emailcore@ietf.org Message-ID: <05255304C36ADB3801C504D9@PSB> In-Reply-To: <520b541d-e34d-43b0-8ad7-d844dbf7c024@www.fastmail.com> References: <101f868f-b277-2ff3-56dc-44f721dc2f78@tana.it> <520b541d-e34d-43b0-8ad7-d844dbf7c024@www.fastmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Spurious gatewaying reference X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 18:45:33 -0000 --On Thursday, December 31, 2020 16:32 +0000 Alexey Melnikov wrote: > On Thu, Dec 31, 2020, at 2:45 PM, Alessandro Vesely wrote: >> Hi, >> >> Section 4.5.5 starts with the paragraph: >> >> There are several types of notification messages that are >> required by existing and proposed Standards to be sent >> with a null reverse-path, namely non-delivery >> notifications as discussed in Section 3.7, other kinds of >> Delivery Status Notifications (DSNs, RFC 3461 [33]), and >> Message Disposition Notifications (MDNs, RFC 3798 [37]). >> All of >> >> >> Now, Section 3.7 is "Mail Gatewaying". What is it referenced >> for here? > > I read 3.7 and 4.5.5 and I agree that referencing 3.7 seems > odd. > > New ticket: > >> Perhaps, the paragraph should refer to Section 3.6.3, >> "Message Submission Servers as Relays", which discusses >> non-delivery notifications. After doing a bit of checking, I don't know quite how this happened, but it appears to me that either 3.6.2 or 3.6.3 is what was intended (there is mention of NDNs in the former too, although only as a disclaimer. I'd going to take 3.7 out and add both of those for -02; one or the other can be removed if people like. john From nobody Thu Dec 31 11:23:04 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCB33A03FB for ; Thu, 31 Dec 2020 11:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=ospAboo0; dkim=pass (2048-bit key) header.d=taugh.com header.b=OdRNQy0Z Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jssjlWhocDfr for ; Thu, 31 Dec 2020 11:23:01 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50A43A03F8 for ; Thu, 31 Dec 2020 11:23:00 -0800 (PST) Received: (qmail 87947 invoked from network); 31 Dec 2020 19:22:59 -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=15789.5fee2513.k2012; bh=o6yQOlqjRvCvdhHZ+0UBBz5pYRdOOzuh5+plFmlmJKE=; b=ospAboo0TbFiZM+J8RoX8PxrzIrMfjqJmkZAFqBqo/wGoZIrZZqBcsEUoW5r89Go/yl7LpUK9+1zuwhP77bItSxVuLoAVGzTC2YPr76LDmPmsr7279hQDz1sxpc8ai4/gsR7+H0jvMpi2NZIauDmsWUGCpOEc+r78/005csheYGAZWlfrDSNPGVmcrA56U1rGv7ZNgFhwwcooX4r4rYXlcrcnLrLeui58qvKJawgeQObiw7P5Uy1/TONs6e4c8+tk1fLldDmMw9t8pNGb0ZJSOTHO66wwY6djvjdpT37wujoxOoA+73Hz5ElI2Fj9OzOAcvK6/uj7isfdJiTCeHxfQ== 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=15789.5fee2513.k2012; bh=o6yQOlqjRvCvdhHZ+0UBBz5pYRdOOzuh5+plFmlmJKE=; b=OdRNQy0ZBnJbRqZptfar0lnP0sNK5O2e04QVoJ8nJU8nJNm/VHo+WS/i5uL2dUiCqeD+WgyujyYvbbrsVzB0OT+RRMylpY0RUcWqMWoqTty/xvA1J1oVDJhOUnIkDKuQA7geqmYbB9VX7CMQWMaPNNeIQFk1PIL2Pc2S9Ps+QkTjS7byrVa/OD9DPYou831juxJBmqjcUtUipCjCWnsCYy3nD+Fkc5hwvcXtidxER3tKtqHHaoB0H5F/V6/4Xs2phME06+jcGXBAlwRrxh+uoiYP5x5DyDjQjW6W3UXWBiNpb5LPJqQiI6sqGRUB8tAYDm80dJ0oGb1dZ7S8jRPuxg== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 31 Dec 2020 19:22:58 -0000 Received: by ary.qy (Postfix, from userid 501) id 5D8443F01737; Thu, 31 Dec 2020 14:22:58 -0500 (EST) Date: 31 Dec 2020 14:22:58 -0500 Message-Id: <20201231192258.5D8443F01737@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 19:23:03 -0000 In article you write: >So I propose the interim step of creating a separate document to specify >a standard for indicating the delivery address and, separately, getting >it made Proposed Standard. > >If there is support for this, I'm glad to do the documenting grunge. Seems like a reasonable next step. Even if it's a hack, it's a widely used hack so it would be nice to agree what its name is. From nobody Thu Dec 31 11:39:44 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523093A0880 for ; Thu, 31 Dec 2020 11:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSWIVGg27TCI for ; Thu, 31 Dec 2020 11:39:42 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09D343A086D for ; Thu, 31 Dec 2020 11:39:41 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kv3nN-000EY8-59; Thu, 31 Dec 2020 14:39:37 -0500 Date: Thu, 31 Dec 2020 14:39:31 -0500 From: John C Klensin To: "John R. Levine" , Jeremy Harris , emailcore@ietf.org Message-ID: <025577A2E8A799577FD38FD0@PSB> In-Reply-To: <9963648-bb55-88dd-e7ae-66afc5ac546@iecc.com> References: <53f54c70-889b-9a55-6829-340069fbe37e@wizmail.org> <9963648-bb55-88dd-e7ae-66afc5ac546@iecc.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] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 19:39:43 -0000 --On Thursday, December 31, 2020 12:52 -0500 "John R. Levine" wrote: >>> I think this is sufficiently established that we can add it >>> to 5321bis. We could say that the delivery SMTP server >>> SHOULD insert a Delivered-To line >> >> Just because some (and not all) MTAs do? >> Better justification needed, I think. > > Postfix and qmail add it, and have for decades. Gmail adds > it. It's shown up in examples in RFCs. > > I think Exim is in the rough here. Once again, while I think that a discussion of this would be entirely in order in an A/S, if you are convinced that you want it in 5321bis, I think what is needed is: (i) An explanation of why this is needed, going beyond "lots of people are doing it". (ii) A decision about erratum 4055 (Appendix G.4 and Ticket #30 in Appendix H.1) or a conclusion that this header field is equally useful without signatures over the headers. (iii) Agreement about the relationship between this header and existing trace headers covered in RFC 5321, including questions of ordering requirements or old header removal. (iv) A discussion of the relationship among Delivered-To:, Envelope-to:, and X-Original-to:. The latter seems popular in some quarters, often in conjunction with Delivered-to:. I suggest the three have different semantics in some popular cases and, if we are going to put text in 5321bis (or even the A/S) the semantics need to be spelled out. In particular, suppose we have a message that is in transit with RCPT TO: It is handed off to the delivery server with that address, presumably having "Envelope-to:" added at the same time "Return-path:" is added. But suppose that set of delivery mechanisms (which we have resisted specifying in IETF standards track documents for 30 or 40 years), encounters a local alias file that says "tom" is really "dick". Now, it is clear (at least to me) that "Envelope-to:" remains unchanged because the envelope said "tom@example.com". But "Delivered-to:", if interpreted according to the obvious meaning of the term, should have a value of "dick@example.com". Perhaps (but I don't know) "X-Original-To:" is a workaround for that problem and has the same semantics as "Envelope-to:". And, of course, if the above is a correct interpretation of how "Delivered-to:" is expected to behave, it raises two other questions: Do all of the systems that insert "Delivered-to:" interpret it the same way, including in the much more unpleasant case in which, rather than a local alias file, the delivery MTA encounters a forward file that can explicitly allow the target to be one or more addresses on different systems? And is it really an MTA function of part of internal processing on delivery servers? In the latter case, however useful it might be, it does not belong in 5321bis (although "Envelope-to:" might). If those issues are resolved, I hope the resolution will come with text. john From nobody Thu Dec 31 12:50:24 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156153A0B05 for ; Thu, 31 Dec 2020 12:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrZ-ruVlPr-l for ; Thu, 31 Dec 2020 12:50:21 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866A43A0B04 for ; Thu, 31 Dec 2020 12:50:21 -0800 (PST) Received: (qmail 12355 invoked from network); 31 Dec 2020 20:50:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=3041.5fee398c.k2012; i=johnl-iecc.com@submit.iecc.com; bh=8LeCY4SU5dhayEYpYqu45x2Dxy9Q6StEhZdSnNF1Y9s=; b=fAKbIltq/k7ZoY69ZGsmXdPtmvlnVbL8ajr5n7j7R280dPvXd14XXP0Zv1OEJdpKzcvrgYRrlSyh5577aGaJROopP/8gxYySra0/bOmAaTh16RTENn30TyNbhflu3+tt28zXj+z6qQpO75mYpR4Lfk2Xr7xnzTIr+uZ9RWVJC8MKXnzH0IrdztwSZTZ73vDH+bHIahEDN/5kRly83BSZaAgMiXcstWFPaHeas4l6eseJScjwjjB5YaUUgKOsGy12THy8mdAg8Pbez/M4Kssilp1StrKbkq3Cl3LmyXcXv5agNKFeC4uNmjKbHChWaUUEdMIU52GqAagI+aQVVNDMyA== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 31 Dec 2020 20:50:19 -0000 Date: 31 Dec 2020 15:50:19 -0500 Message-ID: <46f545e-4bee-66df-5928-e6d91769d589@iecc.com> From: "John R. Levine" To: "John C Klensin" , "Jeremy Harris" , emailcore@ietf.org In-Reply-To: <025577A2E8A799577FD38FD0@PSB> References: <53f54c70-889b-9a55-6829-340069fbe37e@wizmail.org> <9963648-bb55-88dd-e7ae-66afc5ac546@iecc.com> <025577A2E8A799577FD38FD0@PSB> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Emailcore] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 20:50:23 -0000 > Once again, while I think that a discussion of this would be > entirely in order in an A/S, if you are convinced that you want > it in 5321bis, I think what is needed is: On further consideration I think Dave's approach for a separate draft makes more sense. I would like to document Delivered-To so that if people are going to add a header like that, they use a consistent name, but it's not worth hanging up 5321bis. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Dec 31 13:09:26 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054703A0B55 for ; Thu, 31 Dec 2020 13:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8U-7h5hIZZA6 for ; Thu, 31 Dec 2020 13:09:22 -0800 (PST) Received: from purple.birch.relay.mailchannels.net (purple.birch.relay.mailchannels.net [23.83.209.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92AC73A0B54 for ; Thu, 31 Dec 2020 13:09:22 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 5EE70101759 for ; Thu, 31 Dec 2020 21:09:21 +0000 (UTC) Received: from nl-srv-smtpout1.hostinger.io (100-96-27-97.trex.outbound.svc.cluster.local [100.96.27.97]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 646A5101780 for ; Thu, 31 Dec 2020 21:09:20 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout1.hostinger.io ([UNAVAILABLE]. [185.224.136.7]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Thu, 31 Dec 2020 21:09:21 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Harmony-Tank: 02f59a3356dd95ba_1609448960956_789888741 X-MC-Loop-Signature: 1609448960956:2724206559 X-MC-Ingress-Time: 1609448960956 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout1.hostinger.io (smtp.hostinger.com) with ESMTPSA id 5F0BB2B78A99 for ; Thu, 31 Dec 2020 21:09:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1609448958; bh=FUmU72IgE2zbrO8D+r0GlTHOBSpywruEI9n+mRv8R2A=; h=Reply-To:From:Subject:To:Date; b=IftshO4Ok3pksCR9yPY5afUZQlNlzLXXELotSLHmSosjIDu8z4aFd3pd1XMOC5w8t tMW6QvcwWOebyVRCXz8kMxNSAtujr09F5x94p6ekGmwrTBR6BROfFGjQmtURZTpS70 vMG1ViYjeB505aQcvmp+k2G+nTLAH/9w6FFW0gfAgLdr2flVTJPRWhLy8Rxnw3Zj+s QXkr/BnW2BkuNDTD3nYmKkShTHgBQbbrSpgtszlenWIgpHfga6ksJrGR3sLBk7SwuL QWK8UYQxNIdHLf3c3GSp4HHiepSXdTv01aclAurBn2EK8HDNIM/wEMA+BDdb+rYyNH lh3yZxex7RI2Q== Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking To: emailcore@ietf.org Message-ID: <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> Date: Thu, 31 Dec 2020 13:09:16 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 21:09:24 -0000 I think I've got enough information to formulate an initial draft, for people to shoot at, except for: 1. Why a separate header field, rather than Received's FOR clause? 2. What should it say about delivery to multiple recipients? The easiest -- and probably most problematic, for some systems that share access to a single copy of the message -- is to say it must only contain one address. If the spec says something else, what should it be, and why? 3. ? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 31 13:28:04 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123DC3A0BD7 for ; Thu, 31 Dec 2020 13:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpSTCFKNxy8W for ; Thu, 31 Dec 2020 13:28:03 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F07C3A0BD4 for ; Thu, 31 Dec 2020 13:28:03 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kv5UF-000FNM-JP; Thu, 31 Dec 2020 16:27:59 -0500 Date: Thu, 31 Dec 2020 16:27:53 -0500 From: John C Klensin To: "John R. Levine" , Jeremy Harris , emailcore@ietf.org Message-ID: <8A2C974FDE7E8013849E0A63@PSB> In-Reply-To: <46f545e-4bee-66df-5928-e6d91769d589@iecc.com> References: <53f54c70-889b-9a55-6829-340069fbe37e@wizmail.org> <9963648-bb55-88dd-e7ae-66afc5ac546@iecc.com> <025577A2E8A799577FD38FD0@PSB> <46f545e-4bee-66df-5928-e6d91769d589@iecc.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] Delivered-To header X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 21:28:04 -0000 --On Thursday, December 31, 2020 15:50 -0500 "John R. Levine" wrote: >> Once again, while I think that a discussion of this would be >> entirely in order in an A/S, if you are convinced that you >> want it in 5321bis, I think what is needed is: > > On further consideration I think Dave's approach for a > separate draft makes more sense. > > I would like to document Delivered-To so that if people are > going to add a header like that, they use a consistent name, > but it's not worth hanging up 5321bis. Agree with both of you. And, when you do it, please clarify the semantics as discussed in prior message. john From nobody Thu Dec 31 13:43:39 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A80D3A0BF0 for ; Thu, 31 Dec 2020 13:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9qWxtobdkkj for ; Thu, 31 Dec 2020 13:43:35 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576D93A0BEF for ; Thu, 31 Dec 2020 13:43:35 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kv5jK-000FVG-7I; Thu, 31 Dec 2020 16:43:34 -0500 Date: Thu, 31 Dec 2020 16:43:28 -0500 From: John C Klensin To: dcrocker@bbiw.net, emailcore@ietf.org Message-ID: In-Reply-To: <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> References: <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 21:43:38 -0000 --On Thursday, December 31, 2020 13:09 -0800 Dave Crocker wrote: > I think I've got enough information to formulate an initial > draft, for people to shoot at, except for: > > > 1. Why a separate header field, rather than Received's FOR > clause? > > > 2. What should it say about delivery to multiple recipients? > > The easiest -- and probably most problematic, for some > systems that share access to a single copy of the message -- > is to say it must only contain one address. If the spec says > something else, what should it be, and why? > > > 3. ? My candidate for 3 would be whether the contents of the header field reflect the last address seen by SMTP (i.e., presumably the RCPT address --or more than one which comes back to your #2 -- at the time of handoff to the final delivery server) or the address at the time of delivery to the actual recipient mailbox. I look forward to seeing the draft. john From nobody Thu Dec 31 14:33:46 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76583A0C6A for ; Thu, 31 Dec 2020 14:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=X346BSj5; dkim=pass (2048-bit key) header.d=taugh.com header.b=kcCnPZuZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUqHfOQPuxSy for ; Thu, 31 Dec 2020 14:33:43 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18DE33A0C62 for ; Thu, 31 Dec 2020 14:33:42 -0800 (PST) Received: (qmail 80903 invoked from network); 31 Dec 2020 22:33:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=13c05.5fee51c4.k2012; bh=g3pWCYupR7pnCCTYlmTJbc/qoJ7ML+qAO6Klt9Y6S08=; b=X346BSj5mUyUEUpqzoxTT1cMQC4npnnhclJSFjpMrxyWC5hvasVmuKh9CDFwAsInew8YT675jQHVWz6v5KqcokLiaCiJpUfCb/rgmeqJQac2/7RE0JF5lIXxBPXAEkd9B14+8MWkc/QZAymFGthKNUkl55Z70QQHpJi7JkBiskzmL/vUMG4K6lKqFPJXSady2gp/0Ucb8DXMcEhcASaJLln9a8DhQkKPCh7dUTAM2m1MeLmAUPwhonyfP9yWszaEsJkwhzqHLQjCkwWDvUE2O9I/FYr8qTUnxHd+AU9FA4cM6pIyHIZIy5uQ5VI5L7vn1NBop6yul0v1Wg099KjFBg== 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=13c05.5fee51c4.k2012; bh=g3pWCYupR7pnCCTYlmTJbc/qoJ7ML+qAO6Klt9Y6S08=; b=kcCnPZuZCiYSJrNK1/jpCvJzCmcO/zVlp2oZ44lcOnN54AFcJOmp7hoKDhANKczrEUeLqMkNiPZpAjacYpN4nKdOKea6C+6WU3lvyxO7OdJ+hTdwffey8BAR9JjdEyF+E2yg2Glw/mgD4fSOAiiksBR75bvY9gDC26To6gZhNaqDkI5f/hHz/3rAkrhhmmcNvUKaRrNuS1ifKl2MCX0WrNuZK7FphSwUc7SL3cGL2d7LPs0HSPU6NOLSrIzH0B6halqcUUMkGSNJ07Fd21xYHCnIjWSIJ53LXDvTVEWXvAywLx6+rVD/IGHnU+F8r6q0V7fo+0T+QIc2ZwFvbvt5NQ== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 31 Dec 2020 22:33:40 -0000 Received: by ary.qy (Postfix, from userid 501) id D22303F108F2; Thu, 31 Dec 2020 17:33:39 -0500 (EST) Date: 31 Dec 2020 17:33:39 -0500 Message-Id: <20201231223339.D22303F108F2@ary.qy> From: "John Levine" To: emailcore@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 22:33:45 -0000 In article <4bc00e40-8a18-0c8c-bf1e-672e91da2330@dcrocker.net> you write: >I think I've got enough information to formulate an initial draft, for >people to shoot at, except for: > > >1. Why a separate header field, rather than Received's FOR clause? What jck said, the mailbox into which a message is delivered often has a different name from what was in the RCPT TO. That's particularly likely on systems that handle mail for multiple domains. >2. What should it say about delivery to multiple recipients? > > The easiest -- and probably most problematic, for some systems that >share access to a single copy of the message -- is to say it must only >contain one address. If the spec says something else, what should it >be, and why? I think at this point we'd be making stuff up because I've never seen a Delivered-To for multiple recipients. I'm inclined to follow what sec 4.4 of RFC5321 says and only report one recipient address. R's, John From nobody Thu Dec 31 14:45:40 2020 Return-Path: X-Original-To: emailcore@ietfa.amsl.com Delivered-To: emailcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3AB3A0CB3 for ; Thu, 31 Dec 2020 14:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEnL3ovvGN-H for ; Thu, 31 Dec 2020 14:45:37 -0800 (PST) Received: from giraffe.ash.relay.mailchannels.net (giraffe.ash.relay.mailchannels.net [23.83.222.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840293A0CAF for ; Thu, 31 Dec 2020 14:45:35 -0800 (PST) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 3C837341A9B; Thu, 31 Dec 2020 22:45:32 +0000 (UTC) Received: from nl-srv-smtpout2.hostinger.io (100-96-8-104.trex.outbound.svc.cluster.local [100.96.8.104]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id B7C80340F57; Thu, 31 Dec 2020 22:45:30 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout2.hostinger.io ([UNAVAILABLE]. [145.14.159.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Thu, 31 Dec 2020 22:45:32 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Army-Befitting: 018eb02b7a9d94c2_1609454731941_1249058749 X-MC-Loop-Signature: 1609454731941:705256883 X-MC-Ingress-Time: 1609454731941 Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout2.hostinger.io (smtp.hostinger.com) with ESMTPSA id 698E8333EFB7; Thu, 31 Dec 2020 22:45:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1609454729; bh=2ZH1TBsuq9XqxwTNJxoeGRYOZbcii4WMskz/2G//gJY=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=mV7JCXcVk2Ngf3idj5Ovv4UgIpMD1uXHpm3nE7NZc/O4hyUMi9f6NeRj7qoPgcak8 73T/LZO+pKGXwdpe8G+A9e2eMDMZuWrWDJ6ggHYhkGQ/5wnul/iMEhpzrImva5K04D 32+/J1eh33QwjPHa+ZtKPgBwxOKeXmY7hW6XyvxMCmEYPMhXlJZn2PdPLVK+rdxnvL HCdiIqZIE5K9I+uDbWi6b1fNtbSCwFS2JSwWClr1xKjKZJILvaIpFrmLqxEzDuvdAk te07HeMRMfE6b/Tc2gQlkB73vwIQmbUUaWHC9MisVJIYTmOXGOoqeOBaZsbjLUh/5s xOBmt2tha7iKw== Reply-To: dcrocker@bbiw.net To: John Levine , emailcore@ietf.org Cc: dcrocker@bbiw.net References: <20201231223339.D22303F108F2@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <5461cf6d-270a-cf39-12c0-9754acf90ed2@dcrocker.net> Date: Thu, 31 Dec 2020 14:45:23 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20201231223339.D22303F108F2@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Emailcore] Delivered-To issues X-BeenThere: emailcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EMAILCORE proposed working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 22:45:39 -0000 On 12/31/2020 2:33 PM, John Levine wrote: >> 1. Why a separate header field, rather than Received's FOR clause? > What jck said, the mailbox into which a message is delivered often has > a different name from what was in the RCPT TO. That's particularly > likely on systems that handle mail for multiple domains. with apologies to all, for my reading comprehension, limitations, but would someone point to the place in RFC 5321 where the semantics of the FOR clause are explained, and especially in terms of it's coming from a RCPT TO? The language in Section 4.4, in the third bullet, might be claimed to imply this, but it doesn't actually say it. And that bullet does not have a focus of defining the parameter's semantics. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net