Subject: [Emailcore] Agenda for the EMAILCORE interim this Friday (January 21st)

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Jan 2022 11:54:53 +0000

Dear WG participants,

EMAILCORE chairs are hoping to see you attending our next interim this 
Friday, at 5pm UTC.

Below is our proposed agenda with some comments:

> #17 (Deprecated Source Routes)
> https://trac.ietf.org/trac/emailcore/ticket/17
John did a good job cleaning this up. There are only some minor 
questions remaining about strength of some requirements in the new 
Appendix F.2.

Please review the new Appendix F.2 and be ready to discuss:

https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis-08#appendix-F.2

>
> #9 (G.7.3. Definition of domain name in Section 2.3.5)
> https://trac.ietf.org/trac/emailcore/ticket/9
Again, I believe John made some good cleanup of this text, but there are 
a couple of minor remaining issues related to text about alises (moved 
from Section 5) and whether DNS resolvability need to be mentioned in 
Section 2.3.5
>
> #4 (Exploders seem to be prohibited from adding List-* header fields)
> https://trac.ietf.org/trac/emailcore/ticket/4
We started discussing this at the last interim, but didn't have enough 
time to make progress on this. I am hoping we can resolve this one.
>
> #1 (G.1 IP address literals in EHLO)
> https://trac.ietf.org/trac/emailcore/ticket/1
>
> #47 (Accepting Messages based on EHLO Argument)
> https://trac.ietf.org/trac/emailcore/ticket/47
The above 2 tickets were addressed in rfc5321bis, but some text in the 
Applicability Statement needs confirmation/closure.
>
> #54 (G.7.17 Hop-by-hop Authentication and/or Encryption)
> https://trac.ietf.org/trac/emailcore/ticket/54
This ticket is now about text in the Applicability Statement. Todd will 
post a separate message on this.
> #16 (Review Timeout Specifications)
> https://trac.ietf.org/trac/emailcore/ticket/16
Trying to get closure on the old ticket. This is about new text proposed 
for the Applicability Statement. Todd will post a separate message on this.
> #12 (G.7.5. Improve description/definition of mailing lists, aliases, 
> and forwarding)
> https://trac.ietf.org/trac/emailcore/ticket/12
>
> #3 (G.3. Meaning of "MTA" and Related Terminolog)
> https://trac.ietf.org/trac/emailcore/ticket/3
Discussion about these started at the last interim meeting, but we 
didn't have time to make significant progress on these. Hopefully we can 
progress these tickets further this time.

Best Regards,

Alexey

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Jan 2022 08:39:40 -0800

> https://trac.ietf.org/trac/emailcore/ticket/9

Using this section *merely as an example*, I'd like to (re-)raise a 
question about criteria for this version of the document.

For reference, the charter's guidance is:

> This working group will conduct a limited review and revision to the base
> email specifications, and will publish new versions of these documents at
> Internet Standard status, per RFC 6410. The limited review is restricted
> to corrections and clarifications only, with a strong emphasis on keeping
> these minimal and avoiding broader changes to terminology or document
> organization. In addition to processing existing, verified errata and
> errata marked as "held for document update", the WG may address
> newly-offered errata. However, no new protocol extensions or amendments
> will be considered for inclusion into 5321bis and 5322bis documents,
> unless they are already published as IETF Stream RFCs and are at
> sufficient maturity level to move to Internet Standard.

"corrections and clarifications"

"no new protocol extensions or amendments...unless they are already 
published as IETF Stream RFCs and are at sufficient maturity level to 
move to Internet Standard."

The Domain Name System is separate from email and now has extensive 
documentation of specs and use. This was not true in 1982, when SMTP and 
the DNS were in parallel development.

The SMTP specification has no authority of any aspect of the DNS -- 
except SMTP's /use/ of it.

Therefore, any text in the SMTP specification that provides 
specification of DNS syntax or semantics is, at best, wholly redundant 
with the authoritative specification(s).  The 'at best' is because 
redundant specification always invites /divergent/ specification.

   *  This raises the question of why the current effort seeks to modify
      text that does specify Domain Name syntax or semantics, rather than
      simply having the document cite authoritative sources?

A concern that it regularly raised about such a change to this document 
is that it might disrupt existing use of SMTP.  I suggest that if that 
were a real danger, it would mean that there is use of the DNS in SMTP 
that does not conform to the authoritative DNS documents.  I'd be quite 
surprised to see any support for actual non-conformance.  Hence the fear 
has a logic that is presumably not matched by practice.

Scope:

Another distinction for the current work is normative specification vs. 
pedagogy and commentary.

   *  Obviously, the current effort /must/ repair any normative errors in
      the SMTP protocol specification.

   *  Presumably it also should improve on SMTP protocol pedagogy or
      commentary that is now known to be incorrect.

   *  What is not at all clear is why the current document should include
      commentary or guidance about anything over which it has no
      normative control and is, again, likely to be incomplete and/or
      divergent from documents that do have normative control?

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net