# EMAILCORE   {#emailcore}

*   Date: Tuesday, July 26, 2022 (1 hour)
*   Time: 13:30-14:30 (UTC - 4)
*   Meetecho (remote or fully featured):
    https://meetings.conf.meetecho.com/ietf114/?group=emailcore&short=&item=1
*   Onsite tool:
    https://meetings.conf.meetecho.com/onsite114/?group=emailcore&short=&item=1

\###

*   Jabber: emailcore@jabber.ietf.org
*   Notes: https://codimd.ietf.org/notes-ietf-114-emailcore

### Chairs   {#chairs}

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

### Scribe   {#scribe}

### Minutes   {#minutes}

(Bron)

During Agenda - bashing:

*   John Klensin -> discussion of issue from mailing list today? Maybe
    do at the end.

Alexey: many tickets on AS -> hopefully many can be closed. Don't think
many will take a lot of time.

In memorium: Ned Freed. Passed away in May. Will be something in the
Plenary tomorrow. His counsel would have been very helpful in this room.

## G.14 the "for" in Received headers   {#g14-the-for-in-received-headers}

(Alexey takes off chair hat, Todd will be chair)

John posted a draft to the list.

Barry: think it's not sufficient to only do "if multiple recipients"
because forwarding the message can cause disclosure.

*   Primarily support 1.1, should deprecate it - only concern is whether
    it vioates minimal changes rule.
*   Think just saying "shouldn't do for new messages" is right.

John: explicitly allowed to deprecate stuff that hasn't worked out.

Alexey: dissenting opinion here

*   first, did a search on what existing MTAs do (Isode's and exim, will
    also check Sendmail)
*   Both only do "for" if there's a single recipient.
*   Sometimes it's useful to know if you're a To or CC recipient, or
    mailing list.
*   If message with single recipient goes to a mailing list, can see
    that it came through that path.
*   MTAs that I've seen don't make the mistake of leaking information to
    other recipients.
*   And of course MTAs can choose to split a single transaction with
    multiple recipients into multiple transactions, with single
    recipient, then they can emit it.

John: other option is to put 'for' on the sending end rather than the
receiving end.

*   Only option I'm opposed to is weakening the rule. Leaning towards
    options 2 and 3. Think MTA should be allowed to, so makes for 3
    only.

Victor: from postfix project.

*   Also, Postfix only adds for a single recipient. This is a trace
    header, and added at each hop.
*   2 is fundamentally flawed. Strongly vote for 3.
*   Lots of use cases where sufficiently knowledgeable users (and
    postmasters likewise) find it quite useful.
*   When I complain about spam, I want to know which is my aliases it
    went to.
*   Predicts that whatever the draft says, Postfix will continue to do
    '3'.
*   Language can be clarified to warn some hypothetical MTA.

Pete Resnick: strongly encourage 3. Deprecating is very bad. It's
useful. It's deployed as number 3.

*   Given our charter, we shouldn't mess with this.

John Levine: likewise agree with 3, but 3--. We have no idea how people
will route mail. Just note that "everyone after can see, if that's a
security issue, think about what you put there".

Barry Leiba: wanted to respond to all the above. There's no doubt that
it's useful for some people if it's there. You can't rely on it, it's
often not there. I'm OK if we decide in 5321bis that we go with three,
but also put something in the AS saying that we're advising against
using it because of the exposures. Find that the privacy implications
are stronger to me than the usefulness.

Bron: also support 3.

Pete: don't understand the serious privacy implications of the single
item, if it's sent to me and I forward it. If I need to clean it up
(strip FOR on forward), I need to clean it up.

Daniel Gillmor: also speaking in favour of 3. Think there are multiple
people in the room with opinions about how one should scrub email. Worth
noting here. Don't think deprecating it is useful:

*   deprecating reliance on
*   deprecating inclusion of

In favour of doing separate work on email scrubbing.

John K: in favour of 3--. Move all to the AS, strip out the existing
text.

Victor and Pete both agree - we should fix the sentence as proposed on
the slide. Barry also nods. Pete: don't feel really strongly, but
inclination is to just fix the mistake rather than ditch it. Think the
proposed fix is fine.

John K: problem with a lot of this is too much redundant text which says
almost the same thing in almost the same way over and over.

## relax IANA registration policy   {#relax-iana-registration-policy}

Alexey: this turned out to be less controversial on the mailing list
that I expected. It looks like Barry's proposal as modified by John L.
and Dave Crocker is acceptable for many people.

John K: no sword falling. Question: do we have any real world cases
where somebody has proposed something and found the current process too
burdensome?

Alexey: assumption from someone on the mailing list that if people don't
support the draft, then there is objection to registration. It doesn't
quite work like this. I think with helpful and friendly experts this
won't be a problem.

Victor: expert review sounds excellent, in fact I'll be an early user
before too long.

Barry: is everybody happy with this? Yes - many thumbs up (John K
sideways thumb)

# AS ISSUES   {#as-issues}

## Hop-by-hop authentication   {#hop-by-hop-authentication}

Proposal mini WGLC on the issue. Shall we call it closed?

## Octet limit ticket (38)   {#octet-limit-ticket-38}

Pete: proposal "make me write less text" -> someone posted an errata

John: don't think there's even a problem here.

Pete: what do you want AS to even say? Will work offline on some text,  
Pete will propose, Ken will bug. And include John K in the loop.

The three will discuss some text and bring it to the list.

## quoted string definition (35)   {#quoted-string-definition-35}

Alexey: suggestion is to close as "done". Will double check on the list.

## Cover message format elements in web forms (51)   {#cover-message-format-elements-in-web-forms-51}

Raised by Ned Freed.

Many web forms are too strict (don't even allow +).

Add text saying "based on ABNF you should be accepting this stuff"

Barry: what about internationalised email addresses? Do we want to go
there in AS?

*   Alexey: good point, maybe a separate ticket?

Bron: is there any point? Would forms even listen?

*   Alexey: it's good to have something readable in an RFC to point
    people to.

John K: it's good to have something to point to in relatively clean
english, not ABNF.

Hans-Joerg: think this is a very useful thing. See Bron's concern, but
in my personal experience - I find on a weekly basis there are bad
migration algorithms. Much done in libraries, so if we can find library
developers and show it to them.

*   Would also be useful to have a repository of example data.

Alexey: can probably collaborate and find things.

John Levine: browsers have an email validation thing built in, and they
say it's a subset of what's allowed but it what is actually being used.

*   Should check with Mark Nottingham or somebody - we really HAVE to
    get these in alignment.
*   Alexey: good point we should do that.

John Levine: apropos the Unicode, see no pattern in what EAI addresses
actually allow, so we can figure that out separately.

Ken: would it be sufficient for the AS to reference the document that
webforms have?

*   Alexey: looking at regexes breaks brain.
*   John L: their pattern isn't perfect, maybe we should offer them
    something better.

John K: there's an active feud going on between WhatWG and W3C about
things like this. Don't want to pick sides.

Victor: Can volunteer to write fairly advanced regex. Not scared by
them.

*   if people want a regex, there's several proposals. But would like it
    in plain english first.

DKG: definitely think we should excert what influence we have on
standards bodies, including a regex if necessary.

*   Main thing we need is a test suite with examples and why they are
    valid.

Alexey: Ken, you have enough for initial text I think.

## What should we say about MIME in AS?   {#what-should-we-say-about-mime-in-as}

Barry: Think we should say a fairly minimal amount about MIME. Think
once we're done with the first two BISes, we will probably revise MIME.
For now we should say "MIME is widely implemented, go look at it".
There's some +1s.

Ken: Are we looking for normative text? You should look into this? You
SHOULD support this, these parts have never been used?

Barry: not now, we should just say "this is widely deployed, it's
documented here".

Alexey: doesn't have to be normative.

## Requirements for Domain Names and IP in EHLO (19)   {#requirements-for-domain-names-and-ip-in-ehlo-19}

Think it should be closed (subject to mailing list confirmation).

John K: happy to close this one, deal with the other IP thing.

Alexey: This is the next slide.

## IP addresses as literals (1)   {#ip-addresses-as-literals-1}

Should be closed too.

## Review timeout specs (16)   {#review-timeout-specs-16}

Proposal to close the ticket and do nothing in AS.

John K: Could put some text in the AS which suggests that in the modern
world those timeouts are quite long. But not strongly for it.

# John's thing from the start   {#johns-thing-from-the-start}

John K: suggested "MUST" from the list, but person arguing for a SHOULD.
Don't understand what's happening.

Barry: Just need to capitalise "SHOULD not" to "SHOULD NOT".

# SMTP Tickets   {#smtp-tickets}

### 62 -> null mx vs server domain   {#62---null-mx-vs-server-domain}

*   Discussion was that current text is OKish, should close.

### 61 and 12 (mailing lists)   {#61-and-12-mailing-lists}

*   Ned proposed to write a document.
*   Alexey: suggest we do nothing, as we don't have collective energy
    for this.
*   If people write a document on it later, we can incorporate that
    later.

John K: making this go away so I don't have to do anything is fine!

Barry: does this mean we're ready for WGLC after the next update?

*   Alexey: YES!

## Ticket 57 -> enhancement request   {#ticket-57---enhancement-request}

Won't do this now.

# AS ISSUES   {#as-issues-1}

*   will probably close everything (40 => to the mailing list)
*   number 8:

## 8. add a new IANA registry of header fields   {#8-add-a-new-iana-registry-of-header-fields}

Ned was a big proponent initially, but wasn't keen to do it either at
the end. The discussion finished 1 year ago.

Alexey: close with doing nothing is probably the best thing.

# Summary   {#summary}

Will probably WGLC in September.

Some work to do on AS.

Will have a call for opening new issues soon. If people see things that
need doing, now is a good time to raise issues?

Barry: is plan to send 5321 and 5322 bis to editor together and AS later
(not with)?  
 \* Alexey: depends if seems close to being ready.  
 \* Barry: thinking of burden on IESG. Prefer to get first two dealt
with before they have to deal with AS.

John K: if we're doing to send 5321bis and 5322bis to the IESG without
the AS, we'd better be very careful that the AS doesn't say anything
which contradicts.

Pete: question for Murray -> are you OK with running the first two
together?

Murray: can even warn IESG that the other doc is coming. Can help this
out.

Anything else?

Murray: thanks for the progress, this is great.

Alexey: thanks everyone. Maybe we even recharter next time!