# 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