On Tue, Jul 31, 2018 at 4:09 AM, Alessandro Vesely <ves...@tana.it> wrote:
> > Do you have a suggestion for alternative text? > > Say: > > In that case, if the producer intent is not to harm or mislead, the > trust > in this field's content would be proportional to the estimated quality > of > the producer's software. Consumer's wisdom is key. > How is a receiver to know anything about the estimated quality of the producer's software? >> *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. > > Right, but their formation is well described in the relevant paragraphs, > which > I quote: > > The list of commands eligible for use with the "smtp" ptype can be > found in Section 4.1 of [SMTP]. > > [...omitted paragraph here...] > > Where an SMTP command name is being reported as a "property", the > agent generating the header field represents that command by > converting it to lowercase and dropping any spaces (e.g., "MAIL FROM" > becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.). > > Please note that a dumb reader might fail to derive that the latter > paragraph > is constrained by the former. (Perhaps reordering and/or merging might > help.) > I'm not clear on how ordering helps here. You need the two together regardless of order. I'm also not clear on what problem you're trying to solve. Keep in mind that this is now something like the fourth version of this document, and this has not been identified as a deficiency in any prior version. Is this actually broken? >> *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? > > This message is an example. Unless removed, it bears a header field like: > > Authentication-Results: tana.it; auth=pass (details omitted) > > It means I was SMTP-authenticated when I posted the message (otherwise it > wouldn't have been DKIM-signed.) However, for obvious reasons, I don't > want to > disclose the userid I authenticated with. > I think that's operationally a poor choice. The whole point of the data that come after the pass/fail is to tell downstream agents what identifier(s) might be of interest to record or highlight to users. If you managed to authenticate as the identity in the From: field, that's a lot more interesting than if you authenticated as something unrelated; the fact that the filter adding this left out that key piece of information almost makes it useless. But since the syntax (unfortunately) allows it, the proposed text change is reasonable. >> *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. > > Isn't that exactly the definition of policy? > > policy: The message was signed, but some aspect of the signature or > signatures was not acceptable to the ADMD. > Yes, so is there a need to restate all of that here? That's all laid out in Section 2.4. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
