Re: [ietf-smtp] Proposed agenda for EMAILCORE BOF

Alessandro Vesely <vesely@tana.it> Tue, 28 July 2020 10:17 UTC

Return-Path: <vesely@tana.it>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DD43A0A98 for <ietf-smtp@ietfa.amsl.com>; Tue, 28 Jul 2020 03:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIu0wFPvzLfg for <ietf-smtp@ietfa.amsl.com>; Tue, 28 Jul 2020 03:17:49 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92143A0A96 for <ietf-smtp@ietf.org>; Tue, 28 Jul 2020 03:17:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1595931464; bh=2TQ4dezwbemIIVvNnmRzmYrpC4NuighTw31zHuAp73A=; l=1221; h=To:References:From:Date:In-Reply-To; b=DExgAxjitSdF39+kF+/RoCJp8fxwkLOaYlYNROoEniwaK5U/0IkiGuCGqfMINMTuk 8XlzohBeMgos4vN7hp6tnVv8mblNNi1+3E8bixx9abs9ZcUO65WMDrVbdupc8/Cwpq k3vhdr9y0Y941Flkz/Wx2Ub6D6egzDWQrj5MKiXOC25x5PkQY8xPyD92HeqDQ
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC053.000000005F1FFB48.00005D73; Tue, 28 Jul 2020 12:17:44 +0200
To: ietf-smtp@ietf.org
References: <20200723185852.43E3C1D6C234@ary.qy> <f68186e9-3996-a412-25ee-2f5edc0e4d6b@isode.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <717549a3-a94c-0eae-dd28-5a3eb4250805@tana.it>
Date: Tue, 28 Jul 2020 12:17:43 +0200
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: <f68186e9-3996-a412-25ee-2f5edc0e4d6b@isode.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/0puk9d4HBZ3-gxauH1kyvdMYlBU>
Subject: Re: [ietf-smtp] Proposed agenda for EMAILCORE BOF
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2020 10:17:51 -0000

On Fri 24/Jul/2020 13:11:35 +0200 Alexey Melnikov wrote:
> On 23/07/2020 19:58, John Levine wrote:
>> In article <58f73c78-ed2e-98dc-85e7-380ecd5d5bda@network-heretics.com> you write:
>>>> I imagine that you would include SPF and DKIM in this list.
>>>>
>>>> Would you include DMARC, and the new list-friendly version, of which I know
>>>> little?
>>> My strong preference would be to include none of these, and only SMTP
>>> and MIME specifications.
>> I agree. DKIM and SPF sit on top of SMTP and are not part of it. DMARC
>> and ARC are even more sitting on top and are less part of it.
> 
> Right. And we have a separate WG for DMARC already.


Nevertheless, some coordination is needed.  The discussion in Section 7.1 of 
RFC 5321, "Mail Security and Spoofing", needs revision.  This question is 
already addressed in Appendix G.4, "Originator, or Originating System, 
Authentication" of John's I-D.

For RFC 5322, Dave's Author: and Sender: I-Ds might happen to become RFCs 
before rfc5322bis.  Can they be considered in that case?  Certainly, it won't 
make sense to publish contrasting specifications, such as, for example, the 
number of email addresses allowed in a From: field.


Best
Ale
--