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
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
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]
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
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
we can discuss:
G.5. Remove or deprecate the work-around from code 552 to 452
The suggestion in Section 184.108.40.206.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 220.127.116.11. 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 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
|<Prev in Thread]
||[Next in Thread>|
Re: [ietf-smtp] Proposed agenda for EMAILCORE BOF,
Michael Peddemors <=