### 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.