Skip to main content

Minutes IETF112: emailcore
minutes-112-emailcore-00

Meeting Minutes Revision of core Email specifications (emailcore) WG
Title Minutes IETF112: emailcore
State Active
Other versions plain text
Last updated 2021-11-17

minutes-112-emailcore-00
# EMAILCORE

* Date: Wednesday, November 10, 2021 (1 hour)
* Time: 12:00-13:00 (UTC)

* Meetecho:
https://meetings.conf.meetecho.com/ietf112/?group=emailcore&short=&item=1

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

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

### Scribe
Bron Gondwana (why not, I usually do)

## MINUTES

Notewell presented.
No Agenda bash

## rfc5322bis - close to WGLC

Pete asked on the list: anything else than what's in the slide for 5322bis?  No
response.

Pete plans to send out a new version next week, then go into IDLE mode.

### rfc5321 G.7.10 - deprecating source routing

John K: it's scattered in a lot of places - if I remove it, please review
carefully to make sure it doesn't screw something up!

Ned Freed: thought the idea was to remove discussion, not turn into
prohibitions.

Ned/John/Todd: Proposal should be "remove the sentence entirely".

Pete: if we remove it entirely, it won't appear in ABNF and not have historical
note - do we just pretend it didn't exist?  Or allow in ABNF and make no
mention?

Todd: slides all appear to be for option B.  Just say "was specified in RC821,
point to that".

Barry: there has to be something that says "it existed, look at 821" but pull
everything else.

Elior Lear: Prefer "MUST NOT be generated, MAY be parsed" - for parsing
historical mailboxes.

Todd: there's 5321 for wire and 5322 - parts might be in that.

Pete: was checking to see whether the parse syntax in 5322 covers it.  For the
command stream we don't need it.  It's only for 5322 that we need to be able to
parse them.   It's legitimate to say "we won't do that in 5321".

John: except there's no text in 5322 which says "when storing for further use,
you're forbidden to put anything there which 5322 doesn't set".  So there
should be a backward pointer somewhere.

Todd: seems like we're back on option A.

John K: but that means leaving a historical pointer, not taking it all out
entirely.

via chat: ABNF drops it entirely, just a tombstone in the narrative pointing
back to 821.

John K: will need to drop one of appendices C or F.2. Will check the current
text and decide.

Eliot: so seeing a source route is a 500?

Barry: expect it would be like any other invalid data, yes.

Ned Freed: as a practical matter, you're going to get a lot of 5YZ anyway, no
matter what we say here.

John L: Gmail and Hotmail ignore source routes, Yahoo 550 relaying denied.

### Revising quoted strings / comparison for equality

No comments on the example text?

John K: semantic equivalence should be changed to syntactic equivalence?

Ned Freed: that seems like a fine example, but if you want the really important
example it is that:

`"foo"@example.com <-> foo@example.com`

Wes Hardaker: in things like DNS - doing comparisons involve converting
everything down to a canonical form to compare.  So similar wording in other
parts of the IETF are to make things canonical for compare.

John K: with SMTPUTF8 there's other canonical form (defined by Unicode) that we
don't want to confuse with - this is just canonical quoting.

### Moving text about use of backslashes up (slide 20)

John K: agreed.

### Abstract update

No comments, treated as "no objection".

### Informative references to MIME and SMTP Submission RFCs

Pete: MIME is already mentioned in 5322bis.

John: want to limit references in 5321bis to the AS be as few and as
appropriately vague as possible, to minimize the risk of dependency on AS if it
doesn't get published.

### Recommended SMTP extensions

Ned Freed: the really important one is 8BITMIME

Ned: fine with enhanced status codes and DSNs being a MUST, but worry a little
about NOTIFY=SUCCESS.  Maybe need to sping up a quick update to RFC3461
deprecating support for NOTIFY=SUCCESS.

Ned offers to follow up and make sure such a document is written.

### Hop-by-hop authentication and/or encryption.

Will discuss in AS.

Ned: AS needs to say something about the security model that has emerged of
using TLS for security.

### Interim in December?

6th-10th and suitable for US.

Ned: would like to try an interim.

Barry will show up.

John L: will show up

Pete: am around.

## Suggested scope for AS

Barry: looks about right.  Ned agrees.

John K: agrees, although the statement about not touching RFC 6409 (SMTP
Submission) is likely need to be changed.

Bron: the large file problem -> will probably have an inderect interaction with
AS. Need to deal with at some point.

John L: got part way through specing extending the existing
message/external-body media type, in particular to add checksum and date.  If
we revise MIME, this should go there.

Bron: Big file also affect message storage (IMAP/JMAP).

Pete: sounds like we dust off the LEMONADE specs again.

# DONE after 54 min