MINUTES Alexey and Seth co-chairs. There was no agenda bashing Proposals for session Barry Leiba (AD): want to correct the anomaly that the earlier versions are at a high standards level than the current version - so keeping the changes minimal. Seth: want to address existing errata and known issues. Minimal BIS for 5321 and 5322 plus core email applicability statement. Looking to find rough consensus of everyone here about scope/charter of what to do. RFC5322bis Pete Resnick: editor Pete: expect that this will be the easy one. Header field name length and ABNF - ok to do if we can do them safely, but they don’t seem to be causing interoperability problems. Empty quoted strings might impact 5321bis too. Seth: have seen an operational problem with the header name length - there was a buffer overflow in opendkim. Pete: But that was field value, not name. Dave Crocker: why not change it so there’s only one place that defines an email address. Pete: only trauma is that at this point in history, changing the documentation in a way that might cause some disruption. Nebulous concern. Bron Gondwana: should we put the spec in a separate document and then refer to that from both. Pete: the issue is that it’s referenced a LOT in the ABNF, but maybe that’s OK. John Klensin: There’s already lots of cross references between the two. Whatever we do, we probably can’t harmonise the two because 5322 permits the name phrase, but 5321 does not. We can’t get complete harmony, as SMTP syntax doesn't allow for display name. If harmonising, we should consider EAI and try to harmonise the whole lot! Barry: agree with merging - think it’s best to put in 5322bis. Should deprecate the earlier definitions. Viktor Dukhovni: ran into issues with folding References header field after 998 characters, and not necessarily at particular sensible locations. Might be worth specifying that they should be strictly folded at boundaries between different message-id values. Yoav via Jabber: Publishing an RFC in 2020 is different than 2008, might have pushback on privacy and security considerations - not being flavour of the day. We may be underestimating the work involved. Barry via Jabber: already socialised to SecADs. John Levine: agree that non-small changes will lead to heat-death. Pete: open to AD suggestions. Viktor - do you want a small note saying to wrap them at the boundaries. That would probably be in scope, but mandating would not. Seth - we’re at time. Pete: definitely let’s discuss these on the list (list TBA) RFC5321bis John Klensin: editor Quoting John K: In regards to the list of issues in Appendix G: I am just acting as recording clerk - not advocating for anything, but would oppose some changes personally too. Quoting - some systems have own quoting standards, single vs double quoting, confusion about what should and shouldn’t be backslash quoted. Obviously interacts with harmonising between the two specs. Viktor: don’t see a need to require backslashes. In postfix two consecutive spaces may collapse to one, which is a bug that should be fixed if that’s still there. Don’t think spec should require special treatment. John Levine: If I was doing this from scratch I’d do it differently, but don’t see any benefit to trying to change it now. John K via Jabber: while examples in slides have space, there are other ugly cases like “foo@bar”@example.com which need to be considered. Let’s not drop discussion for the wrong reasons. Bring back 1yz reply codes Harald Alvestrand: are they ever used in the wild? If not, should we care? Alexey: I don't know. This was proposed on the mailing list - so will ask proponents to discuss and propose draft. Applicability statement document suggested scope Alexey: proposal from slides - best pracices for SMTP, email format/MIME. Not IMAP/POP/SIEVE/JMAP Not Submission Not DMARC, etc (but maybe reference) Dave Crocker: applicability statements have strong intuitive appeal. This would be new work, seems not necessary for moving other specs to new standard - so suggest taking this out of the critical path. Alexey: things like practices saying “5321 has relaxed syntax, should use a more constrained subset”. Barry: Intent here is that the applicability statement will NOT get in the way of the other documents. Charter says moving 532[12] comes first. Seth: point of the applicability statement is to simplify, not to make more complicated. Pete Resnick: when Alexey/Seth suggested this, it would be a dumping ground for “this doesn’t belong in 5321/5322 bis” and can discuss these things in the other document. Suggested SMTP extensions slide Viktor: PIPELINING has caused issues but just an optimisation, don’t need it - reading spec carefully it’s good, but easy to get wrong. 8BITMIME can break things, so better if everyone needs to do it! Jim Fenton: would put STARTTLS on the list as well. Keith Moore via Jabber: would strongly prefer to leave EAI out. Ned Freed via Jabber: STARTTLS needs to be in. Seth: any other strong opinions? Alexey: think Enhanced Reply Codes is a no-brainer, should be MUST along with 8BITMIME (or at least recommended) Pete via Jabber: need to be clear what we mean by A/S. Post-protocol advice on operations can be useful. Terminology slide Viktor: Reference to 5598 is good, but don’t redefine. John K: via Jabber after audio issues. 5321 is a merge of many earlier docs because of not wanting to do a rewrite because of risk of breaking things. Need to be careful not to wind up doing that rewrite UNLESS WE INTEND TO DO THAT. Viktor back on 5321 bis… Two issues: 552/452 sore spot - the spec tells us to do. John has an issue for it in the Appendix G. Also asked about 554 greetings - is that a message level failure or “try another MX”? Could be clarified. Barry: if we have time at the end to talk about specific issues (i.e. do the work! that would be fine) - but let’s converge on the charter first. Tero Kivinen: have seen 421 errors with Gmail, but if you try a different user it goes through. Need clarification on what to do with error codes. IP Address literals in EHLO John L: we have to allow it in EHLO because it’s used for Submission from devices that don’t have names - but for SMTP it was a bad idea in the 80s and has only gotten worse Victor: +1 - on port 25 (not submission) if using literals expect friction. Keith Moore: against a restriction on IPs - because there’s lots of use of SMTP that’s not on the public internet, and we need to consider scope that’s wider than public internet. Should probably write a draft for longer version of this! Dave Crocker: distingish between what the protocol engine allows and the applicability advice for the public internet. Resolvable FQDNs and private domain names slide Keith: same - shouldn’t be encoded into the engine. Viktor: think “resolvable” is too strong. Move to applicability. Should be as qualitifed as makes it unambiguous between sender and recipient - that’s what fully qualified means, doesn’t necessarily need to refer to the DNS. Alexey: think it just means “not single component local names” Keith via Jabber: if it is intended to mean “don’t use single component names” then is should say that! Pete: (missed it, something about syntax) John K: there’s lots of top level domains and we decided it’s OK for them to have MX records! So we can’t disallow single-component names. Maybe we should have allowed trailing dot like DNS, but introducting now would be bad. Keith: don’t care what ICANN does with single top level domain names, we are free to disallow in email and we should! John K: they did it over my objections. For the last N years this has been valid. Viktor: on that topic, they are dead on arrival, they won’t be interoperable. John L: have been tracking MX records in the root zone. Can confirm they exist, and they don’t work! Would be doing the world a favour by recommending against them. Dave: shouldn’t encode prohibitions against things that are technically reasonable but operationally not into the specs. Charter redux Seth: no major surgeries - if we can delete great, but only add clarifications. Applicability statement should be modern best practices. Proposed Charter: 4 slides in total slide 1 no comments slide 2 Pete: published as standards track RFCs that are eligible to move to Internet Standard (e.g. widely deployed and interoperable) are the only ones that should be considered. Dave C: concerns Pete is raising are important, but excludes informational RFCs which may have things that are useful. Charter should not be written in a way to eliminate these documents. Alexey: agree with concerns, we can relax this - will it help us? Will probably slow us down. Barry: wording could say “at sufficient maturity level to move to internet standard”. Jim Fenton via Jabber: can we say “others with AD approval”. Keith Moore via Jabber: please let’s keep this WG on a short leash! Jim Fenton: AD approval is that leash. Pete: we want to have limiting instructions, but let’s not get too excited about the classification of RFC. Seth: we can work on the wording - keep the bar high. Dave, does that meet your concern? Dave: probably yes, thanks. slide 3 Pete: maybe some text in here making it clear that this document is not locked with 5321/2 bis. This will be published after. Dave Crocker via Jabber: Concern is that generic term A/S may not be clear enough. Not sure why content here doesn’t qualify as a BCP. slide 4 On completion take on similar work, if successful take on other work. Recharter will be required if so. Ben Campbell: isn’t this always true? Alexey: yes, but people concerned that this is all we’re doing. Ben: always seems odd that charters say “you have to recharter to do things” when we can always recharter! Pete: agree that this isn’t required, but charters have a social aspect to them. People on list saying “my things needs to be dealt with immediately” - we’re not shutting them out, just not NOW. Barry: agree with Ben and Pete. Useful but redundant. Tero: A good thing about this that it sets expectations about what group is supposed to do, and allows to tell people not to bring things now. Seth: of similar opinion - it’s worth the signpost even though it’s obvious. Saying “we do intend to look at this other work later” has value. Keith via Jabber: WGs can always be rechartered, but creating an expectation that a WG charter will be extended might be a bad idea. Jabber discussion: Pete: can a STD number point to a BCP? John K: not as I understand, and IESG have declined to consider proposals. Further discussion Barry: are there any objections to a charter approximately along these lines? Chairs - do you have a sense of when this charter will be ready? Alexey: hopeful only a couple of sentences that need changing - so next week! Should it be a separate mailing list? Barry: yes! Out of scope works stays on ietf-smtp, WG mailing list will be the new one. Other business Pete: think Victor brought this up - don’t think there’s any harm in bringing all the “suggested clarification” things to the list for discussion. Don’t think it’s worth doing any one of these here, but we should just do them all. Victor: TLS opens a can of worms, because it keeps changing from time to time and causes bitrot. Don’t know how we deal with that. Explicit versions can be deprecated. Alexey: please raise on the list if you haven’t already. Keith via Jabber: there should be a single reference to the acceptable TLS profile and other specifications should reference it rather than updating the spec every time the TLS recommendations change. Jim Fenton: without requiring exact versions and with fallback to plain text anyway, there isn’t a benefit to being very specific here. John: a strong recommendation for encryption would be appropriate, but making it mandatory would open a whole can of worms. There’s also relay encryption vs end-to-end. Think recommendation would be reasonable, but not a normative requirement reference. (discussion in Jabber about the single-component domain parts) Bron: we should be trying to make things illegal that we have allowed in the past, but we should say “don’t use these things on the public internet!” John: but if we allow these, we should go through the documents careful to make sure that they all work at every point (also affects the ABNF) James Galvin via Jabber: single label domain names are a security issue (SAC053 from 2012 tries to cover this). Single labels in certificates are not allowed. Policies can change in future, but we should bring it back into alignment.