[Top] [All Lists]

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

2020-07-22 10:56:35
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":
  Disallow empty quoted string:
  Header field name length limit:

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
   SMTPUTF8 (a.k.a. EAI)

   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


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

"Catch the Magic of Linux..."
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at @linuxmagic
A Wizard IT Company - For More Info
"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

<Prev in Thread] Current Thread [Next in Thread>