On Tue 31/Jul/2018 15:10:21 +0200 Murray S. Kucherawy 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?
Being proportional works both ways. You can estimate the quality from the
accuracy of the content, then you can trust the field content (of a different
method or message) based on what you learned about that operator.
>>>> *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 meant something like so:
The list of commands eligible for use with the "smtp" ptype can be
found in Section 4.1 of [SMTP]. To report an SMTP command name 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.).
> I'm also not clear on what problem you're trying to solve.
No problem. That reorder and merge is just a marginal hint to improve
readability.
> 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?
No, it is not broken, AFAICS. Rather, it's better than previous versions,
where the "policy" ptype was overloaded beyond clarity, from covering
unregistered properties, to overriding methods' results, to catchall for any
property not extracted directly from the message session.
>> 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.
Agreed. However, my signing agent knows nothing about any AUTH= parameter to
the MAIL FROM command. It just knows the (non-public) smtp.auth. What A-R
field should it write?
> 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.
I beg to differ here. If the authentication token is syntactically equal to
the [local-part of the] mailbox address, this can be considered as substantial
data leakage, given that the mailbox address is public.
IMHO, in a multi-host implementation where downstream agents need to acquire
smtp.auth, there should be a final agent to redact it before it crosses the
trust boundary. For example:
Authentication-Results: example.net; auth=pass
[email protected]
Or, according to rfc6590 algorithm:
Authentication-Results: example.net; auth=pass
[email protected]
Or just remove the header field entirely. Which is better? Also compare with
varying values of From::
From: [email protected]
To: [email protected]
Authentication-Results: example.net; auth=pass
[email protected]
>>>> *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.
Both dkim=fail and dkim=policy are valid ways to override the method's
algorithmic result. To exemplify the preferred way is fine for me.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
