# 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