On Sun 06/Nov/2022 20:02:53 +0100 Murray S. Kucherawy wrote:
On Sat, Nov 5, 2022 at 6:21 PM Douglas Foster
<dougfoster.emailstanda...@gmail.com> wrote:
Evaluators are free to evaluate as many signatures as they wish, and to
use them as they wish. Non-aligned signatures are completely irrelevant
to DMARC's purposes, so evaluation of them should be optional and
reporting about them should be deprecated. >
The last two sentences, I would argue, are in conflict. If evaluators
(i.e., the DKIM layer) are free to evaluate as many signatures as they wish,
then DMARC has no way to assert which ones are optional; that decision is
made at the DKIM layer. At best, DMARC can make that request of the DKIM
validator, but that presumes you're using a DKIM validator that gives DMARC
that discretion. The DKIM RFC doesn't guarantee any such choice, which
means there's nothing DMARC can specify here. >
The thing in DMARC's discretion is which ones to report.
The current layout allows to report as many signatures as the report generator
wants to. It provides for four fields for each signature, domain, selector,
result and comment, and has maxOccurs="unbounded". We are not going to change
that.
The DKIM result is tied to be one of "none", "pass", "fail", "policy",
"neutral", "temperror" or "permerror", where the meaning of "policy", defined
in Section 2.7.1 of RFC 8601[*], is not-acceptable. The current I-D says:
The dkim sub-element is optional as not all messages are signed.
Perhaps, it should say:
The dkim sub-element is optional as not all messages are signed,
and not all signatures have to be reported.
That way, freedom-of-reporting would be clear. I'd skip explicitly encouraging
or discouraging what signatures to report. It goes without saying that one can
only report the signatures it did evaluate (or should we say so?)
Alternatively the spec could provide for an annoying "not-evaluated" result for
DKIM signatures. Annoying because it would force a report generator to keep
track of each signature, which might not be handy.
Best
Ale
--
[*] Alex, please add this citation to the relevant paragraph of Secion 2.1.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
