On Mon 30/Jul/2018 07:58:29 +0200 Murray S. Kucherawy wrote:
> On Sun, Jul 29, 2018 at 11:23 AM, Alessandro Vesely <ves...@tana.it> wrote:
>
>> *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?
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.
>> *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.
IMHO, that paragraph was fine when the idea was new. Nowadays it sounds
somewhat lengthy. Referencing Section 5 might allow to shorten a little bit
the text. It's just a question of taste, and since you're the author, it's up
to you.
>> *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.)
In the ABNF too, the definition of special-smtp-verb doesn't constrain the rule
to the lowercase "smtp" ptype. So, since the definitions of "mailfrom" and
"rcptto" can be found in their respective RFCs, 7208 and 7293, I fail to see
what's the added value of anticipating their definitions here. To wit, you
could as well have defined, say:
property = special-dkim-tag / special-smtp-verb / Keyword
special-dkim-tag = "a" / "b" / "d" / "i"
...
Instead, you appropriately defer that until the DKIM section.
Just wondering...
>> *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.
>> *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.
>> *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".
I thought the methods in Section 2.7.5. "Other Registered Codes" are not,
strictly speaking, /specified in this document/. If the ID is meant to be
comprehensive —by definition or by reference— of all valid methods existing at
the time of publication, then the wording is fine.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
