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

From: Alexey Melnikov <[email-masked]>
Date: Wed, 22 Jul 2020 12:49:46 +0100

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.

---

From: Дилян Палаузов <[email-masked]>
Date: Wed, 22 Jul 2020 15:18:06 +0300

Hello,

> G.6.  Clarify where the protocol stands with respect to submission and TLS issues

RFC 8314 says in the Introduction:

“This memo now recommends that:

o Connections to Mail Submission Servers and Mail Access Servers be made using "Implicit TLS" (as defined below), in preference to connecting to the "cleartext" port and negotiating TLS using the STARTTLS command or a similar command.”

My reading is thay the above text clarifies to prefer 465 over 587.

Greetings
  Дилян

На 22 юли 2020 г. 14:49:46 GMT+03:00, Alexey Melnikov <[email-masked]> написа:
> Disallow empty quoted string:
>https://www.rfc-editor.org/errata/eid3135
> Header field name length limit:
>https://www.rfc-editor.org/errata/eid5918
>
>
>_______________________________________________
>ietf-smtp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf-smtp

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 22 Jul 2020 13:24:16 +0100

Hi Дилян,

On 22/07/2020 13:18, Дилян Палаузов wrote:

> o Connections to Mail Submission Servers and Mail Access Servers be 
> made using "Implicit TLS" (as defined below), in preference to 
> connecting to the "cleartext" port and negotiating TLS using the 
> STARTTLS command or a similar command.”
>

Come to the EMAILCORE BOF and we will discuss :-).

Best Regards,

Alexey

>        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
>
>
>     ------------------------------------------------------------------------
>     ------------------------------------------------------------------------
>     ietf-smtp mailing list
>     [email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Jul 2020 05:27:03 -0700

> Core Email Applicability Statement: - 35 mins

More time is budgeted for this than for charter discussion.

Applicability Statements have long been popular in the IETF.  They are 
an obviously good idea.

Less obvious is whether they are worth the effort.

Who uses them and what is the evidence they are worth the effort?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 22 Jul 2020 13:43:17 +0100

> More time is budgeted for this than for charter discussion.

You will see that various topics are split between RFC 5321 and 
Applicability Statement. We will spend some time at the BOF to discuss 
typical types of issues/suggested changes raised and which ones WG-to-be 
should tackle. This will affect the proposed Charter text, that is why I 
proposed to spend more time on this section. Having said that BOF chairs 
are going to be fluid with time keeping: we might spend more time on 
some topics as long as the [virtual] room is making progress and we 
might cut some discussions short if we are ratholing.

> Who uses them and what is the evidence they are worth the effort?

This would be a good topic to raise at the BOF.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Jul 2020 06:07:18 -0700

> This would be a good topic to raise at the BOF.

Mailing lists are generally viewed as the best place for raising and 
discussing issues.

Meetings have very limited time, and -- worse -- the real-time 
(spontaneous) nature of meetings does not permit sustained consideration.

So I'm raising the question now, hoping for responses /before/ the 
meeting, as input to the meeting.

d/

---

From: Michael Peddemors <[email-masked]>
Date: Wed, 22 Jul 2020 08:56:20 -0700

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.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 22 Jul 2020 17:20:15 +0100

On 22/07/2020 14:07, Dave Crocker wrote:

>>> Applicability Statements have long been popular in the IETF.  They 
>>> are an obviously good idea.
>>>

Dave, I was not being flippant when I wrote "good topic for the BOF". I 
am happy to have a discussion of this now, but this needs answers from 
more than just me.

My personal opinion is that I find them useful. Other people might disagree.

---

From: "John Levine" <[email-masked]>
Date: 22 Jul 2020 17:34:05 -0000

In article <[email-masked]>,
� ил� н � ала� зов <[email-masked]> wrote:
>-=-=-=-=-=-
>o Connections to Mail Submission Servers and Mail Access Servers be made using "Implicit TLS" (as
>defined below), in preference to connecting to the "cleartext" port and negotiating TLS using the

Some of us disagree about how well this advice matches reality. See
you at the BOF.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jul 2020 00:01:13 -0400

> Some of us disagree about how well this advice matches reality. See

What does it even mean to say that this does or does not match "reality"?

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jul 2020 00:14:27 -0400

I would like it to be clarified as to whether the purpose of the BOF is 
to bash the charter for the proposed EMAILCORE WG.

If the purpose of the EMAILCORE WG is indeed to bring the current 
message format and SMTP specifications to Full Standard, I further 
propose that any features not in those specifications should be 
out-of-scope for the WG, unless perhaps any new features are (a) already 
at Proposed Standard; (b) widely implemented enough to also be 
considered for Full Standard; and (c) necessary for inclusion in the 
core specifications in order for the complete set of revised 
specifications (core + new features) to qualify for Full Standard.

(I suppose if someone wants to make a case that the core email 
specifications are not suitable for advancement to Full Standard but 
instead should be recycled at Proposed, while the charter is being 
bashed would also be the time to make that argument.)

I would therefore propose that any features that don't meet those 
criteria either be ruled out-of-scope for the BOF, at least deferred 
until the WG charter has been bashed.   Perhaps if there's time 
remaining it would make sense to use that time to discuss features that 
couldn't be taken up by the working group.

What I don't think makes any sense at all, at least given the current 
IETF standards process, is to combine a discussion of adding new 
features, with a discussion of advancement to Full Standard.

Keith

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Jul 2020 11:38:25 -0400

Keith Moore <[email-masked]> wrote:
    > If the purpose of the EMAILCORE WG is indeed to bring the current message
    > format and SMTP specifications to Full Standard, I further propose that any
    > features not in those specifications should be out-of-scope for the WG,
    > unless perhaps any new features are (a) already at Proposed Standard; (b)
    > widely implemented enough to also be considered for Full Standard; and (c)
    > necessary for inclusion in the core specifications in order for the complete
    > set of revised specifications (core + new features) to qualify for Full
    > Standard.

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?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "John Levine" <[email-masked]>
Date: 23 Jul 2020 11:43:22 -0400

The advice is to use ports that do TLS on connect (465, 993, 995)
rather than ones that connect and then use a command to upgrade (587,
110, 143) on the theory that a bad guy might do STARTTLS stripping on
the latter. I think it is reasonable to assume that any adversary that
knows how to mess with STARTTLS packets also knows how to do port
blocking, and if one port doesn't work MUAs will try the other, so it
doesn't help.

I also observer that MUAs all offer the option of doing it either way
when you set them up, and remember that configuration for subsequent
connections. More useful advice would be to configure a TLS connection
of either type at setup time, and if that configuration later stops
working, alert the user rather than silently working around it.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jul 2020 12:27:50 -0400

> Would you include DMARC, and the new list-friendly version, of which I know

My strong preference would be to include none of these, and only SMTP 
and MIME specifications.

Keith

---

From: Michael Peddemors <[email-masked]>
Date: Thu, 23 Jul 2020 10:14:58 -0700

> My strong preference would be to include none of these, and only SMTP 

If you limit to SMTP and MIME, this isn't really 'email core'.
Including IMAP and possibly others, should be encouraged.

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jul 2020 13:34:58 -0400

> Including IMAP and possibly others, should be encouraged.

I disagree, and for what it's worth, that's not what I had understood 
the intent of the group to be.

If it's necessary to change the name of the group to minimize confusion, 
so be it.

I believe that a tight focus is essential for most working groups, and 
especially so for a group that's tasked with moving a set of mature 
documents to Full Standard.   I don't think such a group should be used 
to bless potentially every email protocol in use, as IMO they vary a 
great deal in both quality and long-term applicability.   I think such a 
group could easily slide down a slippery slope into a huge rathole.

But it does seem like a scope discussion might be a good use of BOF 
time, assuming the ADs are willing at all to entertain the idea of 
making EMAILCORE wider in scope than just SMTP and MIME.

Keith

---

From: Hector Santos <[email-masked]>
Date: Thu, 23 Jul 2020 14:12:38 -0400

On 7/23/2020 1:34 PM, Keith Moore wrote:
> If it's necessary to change the name of the group to minimize
> confusion, so be it.
>
> documents to Full Standard.   I don't think such a group should be
> used to bless potentially every email protocol in use, as IMO they
> vary a great deal in both quality and long-term applicability.   I
> think such a group could easily slide down a slippery slope into a
> huge rathole.
>

+1 on all points.

The term "EmailCore" would inherently suggest a wider scope for the 
Applicability statement covering modern electronic mail. It would 
suggest all the protocols which are part of the "Email-Core" including 
SMTP, POP3, IMAP, NNTP (for legacy purposes, how is it used today) and 
"JMAP" which seems to be blowing pass by SMTP.

This would be the "Perry's Handbook For Mail Engineers" I personally 
believe would help the "total integrated" framework moving forward for 
the next wave of mail engineers.

HOWEVER, this "handbook" would definitely be too much when the 
original intent, I thought, was to 2020 codifying SMTP with RFC5322bis 
and RFC5321bis, preparing it for STD status. Klensin, the world, 
deserves these documents to get to STD.

We also have the email-core conflicts of different mail streams, 
namely, 1::1 direct mail and 1::MANY distribution streams. The 
conflict has been highlighted by DKIM and its augmented security 
protocols. How this fits with the "email-core' are the proposals and 
discussion in the DMARC group to lower the RFC5322.From persistent 
field status to a mutable one.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: "John Levine" <[email-masked]>
Date: 23 Jul 2020 14:58:52 -0400

>My strong preference would be to include none of these, and only SMTP 

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.

R's,
John

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 24 Jul 2020 12:10:02 +0100

> Including IMAP and possibly others, should be encouraged.

I am basically agreeing with Keith on this, i.e. I disagree. Besides, we 
already have a WG for IMAP: EXTRA.

My idea with EMAILCORE (or whatever better name we can find) is that we 
start with 2-3 email format and SMTP related documents at a time and 
then move on to the next set (which will require rechartering), once we 
finish. This would avoid boiling the ocean.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 24 Jul 2020 12:11:35 +0100

> and ARC are even more sitting on top and are less part of it.

Right. And we have a separate WG for DMARC already.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 24 Jul 2020 14:35:33 +0100

Hi Keith,

On 23/07/2020 05:14, Keith Moore wrote:
> I would like it to be clarified as to whether the purpose of the BOF 
> is to bash the charter for the proposed EMAILCORE WG.
>
> message format and SMTP specifications to Full Standard,
Yes.
> I further propose that any features not in those specifications should 
> be out-of-scope for the WG, unless perhaps any new features are (a) 
> already at Proposed Standard; (b) widely implemented enough to also be 

I think you are basically making the same comment as John.

> until the WG charter has been bashed. 
Yes, we will have a change to discuss this when discussing the proposed 
charter.
> Perhaps if there's time remaining it would make sense to use that time 
> to discuss features that couldn't be taken up by the working group.
>

Agreed.

Best Regards,

Alexey

---

From: Keith Moore <[email-masked]>
Date: Sun, 26 Jul 2020 23:20:58 -0400

> working, alert the user rather than silently working around it.

1. Let me address the latter point first.

The draft that became RFC8314 was intended to recommend exactly that for 
user agents: establish parameters for a secure connection when the 
connection is set up, remember those parameters for subsequent 
connections, and fail if the pre-established requirements for connection 
setup were not met.   For example, section 5 repeatedly discusses 
recommendations for "establishing new configurations" and "account setup".

However, as I read the document now, this is certainly not stated as 
clearly as I would like.   I'm thinking that some of the text in earlier 
drafts that specified user agent requirements, was removed in a late 
edit in an attempt to make the document less cumbersome to read.

2. Regarding ports: 8314 doesn't make recommendations in terms of which 
ports to use, but rather to use Implicit TLS in preference to 
STARTTLS.   (This may seem like a subtle point, but in practice a server 
operator can operate a service using Implicit TLS over any port that he 
or she wishes.   There is no protocol requirement to use the IANA port 
assignments.)   "Implicit TLS" simply means to configure a client and 
server to negotiate the TLS connection immediately after TCP open, on 
whichever port they are both configured to use.

The preference for Implicit TLS over STARTTLS is based on the assumption 
that it's harder for an attacker to hijack a Implicit TLS connection, or 
force a downgrade of such a connection to cleartext, than it is for an 
attacker to force a downgrade of a connection using STARTTLS to use 
cleartext.  Neither a client that is configured to use Implicit TLS nor 
a client that is configured to use STARTTLS should ever fail over to 
cleartext, and I think 8314 is clear enough about that.

But, as stated above, 8314 was intended to recommend that an MUA 
determine the requirements of an account's configuration when an account 
is set up, NOT to do this on a per-connection basis.    If the client is 
pre-configured to use Implicit TLS on some port when talking to the 
server, and for whatever reason that connection setup fails (e.g. TCP 
open fails, TLS negotiation fails, certificate validation fails), 
something is wrong and the client should abandon that attempt to 
establish the connection.

The client is NOT expected to fail-over to STARTTLS on a different 
port.   The whole point of establishing the connection in advance and 
preferring Implicit TLS is to minimize the potential for downgrade attacks.

Keith

---

From: "John Levine" <[email-masked]>
Date: 27 Jul 2020 08:26:40 -0400

In article <[email-masked]> you write:
>>>> you at the BOF. ...

>preferring Implicit TLS is to minimize the potential for downgrade attacks.

We agree about that, but if that what 8314 is supposed to say, it's
not saying it in a way I can recognize.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Jul 2020 09:05:54 -0400

> not saying it in a way I can recognize.

I see your point.

Keith

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Jul 2020 12:17:43 +0200

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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 28 Jul 2020 03:49:53 -0700

On 7/28/2020 3:17 AM, Alessandro Vesely wrote:
> 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.

Since emailcore is for making small fixes to the core specifications, 
introduction of new functionality would seem to be out of scope.  As 
such, neither of my proposals ought to be relevant to the emailcore effort.

d/

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 Jul 2020 07:29:34 -0400

Ale,

Two small comments...

--On Tuesday, July 28, 2020 12:17 +0200 Alessandro Vesely
<[email-masked]> wrote:

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

As I mentioned on-list when what is now Appendix G was started
and ;east until there is a WG, I'm trying to remain strictly
neutral about the items listed there.  So the listing of a
particular topic doesn't mean it has been addressed, at least as
I would use that term, only that someone has raised the issue
and I wrote it down.  The question as to what should be done
about it and, if anything, where is a potential BOF discussion
topic and eventually up to the WG.

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

No opinion, right now, about what should be done.  But a
procedural point is probably relevant: while the draft charter
talks about things that could be discussed with its scope,
actual incorporation of those features into 5322bis would
require that they be published as Proposed Standards, wait some
months, and then that the specifications be implemented and show
"widespread deployment of multiple implementations from
different code bases" [RFC 6410].   

As far as I can tell, there is little energy for working on
RRC5321bis/5322bis and then reissuing them as Proposed
Standards.   If the goal is to finally get SMTP and the Header
specification to Internet Standard and definitively (finally)
replace 821/822 --something I read into the draft charter-- that
would be seriously counterproductive.  If there are
specifications in the pipe whose results should really be
incorporated into the revised documents, than we should probably
postpone the WG until those specifications are ready.  If you
believe that is the case, please make the argument at the BOF.

    john

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Jul 2020 07:47:24 -0400

Strictly speaking, 8314 does not prefer 465 over 587.  It prefers 
Implicit TLS over STARTTLS.

The default port for submission over Implicit TLS is 465, but a client 
and server can use a different port by mutual agreement.

The default port for submission over cleartext (upgradable using 
STARTTLS if both client and server support it) is 587, but again, a 
different port can be used by mutual agreement.

8314 prefers Implicit TLS over STARTTLS (because it's harder for an 
attacker [or middlebox] to hijack a TLS connection that starts at TCP 
Open than for an attacker to hijack an ordinary TCP connection that is 
subsequently upgraded to use TLS using STARTTLS).    But either type of 
connection is permitted and considered secure for user interface 
purposes as long as the connection otherwise meets minimum 
confidentiality requirements. One implication is that there's no 
requirement in 8314 for mail service providers to shift customers to 
Implicit TLS if they're already using STARTTLS.  (But ideally mail 
service providers would support Implicit TLS if they're not already 
doing so.)

But the intention in 8314 was that this choice of Implicit TLS vs. 
STARTTLS should be made at account configuration time, NOT on a 
per-session basis.   Unfortunately it now appears to me that the 
language that should have made this clear was inadvertently removed in a 
late edit (but still prior to Last Call).

Keith

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Jul 2020 17:47:02 +0200

On Tue 28/Jul/2020 13:29:34 +0200 John C Klensin wrote:
> 
> As far as I can tell, there is little energy for working on RFC5321bis/
> 5322bis and then reissuing them as Proposed Standards.   If the goal is to
> finally get SMTP and the Header specification to Internet Standard and
> definitively (finally) replace 821/822 --something I read into the draft
> charter-- that would be seriously counterproductive.

Agreed.

> If there are specifications in the pipe whose results should really be 
> incorporated into the revised documents, than we should probably postpone
> the WG until those specifications are ready.  If you believe that is the
> case, please make the argument at the BOF.

No, that would be too slow.  A right amount of coordination will suffice :-)

Best
Ale
--

---

From: Hector Santos <[email-masked]>
Date: Tue, 28 Jul 2020 12:22:09 -0400

On 7/28/2020 6:17 AM, Alessandro Vesely wrote:

> RFCs before rfc5322bis.

I hope not.