Benjamin Kaduk has entered the following ballot position for draft-ietf-dmarc-rfc7601bis-04: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I also appreciate the efforts to reduce the diff between RFC 7601 and this document; it does help readability greatly. (I also support Ben's Discuss.) Unfortunately, it also can obscure some aspects where the text of the document did need to change as part of the update, but has not done so. For example, in Section 1: There exist registries for tokens used within this header field that refer to the specifications listed above. Section 6 describes the registries and their contents and specifies the process by which I don't think all of this is still present anymore. (If we were talking about registration policies, for example, we'd need an 8126 reference to replace the 5226 reference that was removed.) entries are added or updated. It also updates the existing contents to match the current states of these specifications. [We should double-check that everything that now allows EAI-formatted stuff is updated to also refer to this document from the IANA registry. On first glance this might include vbr.mv and vbr.md, but probably much more.] Don't we need to mention the updates (or obsoletes) relationship w.r.t. 7601 in the Abstract and Introduction? Section 4.1 has: MUAs and downstream filters MUST ignore any result reported using a "result" not specified in the IANA "Result Code" registry or a "ptype" not listed in the "Email Authentication Property Types" registry for such values as defined in Section 6. [...] This would seem to be an internal inconsistency, in that it seems to preclude any sort of experimental usage as described in Sections 2.7.x. In Section 2.3: Combinations of ptypes and properties are registered and described in the "Email Authentication Methods" registry, coupled with the authentication methods with which they are used. This is further described in Section 6. The relevant subsection of section 6 is a pretty empty stub now. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks you for updating in response to the secdir review! Are we now intending to restrict ourselvesto domain-based authentication schemes, having removed the disclaimer present in 7601 about the intent of the document? Section 1.1 In particular, the mere presence of this header field does not mean its contents are valid. Rather, the header field is reporting assertions made by one or more authentication schemes applied somewhere upstream. For an MUA or downstream filter to treat the assertions as actually valid, there must be an assessment of the trust relationship among such agents, the validating MTA, and the mechanism for conveying the information If this document is reporting assertions made upstream, we should say what kind of integrity and authenticity guarantees we do or do not provide for the reported information. (That is, "this header is transmitted in cleartext and could be modified by any agent along the delivery path", modulo the speculation we have later about potential ways to improve on that situation.) Section 1.6 goes a bit farther in this vein; maybe a forward reference is in order? Section 1.4 Isn't there a requirement to drop this header on the boundary, if there are any internal consumers? This is not a global requiremnet on existing servers, of course, but a deployment consideration that may affect existing servers. The end of section 7.1 seems to cover this situation pretty well, as well. Section 1.5.1 Please consider using the RFC 8174 version of the BCP 14 boilerplate. Section 1.5.4 o An "intermediate MTA" is any MTA that is not a delivery MTA and is also not the first MTA to handle the message. Is this intended to be global or within an ADMD? Section 2.2 I guess wouldn't be a whole lot of value in subtyping Keyword to have one symbol per registry, though the thought did occur to me while reading. Section 2.3 body: Information that was extracted from the body of the message. [...] interest. The "property" is an indication of where within the message body the extracted content was found, and can indicate an offset, identify a MIME part, etc. I'm not seeing where it's specified how the "property" gives an offset. I see other descriptions below about specific header fields and SMTP verbs and such, though. (Do we need to make it more clear that the "property" is defined within the context of the method?) The results for Sender ID are listed and described in Section 4.2 of [SENDERID], but for the purposes of this specification, the SPF definitions enumerated above are used instead. Also, [SENDERID] specifies result codes that use mixed case, but they are typically used all lowercase in this context. We use much stronger statements about lowercasing than "typically", elsewhere in this doc. Is this time different? Section 2.7.6 Experimental method identifiers MUST only be used within ADMDs that have explicitly consented to use them. These method identifiers and the parameters associated with them are not documented in RFCs. Therefore, they are subject to change at any time and not suitable for production use. [...] This part seems to value RFC status too highly -- earlier in the section we only say that they should "preferably" be published in an RFC. Section 2.7.7 Do we want to say that temporary registrations are available for wide-scale or long-running experiments? Section 3 of the validity of the connection's identity using DNS. It is incumbent upon an agent making use of the reported "iprev" result to understand what exactly that particular verifier is attempting to report. Does that in practice constrain "iprev" usage to within a single ADMD? Section 4.1 MUAs SHOULD ignore instances of this header field discovered within message/rfc822 MIME attachments. When would I want to not ignore it? Section 5 I guess there's not really any special behavior to worry about when a message's path causes it to have two or more disjoint path segments in its delivery path that go through a given ADMD. (That is, delete on entry is still the right thing to do.) The last paragraph of Section 1.2 covers a related case, but I am thinking of something like a message that gets delivered to an expander and some of the recipients' delivery path would then return through a previously visited domain. For example, an MTA for example.com receiving a message MUST delete or otherwise obscure any instance of this header field bearing an authentication service identifier indicating that the header field was added within example.com prior to adding its own header fields. [...] Do we want to say anything about the authserv-id here? Section 6.4 I think we need to update the registry to also refer to this document. Appendix C 2. Border MTAs are more likely to have direct access to external sources of authentication or reputation information since modern MUAs are more likely to be heavily firewalled. [...] It's unclear that this statement about "modern MUAs" is still true, given the "zero trust" movement and such. _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
