On Sun, Jul 29, 2018 at 11:23 AM, Alessandro Vesely <[email protected]> wrote:
> On Sun 15/Jul/2018 20:04:51 +0200 Barry Leiba wrote: > > > So begins Working Group Last Call (WGLC) on draft-ietf-dmarc-rfc7601bis- > 02. > > > > Please review the latest version: > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ > > .... and send comments to the DMARC working group mailing list by 3 > August. > > *Registries definitions* > Did the WG decide whether this document is going to update or obsolete > rfc7601? > IIRC, the catch was that obsoleting would require registries > [re]definition > lest leaving pointers to obsolete defining documents. Hm... perhaps it's > fine > for a deprecated definition to point to an obsolete document... I'm not > good at > that, I'm asking. > I thought it was pretty clear that this is a replacement, which means it obsoletes 7601. > *Domain based* > An introductory paragraph sounds outworn, since rfc7281 is not > domain-based: > > This specification is not intended to be restricted to domain-based > authentication schemes, but the existing schemes in that family have > proven to be a good starting point for implementations. > True, this can be removed. *EAI addresses* > +1 for adding "or email addresses" in Section 1.5.2, Internationalized > Email, > after the words "allow UTF-8 in most places that free-form text ". > Deferring to the follow-up thread on this one. *Section 1.2. "Trust Boundary"* > That section ends with two questionable statements about A-R fields found > in an > attachment: > > The details reported by this field cannot be > trusted in that case. Thus, this field found within one of those > media types is typically ignored. > > How about generic spam complaints and ARF reports of various kinds? Of > course, > trust in the report originator may vary, but I wouldn't say the field is > typically ignored. > Do you have a suggestion for alternative text? *This proposal* > The term appears three times (sections 1.5.3. "Security", 7.11. "Reverse > Mapping", and Appendix A. "Legacy MUAs"). Won't the approved RFC be > promoted > to "Internet Standard"? In that case, I'd s/proposal/standard/. > No, this is not being advanced to Internet Standard by this action. It could be, I suppose, but the WG hasn't discussed that question. I'll change "proposal" to "specification". *Section 1.6. "Trust Environment"* > The first paragraph deserves a reference to Section 5 "Removing Existing > Header > Fields". > I kind of like how the various parts of Section 1 stand alone in terms of laying out the ground work for what follows. I'll change it if there's consensus, however. > *authres-payload* > This rule is new. Yet, the corresponding syntax doesn't seem to be > changed; it > seems to be just a readability improvement. Is that obvious? If not, I'd > mention this change/non-change as a first entry in Appendix D, to reassure > parsers implementers. Or am I misreading the ABNF? > It's meant to create a token that is easier for other documents (e.g., ARC) to import. I'll make an entry for it in Appendix D. > *special-smtp-verb* > This rule is redundant and, if we're after readability, can be striked. In > fact, both terms it produces fall under the "Keyword" rule. In addition, > IANA > reports smtp.rcptto as defined by rfc7293, so it can be omitted here. > It's not redundant. MAILFROM and RCPTTO are not SMTP verbs. *Keyword enumeration* > The note says: > > "Keyword" is defined in Section 4.1.2 of [SMTP]. When used in > "result" above, it is further constrained by the necessity of being > enumerated in Section 2.7. > > I'd replace it with: > > "Keyword" is defined in Section 4.1.2 of [SMTP]. It is further > constrained > by the necessity of being registered in the relevant IANA Registry. See > Section 6. > > Simpler and direct, no? > Not quite, because "Keyword" is used in four places, not just that one, and when used as a "policy", its registration is not required because it only means something locally. But I see what you're getting and I'll fix it up. *prospec omission* > OLD: > > The "propspec" may be omitted if, for example, the method was unable > to extract any properties to do its evaluation yet has a result to > report. > > NEW: > > The "propspec" may be omitted if the method was unable to extract or > unwilling to disclose any properties involved in its evaluation, yet > has a > result to report. > What's an example? *policy* > This ptype can now evolve from catchall to meaningful indicator: > OLD: > > A "ptype" value of "policy" indicates a policy decision about the > message not specific to a property of the message that could be > extracted. See Section 2.4 for details. > > NEW: > > A "ptype" value of "policy" indicates a policy decision about the > method. Its presence in a "resinfo" indicates that the algorithmic > result > of the method might have been overridden because of an internal > criterion. > Both "property" and "pvalue" concur at hinting what the internal > criterion > was. See Section 2.4 for details. > > The above interpretation is based on the example in Section 2.4, The > "policy" > ptype, which reads: > > ... dkim=fail policy.dkim-rules=unsigned-subject ... > I disagree, because I think the existing text still adequately captures this case; there's been a policy decision made that was unrelated to some value found in a header field or tag (i.e., it's not a straight "fail"), but rather some combination of things that violates something the verifying ADMD wants to enforce. > *Section 2.7. "Defined Methods and Result Values"* > s/New methods/Methods/ > Why? It's referring to methods that may come in the future, which I would consider "new". -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
