Skip to main content

Minutes IETF111: emailcore
minutes-111-emailcore-00

Meeting Minutes Revision of core Email specifications (emailcore) WG
Title Minutes IETF111: emailcore
State Active
Other versions plain text
Last updated 2021-08-03

minutes-111-emailcore-00
### Scribe
Bron Gondwana (w00t)

## MINUTES

Slide sharing: was better using meetecho than presenting from computer.

No agenda bashing

Alexey Melnikov presenting

### Trace header fields

Tried to get resolution on lone Return-Path last time.  Do we care?

Ned Freed: when you're composing a message, you can use Return-Path to
represent the SMTP "MAIL FROM" - and you don't have Received at that time.

Alexey: ok, interesting use case.

Dave Crocker: requirements -> something that should be there when things won't
work if they aren't there.  Don't see any reason to impose requirements that
aren't essential to the operation of the system.  Having a lone return path
seems fine to me.

Alexey: to rephrase -> won't break anything if lone Return-Path is encountered
in the wild. Software doesn't enforce requirement to have Received if
Return-Path is present.

Barry Leiba: agree with Dave.  We should say what Received fields are and what
they're used for, but not mandate.

Dave: all sorts of operational reasons to WANT Received fields, but don't need
to make it mandatory to the protocol.

Viktor Dukhovni: agree lone Return-Path is OK.

Pete Resnick: think Ned has made a reasonable case for a reason to have
Return-Path without Received headers.  If you have one, it must mean it's
traversed something, but Ned's answer is reasonable.

John Klensin: not sure if an issue for SMTP.
Alexey: think it's fine, as SMTP dictates when Received and Return-Path are
added. SMTP is more restrictive in this sense, which is fine.

Alexey: I think we have consensus in the room that a lone Return-Path is OK.

ACTION: text and ABNF needs to be updated to allow for Return-Path without
Received.

### Can other fields exist between Trace and Resent-* fields?

Currently allowed by the ABNF.

Barry Leiba: trace header fields within a particular group (Received, etc) are
ordered, but order with respect to other fields is irrelevant, so this is fine.

Alexey: no reason to restrict this, and don't think anybody will enforce
checking.

ACTION: current ABNF in the document is fine in this respect, so no change is
needed.

Pete Resnick: plan is to publish, use doc to check on list if this is right.

Viktor Dukhovni: Postfix adds 'Resent' at the bottom of the header block, and
this has never caused a problem.

Pete: syntactically not a problem.

### RFC5321 beter definition of trace fields

Suggest that the current definition of Received header field get moved to a
subsection of 4.4, with 4.4 becoming an introductary section defining trace
header fields.

No comments, no objections.

John Klensin: is already in the working document as a comment.

Dave Crocker: section 2.3.10 is using terminology that isn't all that well
defined and/or is outside the scope of SMTP  (Gatewaying is outside the scope)

Alexey: ok but that's a separate issue, not currently under discussion.

John: disagree with Dave's analysis, will deal with when we get there.

Dave: I see the word gateway!

John: the decision to include that word was an explicit choice.  Happy to
discuss again.

Ned: I couldn't see the word gateway on the slide?

### Slide 11 (3.6.3 and 7.6)

No comments or objections to adding "and possibly other trace fields" (Barry
and Ned +1 in chat)

### Ticket 20: removal of SEND,SAML,SOML

Only mentioned in appendix now.

Ned/Barry agree with proposed changes (Ned's suggestion, as updated by
Alessandro/Alexey)

### Ticket 14: Review of size limits

Todd Herr (chair): ticket asked whether size limits were correct and well
enough defined.  List discussed and said we can't change size limits.  Question
is "is text sufficient"

Alexey: does anyone want to comment on size limits?  Nobody did.

Barry: question - do we need to change text?  I don't think we need to.

Alexey: happy to close the ticket without changes.

Barry: who opened the ticket?  Alexey: Based on notes from John's document. 
Barry: OK, guess we're done.

### Extension keywords starting with X

Alexey: seems to be an agreement that they not be made special.

Barry: we've completely deprecated X, so yes.

### private-use commands with X

Alexey: suggest to drop entire section.

### change "MUST be registered unless X" to SHOULD be registered

Allow IESG-approved informational RFCs?

Dave Crocker: temptation to be strict for quality control, but main purpose is
to avoid collision?

Ned: would add "to enable people to document existing practice", particularly
widespread existing practice.  E.g. Microsoft uses their own auth.  Would
rather capture data in some form - allow registry to have different criteria
levels like with media-types.  But more information is almost always better.

John L via jabber: do specification required or FCFS.

Dave Crocker: do we have to require a spec at all?  Not just IETF spec, any
spec would be sufficient to handle point that Ned is making.

John Klensin: this would slide towards "register whatever you want to", but
it's a fairly major departure.

Barry: we're succesfully used FCFS with specifiation strongly encouraged
before, but put registration template a specification pointer.  No expert
review, just asking people to provide a specification somewhere, and it's
worked.  We should do something like that.

Alexey: some form of consensus in the room to reduce restriction.

ACTION: discussion on mailing list about relaxing restrictions -> Barry will
suggest text on the mailing list.

### Ticket 30? Erratum 4055 -> remove reference to SPF/DKIM

Dave Crocker via Jabber: drop first sentence

Barry: text isn't quite right, we could fix it to describe DKIM/SPF properly
but why not just drop it?

Victor: also agree, why not drop one or both sentence.

ACTION: go with "Verification of the Return-Path is outside the scope of this
specification"

John K already dealing with this.

### Ticket 19 - requirements for domain name and IP address in EHLO

Ned Freed: what does "verification" actually mean? The text doesn't seem to
suggest any action.

Todd: proposal is that the client may verify and possibly log/etc.

Ned: why not move whole thing to applicabilty statement?

Victor: can log the value or record it in the trace headers.  Rejecting on that
basis is too fragile in general without additional signals.  Commenting "not a
good basis for rejecting" could be in scope.  Good to not encourage people to
block based on it.

Dave: maybe applicability statements are more useful?  But often not given
attention by implementers.  Like proposed text in protocol to flag issue.

Barry: understand Dave's issue.  Suggest applicability statement is a formal
update of base spec, so keep base spec to protocol and not put advice into it. 
But make sure there's a forward pointer.

Todd: so -> move entire paragraph to the applicability statement, but have a
pointer stay.

John K: nothing prevents us from putting a forward pointer here.  Would lose no
sleep over holding this until applicability statement is published.

Victor: this tells senders to be careful what they send, but doesn't tell
recipients not to reject.  There should be some discouragement in the text for
rejecting.

Alexey: Victor, can you please suggest text?

ACTION: Victor to suggest text on the mailing list.

Allessandro Vesely: the text needs to put value in the EHLO name.  Random
value, not important.

Todd: you can contribute to the discussion on list if that works.  OK.

### Use of top-level domains where FQDN is expected not interoperable

Alexey: Didn't get to specific text.

John Levine: Would go stronger.  TLDs have never worked in mail, though some
people do it as a gimmick.  Should make it stronger.  MUST NOT.  Don't do it,
don't expect it to work.

Alexey: John L, can you suggest some text?

John L: Sure.

Victor: Agree.  user@cctld will not go anywhere.  On local networks, people do
short names - they get punished later when they connect to the internet but
that's their choice.

Dave: not disagreeing with anything said so far.  Have A/S discuss issue to
note problems.  Reason it's worth going into detail because there are people
who want to have their top-level domain work this way!  Detail enough to scare
people!

John Levine: have been a couple of requests to ICANN to put A records at the
top level.  No MX or A at the top.  Will only occur in a cctld because they
want to do clever things.

ACTION: John Levine to suggest text on the list.

## AOB?

Discussion about IANA registry (ticket #8) - Alexey will get to later this week.

John K: plan right now is to wait until registry consensus call and minutes
come out, then generate a new version of 5321bis.  Will not be this week.  Hope
it will be in the first half of August.

Hopefully this time not go silent until next IETF!

Done at 55 min, thanks from chairs.