EMAILCORE
EMAILCORE Agenda
IETF 121 [hybrid] Dublin
Session 1:
Thursday 7 November 2024
17:30 (UTC) 1 hour
Session 2:
Friday 8 November 2024
13:00 (UTC) 1 hour (but can have up to 2)
Meetecho:
https://meetings.conf.meetecho.com/ietf121/?group=emailcore&short=&item=1
Notes: https://notes.ietf.org/notes-ietf-121-emailcore
Chairs: Alexey Melnikov, Todd Herr
Note: timings are approximate!
Session 1:
Note Taker: Tero Kivinen
17:30 Administrivia
(5 min; chairs)
The current list of open issues (for all documents):
https://github.com/ietf-wg-emailcore/emailcore/issues?q=is%3Aopen
17:35 Review of remaining SecDir and DnsDir comments on SMTP
(rfc5321bis)
https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis-32
(55 mins; Alexey Melnikov, assisted by John Klensin)
Alexey reads all of the Note Well statement, slowly and carefully.
WG status: 5322bis done, 5321bis is post-LC, will need discussion today
due to comments from secdir/dnsdir reviewers.
Issue 106: Donald Eastlake commented on wording. No appetite for change
in the room.
Issue 115: What is needed to reclassify RFC 821 on publication so that
it is no longer listed as Internet Standard? Chairs suggest to punt to
the AD who can do this in IESG, AD looks happyish.
Issue 121: Chained CNAMEs. Ted Lemon suggested changed text earlier.
John Levine suggests accepting Ted's text, noone disagrees.
Issue 98: Donald Eastlake suggests simpler text for a complicated
paragraph. People in the room like Donald's text.
Issues 113, 109, 110, 112: Various additional security considerations
relating to STARTTLS and DKIM. Alexey mentions the possibility of
letting this document wait until it and the A/S can be sent to the IESG
at the same time, since the A/S contains most of the text requested in
these issues. Barry suggests that the AD (present) should make the final
decision. Pete further suggests that informative references to the A/S
will do. Pete largely agrees and thinks informative references will get
the point across. Pete does explicitly not want to hold this document up
to avoid downreferences, but if it waits anyway, which it likely does...
John wants to avoid mentioning specific tools to use, and likes Pete's
language that references the A/S much better. Tero Kivinen is a little
on the fence, thinks implementers ought to read the A/S, thinks
informative references to the A/S will do. Alexey requests Tero to
suggest some specific text to include in rfc5321bis about STARTTLS/etc.
Jim Fenton wants language that mentions that STARTTLS isn't always
sufficient, Alexey thinks there's something of the sort in the A/S but
wants that checked.
Pete points out that 5322bis contains informative references that people
will need to read anyway (about 8-bit/UTF8) and says that adding
informative references in the security considerations isn't a big deal.
Ken points out that there is a large chunk of text in A/S already, and
asks people to go and read it. Murray points out that STARTTLS is a SMTP
extension and assumes that noone wants to include all of RFC3207 into
this document, and therefore an informative reference to the A/S is a
good way forwards. John is open to text. Barry suggests requesting early
SecDir review of the A/S as we work on this document, to make sure that
the people who've asked for text here are satisfied with the text in the
A/S.
Alexey suggests leaving any residual changes for listed tickets and
dealing with them once the above has been dealt with in the document.
Issue 108: Further deprecate or prohibit TURN, or else describe when it
might be used? Alexey suggests changing "SHOULD NOT be used unless
authenticated" to "MUST NOT be used unless authenticated", as individual
rather than chair. John prefers to leave the text alone and leave cans
of worms closed, and promises to edit the text if e.g. SecDir or IESG
demands something.
Pete thinks MUST NOT is more correct, and agrees with John that it's not
a major issue. John (Levine) prefer to leave the existing text alone.
Murray half-suggests taking out the entire text, Alexey replies that
it's in the section about obsolete, removed features.
Alexey sums up the sense of the room as "leave it as is and Murray will
defend that in the IESG". John (Klensin) mentions that there remain
users of TURN, even if rare, and doesn't want to change the text. Murray
offers to defend everything and anything the WG decides. Laughs around
the room.
Issue 111: Donald pointed out that the section title of section 7.1 is
suboptimal.
John K. says the title is a little bit intentionally ambiguous, doesn't
mind changing the title. Alexey suggests that John K. changes the title
and everyone else will definitely check the next revision, everyone else
is silent.
Issue 99: Donald suggests to change a sentence. John K. already included
it in the latest draft. Checking with the WG that this is fine. No
objections.
Issue 101: Donald asks for a clarification. John K. already included it
in the latest draft. Checking with the WG that this is fine. No
objections. Steve and Murray then discuss wording. Still accepted.
Issue 104: Whether to change the title of 5.3.2 to include EXPN. General
agreement.
Issue 105: Whether to remove parenthesis in order to avoid a possible
misunderstanding in section 4.2.2. Alexey suggests leaving the text as
is. Murray points out that there's a grammar problem, John (Klensin)
thinks he's fixed that. Barry has some sympathy for the point that
SHOULD shouldn't be inside parenthesis, but accepts the text as is.
Issue 102: Donald asked about clarification about Functional Groups.
There used to be a formatting error, Alexey thinks it has been fixed
already. John isn't sure that the grouping in the current document is
correct, and asks for careful review by anyone who worries. Alexey
volunteers to look at it, asks for other volunteers, I'm too busy typing
to raise my hand.
Issue 116: Whether to add "(or HELO)" in places where EHLO is mentioned,
with text suggestions from Donald. Pete thinks John should do this even
if it's a painful chore, even if it's purely editorial fluff.
Alexey (as participant) thinks Donald's change is a clarification, for
example in regards to which commands reset SMTP transaction, or perhaps
that EHLO and HELO both need to be mentioned in a few more places. John
agrees that it's editorial fluff, except that Donald, Alexey and John
all looked at where it needed to be changed, all three lists differed,
and that suggests that there's no simple correct list of places to
change.
John suggests leaving the text, but will change if the WG provides a
list of places. Pete is happy to leave. Tero thinks it's a technical
issue and needs consideraiton, since the three of us don't read the text
in the same way.
John suggests that if we are to discuss this as a technical issue, then
the issue discussed should include whether to deprecate and remove HELO
entirely. After all, it has been obsolete at least for the two decades
since RFC 2821 and arguably since RFC 1425 three decades ago.
Alexey asks for two volunteers, Arnt and Pete volunteer. Pete suggests
that if we two agree, that's fine, and if we don't, the two of us will
decide which list is correct.
Alexey discovers that we're six minutes over time, thanks everyone for
coming, and wishes everyone a pleasant evening and a pleasnt meeting
tomorrow.
Session 2 (Friday)
Note Taker: John Levine
5321bis issues:
Issue 107: extra information in EHLO/HELO. Agree to change "clients
SHOULD NOT send extra text" to "... MUST NOT ...". John K will add note
this may make some old clients non-compliant. Ken notes existing grammar
does not allow extra text after EHLO. John K thinks long ago some
clients sent name and IP, wasn't a good idea.
Issue 114: sections 6.1 and 6.2, MUST NOT lose messages. Pete asks how
old is this text, John K agrees we tried to fix this wording and weren't
able to improve it. Pete says Don's text looks OK, concern that it might
miss something. John says changed in RFC 2821, changed in draft three
years ago, concern that we might later find we didn't say what we meant.
Murray does not understand how you would test "MUST NOT accidentally
lose", notes text is 20 years old, could leave it alone. Does
"frivolous" mean "don't write lousy code"? Many say yes. Alexey says
does it mean if you accept it, commit it to persistent storage. Todd
says big sites won't write stuff to disk, small ones might have disk
failures. This means "your persistent storage must never fail". Bron
says it means design for expected failures, e.g., daily reboot.
Bron and Todd will suggest some better text.
Change to 6.2: John notes document is already a pastiche of different
authors' styles, proposed changes are yet another. Agree to proposed
change.
Issue 119: mail gateways are described in 3.7 (and subsections) and
Appendix D which notes confusing envelope and headers causes trouble.
Alexey proposes move Appendix D to 3.7.6. Pete says Dave C would have
put it all in an appendix, but we split it. He's OK with the move. John
agrees with analysis, 3.7 is normative, App D isn't. but OK to move.
Wants people to check that he did it right. Jim Fenton asks if "must"
should be normative. After some discussion the room agreement that it is
not, because it is not testable.
Agreed to move Appendix D, we will all check.
Issue 118: IANA registry of SMTP reply codes. Donald observed that rules
for response codes looks like a registry rule. John and Alexey recall
there is no registry because we don't want to encourage new ones. John
says use existing codes and add enhanced status codes. Defining new
codes and distinguishing from existing codes is very hard. Also, new
codes are a compatibility problem since they will not be implemented for
a while. Pete agrees to not change.
Alexey talked to Don who can live with no change. So no change.
John offered to add a sentence saying to add enhanced status codes
instead.
Issue 103: subregistries created by MT-PRIORITY extension. John says
text is there at IANA's request. Murray will do a management item to ask
IANA to rename that registry and then we will remove text.
Issue 100: terminology in 4.5.3.2. Alexey says nobody has been confused.
John notes that there can be more than one mail buffer. Agree to no
change.
Other topics:
John notes changes to latest draft adding discussion of A/S in intro,
and text in security sections. Pete suggests moving security stuff in
intro into security section as security AD probably wants. John talked
to him, thinks this text is OK.
Tero says we need an e-mail roadmap, something we can write AFTER this
document is done. Can be updated as we add new stuff. As example, SPF is
a bad security feature but it's standards track. Pete notes A/S is
halfway to the roadmap. OK to add a few more sentences to security
considerations to get us over the line.
John says look at new text and comment on mailing list.
Murray talked to security AD, will have downref to A/S which has the
security advice. Alexey prefers informative reference to A/S, as does
John.
Can switch if there are objections during IESG review.
John asks do you want another draft soon? Alexey prefers yes so he can
close tickets. John wants to wait for text from Bron and Todd, which is
promised soon. Alexey asks for draft by Monday either way.
Tero says we have multiple temporary errors, behavior is different for
each. E.g., if "mailbox full" is returned, it makes no sense to try the
next MX, but other errors do. We have no advice whether errors are per
user, per domain, per server. Todd doesn't think it's possible,
providers don't use the codes consistently. John says these codes are
very old, predating MX. When MXes were added they decided to match
existing codes as best they could. Adding this to 5321 would take
months, so don't do that, it's 30 years too late. Could put something in
A/S describing what implementations do, maybe useful probably not worth
the effort.
Alexey says propose text for A/S. Bron says don't encourage indirect
mail flows because backup MXes don't really exist any more.
A/S open issues:
Issue 40: DSN extensions, changes OK.
Issue 78: In regards to discouraging %-encoding, John L says it should
forbid encoding local-part, not domain part. Ken will update the draft.
Issue 79: added ref to EAI RFCs. People thinks this is sufficient and
should resolve the ticket.
Issue 84: New text about reuse of header fields in new messages such as
replies. General agreement in the room that the text looks reasonable.
Issue 85: New text by Dave Crocker about what is sensible and not
sensible to do with Received header fields. General agreement in the
room that it looks reasonable.
Issue 94: quoted strings. New text by John L. Alexey is sad about
removal of examples of non interoperable email addresses. Alexey will
verify changes for empty local part. Also agreement to take out Keywords
example with "", as this is probably working.
Issue 92: CNAMEs, do changes in base spec to deal with this? People
should check if any further changes in A/S are needed.
Issue 93: Alexey will still suggest some text about SMTP authentication.
Issue 96: multipart/alternative. John K thought it was used for
different languages, but Pete notes examples in RFCs are plain text vs.
rich text, so agreed to close this ticket with no change. (We also
briefly discussed multipart/multilingual, which allows for multiple
languages)
Issue 97: more security and privacy text from Donald Eastlake, John says
need to take another look in light of changes to 5321bis. Jim notes
first bullet is unlikely since clients are never authenticated, only
servers.
Next steps
John will update 5321bis, leaving notes on various tickets in for now.
Propose interim in early December. Not sure whether to ask IESG to
review 5321bis sooner or do at the same time as A/S. Murray says send it
when ready. Can hold for A/S if needed to do in same telechat. Alexey
says chairs, editors, AD will confer when it seems to be ready.
Ken asks whether to do new version of A/S. Alexey prefers sooner.