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

Michael Peddemors <michael@linuxmagic.com> Wed, 22 July 2020 15:56 UTC

Return-Path: <michael@linuxmagic.com>
X-Original-To: mailsec@ietfa.amsl.com
Delivered-To: mailsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1326D3A0978 for <mailsec@ietfa.amsl.com>; Wed, 22 Jul 2020 08:56:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXUwjIYlwEhz for <mailsec@ietfa.amsl.com>; Wed, 22 Jul 2020 08:56:24 -0700 (PDT)
Received: from mail-ob3.cityemail.com (unknown [104.128.152.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFFD3A0962 for <mailsec@ietf.org>; Wed, 22 Jul 2020 08:56:21 -0700 (PDT)
Received: (qmail 13250 invoked from network); 22 Jul 2020 15:56:21 -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 (e2e2e540-cc33-11ea-90d0-7fe6812030b9); Wed, 22 Jul 2020 08:56:21 -0700
To: ietf-smtp@ietf.org, mailsec@ietf.org
References: <579f408c-ed7e-9dbe-f626-f0dab2380d13@isode.com>
From: Michael Peddemors <michael@linuxmagic.com>
Organization: LinuxMagic Inc.
Message-ID: <2841d94c-07c8-c90b-70f4-e74fca55eb5e@linuxmagic.com>
Date: Wed, 22 Jul 2020 08:56:20 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <579f408c-ed7e-9dbe-f626-f0dab2380d13@isode.com>
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: e2e2e540-cc33-11ea-90d0-7fe6812030b9
X-MagicMail-Authenticated: michael@wizard.ca
X-MagicMail-SourceIP: 104.128.144.8
X-MagicMail-RegexMatch: 0
X-MagicMail-EnvelopeFrom: <michael@linuxmagic.com>
X-Archive: Yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/mailsec/FYQej0KfBpOnE3HGolp0J8HAEoQ>
Subject: Re: [Mailsec] [ietf-smtp] Proposed agenda for EMAILCORE BOF
X-BeenThere: mailsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <mailsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mailsec>, <mailto:mailsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mailsec/>
List-Post: <mailto:mailsec@ietf.org>
List-Help: <mailto:mailsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mailsec>, <mailto:mailsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2020 15:56:27 -0000

I would also like to again talk about CLIENTID in email core as well.
We recently started a 'mailsec' mailing list, and currently just pushing 
for more people to get on that list, that is specifically interested in 
email security issues, however with an 'email core', we should discuss 
if some of those elements have a cross over.

Since it is obvious that extensions to SMTP are being considered, and 
since this is 'email core' and not just SMTP anymore, the CLIENTID 
extension for SMTP/IMAP should be considered as part of that (smtp 
extensions) discussion.

For the record, we now have many email clients, and email libraries 
supporting CLIENTID as it stands in the present RFC Drafts, making this 
already a defacto standard, which is something that the IETF I believes 
uses as a litmus test for things that should be supported/pursued by the 
IETF.

CLIENTID support is in the wild, with our MagicMail platforms, as well 
as other platforms are in various stages of supporting it (MailEnable et 
al) and modern email clients like SaneBox, BlueMail, emClient, 
Thunderbird and more are already shipping with CLIENTID support.

As well, I do see that the topics I suggested for the 'mailsec' mailing 
list, eg discussing no longer suggesting the use of POP 110, or SMTP 
AUTH on port 25, (eg no use of protocols that are not SSL/TLS enabled) 
is also listed as a topic for this BOF.

Welcome comments on the overlaps, and suggestions on how to 
administratively best address that overlap.



On 2020-07-22 4:49 a.m., Alexey Melnikov wrote:
> Revision of core Email specifications (emailcore) agenda for [virtual] 
> Madrid.
> 
> 
> WEDNESDAY, July 29, 2020 (UTC)
> 11:00-12:40 (1 hour 40 mins)
> 
> 
> Agenda bashing, introduction, meeting format (chairs) -  5 mins
> Problem statement (chairs) -  5 mins
> 
> Review of proposed changes to "Internet Message Format" (RFC 5322)
> draft-resnick-rfc5322bis - 15 mins
> 
>   Issue with ABNF for "field": https://www.rfc-editor.org/errata/eid2950
>   Disallow empty quoted string: https://www.rfc-editor.org/errata/eid3135
>   Header field name length limit: https://www.rfc-editor.org/errata/eid5918
> 
> 
> Triage of raised issues for "Simple Mail Transfer Protocol" (RFC 5321)
> draft-klensin-rfc5321bis - 10 mins
> 
> Example topics (we tackle as many as we have time for)
> 
>   G.9.  Revisiting Quoted Strings
> 
>   G.7.11.  Bring back 1yz reply codes?
> 
> Core Email Applicability Statement: - 35 mins
> 
>   G.6.  Clarify where the protocol stands with respect to submission and
>         TLS issues
> 
>     1.  submission on port 587 or port 465
> 
>     2.  TLS relay on a port different from 25 (whenever)
> 
>   Suggested SMTP Extensions:
>    G.8.  Enhanced Reply Codes and DSNs
>    8BITMIME
>    SMTPUTF8 (a.k.a. EAI)
> 
>   Terminology:
>    G.3.  Meaning of "MTA" and Related Terminology
>    G.7.2.  SMTP Model, terminology, and relationship to RFC 5598
>    G.11.  SMTP Clients, Servers, Senders, and Receivers
> 
>   G.1.  IP Address Literals in EHLO, MAIL or RCPT
> 
>   G.7.3.  Resolvable FQDNs and private domain names
> 
>   G.10.  Internationalization Consideration section needed?
> 
> 
> High level discussion of how the proposed WG going to decide
> which issues to tackle (chairs) -  5 mins
> 
> Charter Review and discussion (chairs) - 25 mins
> 
> 
> 
> Documents:
>   https://datatracker.ietf.org/doc/draft-resnick-rfc5322bis/?include_text=1
>   https://www.rfc-editor.org/errata_search.php?rfc=5322&rec_status=15&presentation=table
>   https://datatracker.ietf.org/doc/draft-klensin-rfc5321bis/?include_text=1
>   https://www.rfc-editor.org/errata_search.php?rfc=5321&rec_status=15&presentation=table
>   https://datatracker.ietf.org/doc/draft-klensin-email-core-as/?include_text=1
> 
> ---------------
> If we go too quickly through triage of some issues, here are some others 
> that
> we can discuss:
> 
> G.5.  Remove or deprecate the work-around from code 552 to 452
> 
>     The suggestion in Section 4.5.3.1.10 may have outlived its usefulness
>     and/or be inconsistent with current practice.  Should it be removed
>     and/or explicitly deprecated?
> 
> G.7.1.  Issues with 521, 554, and 556 codes
> 
>     See new Section 4.2.4.2.  More text may be needed, there or
>     elsewhere, about choices of codes in response to initial opening and
>     to EHLO, especially to deal with selective policy rejections.
> 
> _______________________________________________
> ietf-smtp mailing list
> ietf-smtp@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-smtp



-- 
"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.