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

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(_at_)ietf(_dot_)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.

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp