# EMAILCORE * Date: Friday, March 25, 2022 (2 hours) * Time: 12:30-14:30 (UTC + 1) * Meetecho (remote or fully featured): https://meetings.conf.meetecho.com/ietf113/?group=emailcore&short=&item=1 * Onsite tool: https://meetings.conf.meetecho.com/onsite113/?group=emailcore&short=&item=1 ### * Jabber: emailcore@jabber.ietf.org * Notes: https://codimd.ietf.org/notes-ietf-113-emailcore ### Chairs * Alexey Melnikov alexey.melnikov@isode.com [onsite] * Todd Herr todd.herr@valimail.com [remote] ### Scribe * Todd Herr Delay waiting for John Klensin to address technical issues with remote connectivity... Agenda adjusted while waiting for Mr. Klensin ### Enhanced Status Codes requirements in A/S * Original text said MUST implement; proposal is to change text to say support is RECOMMENDED. * Levine from chat - "Looks reasonable" * Kucherawy from chat - "+1" John Klensin has entered the chat ### Ticket 11 - G.7.4 Clarification about Mail Transactions and Transaction State * Ticket appears to be resolved by earlier changes. * Recommendation is no changes other than to possibly insert the word "normal" into the sentence "There are three steps to SMTP mail transactions." ### Ticket 56 - Relax IANA registration policy for SMTP extensions * Two proposals * NEW-1 - extensions may be registered using Specification Required as per BCP 26 * NEW-2 - extensions may be registered using First Come First Served * Klensin recommends hybrid approach, details on list * Kucherawy - NEW-2 harder sell to IANA than NEW-1 or hybrid * Crocker from chat - "Using registration as a quality control mechanism makes sense when the registration namespace is limited, or the operational dangers of registering 'poor' entries is dangerous. Neither seem to apply here. Specification Required ensure a single reference, but does not get into the game of quality control on the work." * Leiba - Goal is to have people register what they're using. Volunteers as designated expert to approve everything if Specification Required is the choice. * Melnikov and Klensin express concern about possibility of free for all registrations. Don't want things that are "looney" e.g., "My Shiny Balloon" * Levine - We're not the network police; people will do bad stuff regardless of what we do * Crocker from chat - "//sorry. I mis-remembered Specification Required. Given the choices, FCFS should apply. Yes, that can produce useless registration. That is too bad for what is being registered, but doesn't hurt general SMTP use." * Discussion in chat about whether need for expert is too high a barrier in both effort and time * Levine volunteers in chat to be co-expert with Leiba * Leiba proposes "First Come First Served with a reference provided, but highly RECOMMENDED that proposer post to emailcore mailing list for feedback and discussion" * Melnikov prefers mailing list post happen first before registration. Similar to how Media Type reviews are done. * Leiba asks if registration can still happen even if mailing list feedback is negative * Murchison - Want to make sure we don't have name space collisions that might result from two different vendors both using a given name to mean two different things * Crocker expresses concern that we're trying to propose revised IANA procedures, sowing confusion. * Klensin in chat and in voice proposes "Then one provides provisional registration that gets the name into the registry and allows the registrant 60 days to listen to discussion and amend things before the registration semi-automatically becomes permanent" * Crocker still feels like this is revised IANA procedures. Conditions create opportunity for confusion. Goal of working group is minimal changes, not whatever changes seem like a good idea. * Klensin and Crocker discuss further * Gondwana from chat - "we can always fix this later right? If the registry gets filled with s***, we can do an IETF consensus document to change the registry and clean out the nonsense" * Resnick argues for First Come First Served without condition, working group can engage registrant if group has questions. * Leiba now ambivalent; proposes leaving text as is or go with Specification Required as path of least resistance * Crocker from chat - "The nature of FCFS is well-understood. Although perhaps a 'bigger' change, it fixes the problem. Anything else doesn't." * Resnick from chat - "Specification Required is less change than FCFS, which would lean in favor of that. But I still favor FCFS." * Gondwana from chat - "I can't reliably talk, but I'm right here with Dave. Let's just FCFS" * Crocker and Leiba agree that FCFS is the better approach, even if it's significant change * Happel from floor wonders if we're spending a lot of time discussing something that's little used? * Agreemnt in the meeting that we've spent too much time on this topic. Move to list and move on. * Melnikov delegates to Leiba to follow up on mailing list ### VRFY in required commands in 4.5.1 * Levine believes no one implements it any longer other than responding with 252 * Levine recommends leaving text as-is * Proposal is no change in base spec, we can discuss on mailing list the idea of putting extra text in A/S * Klensin: shall I check existent text about VRFY for consistency and possibly suggest clarifications? * Melnikov (as a chair): yes, please ### Restricted-capability clients? * Section 3.3 text is as issue. * Do we need clarification on just what such a client is? e.g., printer that sends notifications to a single address, OR * Is this text about open relays? * Levine proposes that we make it clearer just what a restricted-capability client is * Resnick wonders if the text should just say "clients" * Crocker wonders if the text has caused any problems, points out that it's confusing, suggests dropping it or keeping it, not modifying it * Klensin - Text quoted repeatedly out of context. Previous sentence not included in discussions, and the quote misses the first word of the sentence ("Consequently...") * Pushing discussion to list in the next week or so * Resnick following up on chat discussion with Klensin - "If we can figure out what it means, let's fix it, but what if we can't figure out what it means?" * Klensin - If we can't figure out what it means, let's drop it. ### null mx vs. server domain in 4.2.4.2 (issue 62) * Consensus of discussion is no change to document (5321bis), meaning 550 should be the response ### G.7.9 Discussion of "blind" copies and RCPT * Slides a bit out of date due to ongoing discussion on list, but no alternative text has been proposed * Klensin and Resnick to collaborate on proposed text, post to mailing list for discussion ### Exploders seem to be prohibited from adding List-* header fields * Four options presented * Melnikov asserts he and Klensin prefer either option 3 or option 4 * Initial consensus is option 3 - Replace sentence with "This change to MAIL FROM doesn't affect the header section of the message." * Follow on discussion... * Crocker from chat - "1. SMTP does not get to dictate what list exploder do, since their activity is quite long after message delivery. 2. Do we have documentation of a significant operation problem that making a change here will fix?" * Melnikov proposes staying with option 3 ### Hop-by-hop Authentication and/or Encryption * Rev 4 posted to the list; Melnikov has commented * Herr to post rev 5 to list based on Melnikov's comments. Two weeks for on-list discussion, after that Ken can incorporate into next revision of A/S. ### G.3 Meaning of "MTA" and Related Technology * Question 1 - "sender-SMTP" and "receiver-SMTP" vesus "SMTP client" and "SMTP server". Proposal: no change * Klensin points out that 5321 currently contains both. Minimal change says leave as-is; maximal clarity says clean it up and make it consistent. * Resnick agrees with minimal change * Kucherawy from chat - 'You could add a sentence near the top that indicates this document uses "sender-SMTP" and "SMTP client" interchangeably, and change nothing else.' * Melnikov as participant agrees that leaving as-is is best * Murchison asks if he has to update A/S text * Resnick echoes Kucherawy's recommendation for clarifying text (i.e., "both terms are used") * Happel expresses preference for sender and receiver over client and server due to ambiguity in use of client (e.g., client could mean MUA) * Crocker in chat - "Since 'server' seems to have become a socially insensitive term, sender/receiver is the socially safer choice." * Klensin - Use of sender and receiver in document seems mostly to be in context of reference to dual-function entities * Question 2 - definition of MTA * Suggestion to do no change. ### Discussion of whether to have next interim and when * Klensin wants to make case for people to work on things on mailing list first; easier to transcribe changes from there, list is supposed to be primary place for working group work. * Melnikov agrees, but asserts that it seems like interims push things forward in ways that list doesn't * Klensin agrees, proposes scheduling interim but canceling if we manage to get work done on list * Chairs will propose date for next interim next week * Kucherawy mentions he'll be unavailable for April ### Open discussion * Happel raises topic of sub addresssing (e.g., todd+ietf@example.com) * Leiba believes topic out of scope for the SMTP document