Minutes interim-2022-emailcore-01: Fri 17:00
minutes-interim-2022-emailcore-01-202201211700-00

# EMAILCORE

* Date: Friday, January 21st, 2022 (1.5 hour)
* Time: 17:00-18:30 (UTC)
* Zoom:
https://us06web.zoom.us/j/89359071984?pwd=ZXZSOVBtc0RPWUl1RjhUUGlRZzZQQT09

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

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

### Scribes
* Todd Herr
* Pete Resnick

## Attendees
Todd Herr
John Levine
Alexey Melnikov
John Klensin
Barry Leiba
Pete Resnick
Ned Freed
Dave Crocker

## MINUTES
* G.7.10 Deprecated Source Routes (slides 8 to 11)
    * Presentation of proposed text on slides
    * Slide 8 - No comments
    * Slide 9
        * Leiba - Last sentence on slide 9 should change to "MUST NOT" from
        "SHOULD NOT" * Leiba - Suggest to change "SMTP servers SHOULD" on slide
        9 to "SMTP servers MAY" * Discussion between Dave and Barry about
        whether proposed changes do indeed deprecate source routes * Crocker
        make last sentence on slide 9 a new paragraph; Barry and Alexey concur.
        * Consensus from meeting attendees, with promise to discuss on list
    * Slide 10 - No comments
    * Slide 11
        * Klensin - Propose removal "only" from first sentence
        * Leiba - No objection, but why?
        * Klensin - "only" adds confusion, but not a big deal either way
        * Agreement that it either stays or goes
* G.7.3 Definition of domain name in Section 2.3.5 (slides 12 to 13)
    * Slide 12
        * Klensin elaborates on notes on slide. Asks if text belongs here or in
        A/S * Crocker - Text here modifies definition of submission server or
        is being redundant, neither of which seems like a good idea. * General
        discussion of bold text; some agreement on removing phrase "used for
        initial submission of messages" * Crocker proposes "Due to a history of
        problems, SMTP servers SHOULD NOT make such inferences." * More
        discussion; proposal of two sentences:
            * "Due to a history of problems, SMTP servers SHOULD NOT make such
            inferences. Among the range of functions that an SMTP server might
            perform, intermediate (relay) SMTP servers MUST NOT make them."
        * Klensin expresses concern that "Among the range of functions" will be
        flagged during Last Call as hand-wavy/too vague. * Resnick recommends
        something akin to the above text is fine, and that chairs defend text
        against any issues raised during Last Call.
    * Slide 13
        * Question is "Should discussion of DNS record resolution simply point
        to Section 5?"
            * Resnick - "Whatever"
            * Freed - "Whatever"
            * Melnikov - Ok, I give up :-). Leaving the current text in -08
            seems to address the ticket. * Crocker - A small extra issue: "may"
            in the second bullet should be "MAY". Others agree. * Klensin -
            Could adjust the text in the 1st bullet to make clear that it's
            simply descriptive. Some discussion, but no change desired.
* Exploders prohibited from adding List-* header fields (slide 14)
    * Slide 14
        * Leiba - Thought we resolved this on the last interim, but the bottom
        proposed text seems close to what we had. * Freed - Simply drop the
        sentence starting "However" to remove any discussion of what mailing
        lists do. * Crocker - (New Issue) The first sentence of that paragraph
        sounds like it's requiring the implementation of aliases and mailing
        lists, which is inappropriate. Levine and Freed agree. Crocker suggests
        simply removing the first sentence. Klensin suggests some context
        (perhaps defining MLs and aliases) might still be necessary. * Klensin
        - Will attempt a rewrite of the first sentence to attempt to capture
        definitions; if we don't like it, we can drop it.
* G.1 IP address literals in EHLO
    * Slide 15
        * Herr - Added this to try to capture that things might go poorly if
        FQDN is not used. Melnikov and Klensin think this is fine.
* Accepting Messages based on EHLO argument
    * Slide 16
        * No objections to inclusion of this text
* G.7.17 Hop-by-hop Authentication and/or Encryption
    * Slides 17-22
        * Herr - This is proposed text for the A/S
        * Levine/Freed - DKIM/SPF and PGP/S/MIME are not hop-by-hop. Those
        discussions should be dropped. * Leiba - Should mention message-level
        encryption, but say that it is out of scope for this document. *
        Crocker - The topic area is properly "Integrity and Confidentiality",
        the mechanism is "Encryption". Should be use that terminology? Leiba -
        Should at least define terms. * Klensin - ? * Freed - Opportunistic TLS
        is so widely used, it might need to be mentioned. Message-level should
        be mentioned and brushed off. * Resnick - We're not doing this because
        we think the A/S is only about SMTP, right? Agreed. * Crocker/Leiba -
        Clarify that "opportunistic" is encryption without authentication. No
        trust on first use implied. * Klensin - We do want to include things
        that are important to note in the current operational environment, even
        if they are things we don't like. * Melnikov - I think mentioning
        DKIM/SPF and PGP/S/MIME is the right thing, even though they are
        end-to-end. * Herr - Will edit text. Will get more input from WG. *
        Check recording for possible missed comment from Klensin
* Review Timeout Specification
    * Slide 23
        * Herr - This is proposed text for the A/S
        * Crocker - This seems to indicate people are not happy, but not
        operational problems, so this sounds right. * Melnikov/Leiba - Don't
        like second paragraph. * Herr - Then should we remove this discussion
        from A/S? Melnikov/Leiba/Freed think removal is OK. * Freed - Some spam
        mechanisms play with these long timeouts in order to delay "people they
        don't like". Going down this road in the discussion doesn't seem good.
        * Crocker - Could be helpful to keep 1st paragraph for context, and
        then explaining that different timeouts are operationally useful.
        Leiba/Melnikov don't think it's worth it. * Levine - The text is OK for
        an A/S. * Melnikov - Sounds like keep the first paragraph or drop it
        all, but ambivalence. * Herr - Probably should say something, but if we
        remove the second paragraph, maybe add a bit to the first. Will propose
        some text to the list.
* G.7.5 Improve description/definition of mailing lists, aliases, and forwarding
    * Slide 24
        * Freed/Crocker will work on some text on this in the not-too-distant
        future. Target 2 months for -00.
* Side note: Will be requesting a session at IETF 113, with a preference for an
afternoon session. * Victory for the day declared.