To Murray's question, there is no "layer" boundary that limits the ability of an evaluator to choose which signatures are evaluated and which are not.
I favor explicitly excluding any signatures that are not evaluated, while adding a requirement that ignoring all DKIM signatures makes the message non-reportable, because domain owners require both SPF and DKIM results to make the report useful. I still find "unbounded" to be unacceptable, first and foremost because it is untestable. Every system has limits, and when interoperability is involved, the corresponding systems will have different limits on both what is feasible and what is tested. Assuming that most participants will be using associative tables, reporting has a hard limit based on the number of keys designed into the table. For interoperability, all participants should be designing and testing for the same hard limits. For efficiency, the design limit should be only marginally larger than what has been observed in practice, which means something between 7 and 10. I am OK with "freedom of reporting" language that allows evaluators to evaluate only what they need, and report only what they evaluate, with the caveat that they must compute a DKIM result for the message to be reportable. Doug On Mon, Nov 7, 2022 at 6:46 AM Alessandro Vesely <[email protected]> wrote: > On Sun 06/Nov/2022 20:02:53 +0100 Murray S. Kucherawy wrote: > > On Sat, Nov 5, 2022 at 6:21 PM Douglas Foster < > [email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
