Minutes IETF108: emailcore
minutes-108-emailcore-00

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.