Minutes interim-2021-emailcore-01: Thu 17:00
minutes-interim-2021-emailcore-01-202112091700-01

# EMAILCORE

* Date: Thursday, December 9, 2021 (1 hour)
* Time: 17:00-18:00 (UTC)
* Zoom:
https://us06web.zoom.us/j/89359071984?pwd=ZXZSOVBtc0RPWUl1RjhUUGlRZzZQQT09

###
* Jabber: emailcore@jabber.ietf.org
* Notes: https://notes.ietf.org/notes-emailcore-interim-dec-2021

### Chairs
* Alexey Melnikov alexey.melnikov@isode.com [virtual presence]
* Todd Herr todd.herr@valimail.com

### Scribe
Todd Herr

## Attendees
Barry Leiba, Futurewei
Alexey Melnikov, Co-Chair
Todd Herr, Co-chair
Ned Freed
Dave Crocker
Mark Mackenzie
Randall Gellens
John Levine
John Klensin
Pete Resnick

## MINUTES
Meeting starts at 17:05 UTC

Alexey notes that meeting is being recorded.

Welcome and introductory slides, including IETF Note Well and IETF Code of
Conduct.

Agenda slide shared.
* Ticket 17
* Ticket 9
* Ticket 15
* Ticket 55
* Ticket 4
* Ticket 12
* Ticket 3

### Ticket 17 - Deprecating Source Routes
Slide 8
* 4.1.1.3 - 2nd paragraph in -07 - Dave Crocker asks if "mailbox" is the
correct technical term to use in the proposed text. * Crocker: "Ultimate
destination" could be confusing if this text is in context of current SMTP host
* Klensin: Is "inserts it into the destination mailbox" correct at all,
considering use of IMAP/POP and how delivery is working these days? * Group
discussion (Freed, Crocker, Klensin, Melnikov) on alternative to proposed text,
or whether text is even needed. * Agreement to note that this text is
problematic, further discussion to be held on-list

Slide 9
* Freed - The less said about source routes, the better.
* Klensin - If source routes are mentioned at all, should be moved to Appendix
F.2

Slide 10
* General consensus to move examples to Appendix F.2

Slide 11
* Melnikov - Should italicized, bolded text be deleted? This is the 2nd
paragraph in Appendix F.2:

>  Clients SHOULD NOT utilize explicit source routing except under
>  unusual circumstances, such as debugging or potentially relaying
>  around firewall or mail system configuration errors.

* Crocker - Yes, delete

Slide 12
* Klensin - Will take shot at rewriting Appendix F.2, will post new version to
list, wants promise that people will look at it.

### Ticket 9 - Definition of Domain Name in Section 2.3.5
Slide 13
* Melnikov - Are the terms "alias" and "nicknames" the same in this context?
* Crocker - "alias" here conflicts with different use elsewhere in the document
* Crocker - Technical point here is "relative" vs. "absolute". Perhaps using
those here might help? * Klensin - Should we draw a clearer line between what
submission servers do and what relays do? * Melnikov requests that Klensin
propose text; Klensin reluctant to propose text unless there's agreement that
change should be made. * Crocker - Not sure what people think is important in
the text vs. what's nice * Gellens - Could we say "host alias" rather that just
"alias" in the text here? * Crocker - Asks for clarification on meaning of
"host alias". FQDN has meaning that is clear and specific. * Some agreement in
the meeting that "host alias" is better than just "alias" * Crocker and Freed
exchange regarding meaning of FQDN on public internet vice private networks *
Crocker - First paragraph should specify "global syntactic uniqueness" *
Discussion of what that means and how to represent it * Suggestion to change
"is the entire, fully-qualified name" in first paragraph to "MUST be the
entire, fully-qualified name". * Crocker - First bullet might be better located
in EHLO description rather than this section. Second bullet should be elsewhere
in document as well, rather than in section 2.3.5 * Mackenzie - Still value in
keeping first bullet in section 2.3.5 * Final tweaks to be handled on mailing
list

Slide 14
* Crocker - Section has done its job if the word "resolvable" is removed from
the first sentence in Paragraph 3 * Crocker - with this change this seems to
overlap with what paragraph 2 is saying. It looks like the paragraph 2 can be
removed and the paragraph 3 text is sufficient. * Levine (in chat) - Sounds
right * Gellens - Wording seems convoluted. Alternative: "Domain names used in
SMTP MUST be FQDNs"

### Ticket 15 - 'Blind' copies and RCPT
Slides 15 and 16
* Crocker - Not sure why 5321 would talk about blind copies at all; blind
copies are a 5322 construct * Resnick - Blind copies are discussed in 5321
because of "FOR" clause * Further discussion, leading to decision to discuss
topic on-list * Klensin - Choices are
    * Favor privacy, debugging and tracing be damned
    * Favor debugging and tracing, privacy be damned
    * Alter SMTP protocol(?) to signal whether privacy or debugging is preferred
* Second suggestion to move discussion to the list. May need second interim to
resolve issue. * Resnick - Is possible outcome to remove this topic from 5321,
or might that affect document status?

### Ticket 55 - FOR clause in Received Header field
* Discussion from previous slides on-list will impact how to address this
ticket.

### Ticket 4 - Exploders prohibited from adding List-* header fields?
* Crocker - Topic seems outside scope of RFC 5321. For mailing lists header
fields are added after delivery. * Klensin - Half agree with Crocker - Maybe
need text to express distinction between aliases and mailing lists. * Crocker -
Aliases and Mailing Lists might be operationally different, but as far as SMTP
goes they're semantically the same (RCPT TO) * Freed - Both mailing lists and
aliases can be implemented within SMTP server, without delivery. * Freed -
Acceptance of that model means that 5321 must discuss the differences. A/S not
the right place. * Leiba - Text was intended to address what happens within
SMTP for things like internal aliases and lists * Resnick - "SMTP" at
protocol/architecture level is different than "SMTP" at implementation level *
Freed - We don't have a [separate] normative specification that discusses
Aliases and Mailing Lists * Crocker - Section 3.9 was necessary when 821 was
written, but topic has been overcome by events. Dropping this section and
creating separate effort to fix the topic would be a more constructive effort.
* Freed - We tried that once before; we tried to tell mailing list developers
how to implement things, but they didn't listen * Crocker - We're less naive
now * Klensin/Freed - VRFY, EXPN, 251/551 redirect are reasons to not remove
this section * Freed - Willing to propose text on-list * Crocker - Is this
document trying to be SMTP protocol document or an Email Service document *
Resnick - It's trying to be an SMTP protocol document, but legacy things that
snuck in over the years make clean up a challenge * Klensin - Cleanup takes
document back to Proposed Standard, which is not the status we want

Scheduled meeting time expired.

Recommendations to take remaining tickets to list, schedule an interim in
January, this time for 90 minutes (at least) vice 60.

### Chat Log

John Levine to Everyone (12:08 PM)
have we logged who is attending?
https://notes.ietf.org/notes-emailcore-interim-dec-2021
Alexey Melnikov to Everyone (12:08 PM)
https://notes.ietf.org/notes-emailcore-interim-dec-2021
Pete Resnick to Everyone (12:35 PM)
Sorry for being so late. Caught in another meeting.
I presume nothing for 5322bis has come up?
Todd Herr to Everyone (12:40 PM)
@Pete Correct
Pete Resnick to Everyone (12:40 PM)
👍
John Levine to Everyone (12:41 PM)
sounds right
FOR clause in received headers
Barry Leiba to Everyone (1:07 PM)
7 minutes over, I would say.
John Levine to Everyone (1:08 PM)
January
Randall Gellens to Everyone (1:09 PM)
Late January, after the 19th, please