Skip to main content

Minutes IETF113: emailcore
minutes-113-emailcore-00

Meeting Minutes Revision of core Email specifications (emailcore) WG
Title Minutes IETF113: emailcore
State Active
Other versions plain text
Last updated 2022-03-28

minutes-113-emailcore-00
# 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