This topic becomes much more than "which signature". It is really about "what is needed to identify and correct alignment problems".
Based on the authentication discussion, we have several inter-related issues: - I started with a concern about putting excessive data collection requirements on the reporting domain. - Increased data collection causes data disaggregation. This becomes a technical problem as report sizes increase. Disaggregation also allows individual message characteristics to be revealed, which becomes a potential privacy concern. - In theory, very few attributes should be necessary to triage an alignment problem: Source IP, SMTP domain, From Domain, and DKIM scope. In practice, investigating root cause is difficult and as a result report recipients crave maximum data. My current perspective, still open to being convinced DKIM Scopes I have not heard a compelling argument to require information about authentication tests that are unrelated to alignment testing. For DKIM specifically, I think one scope should be sufficient, on this hierarchy: - The best-aligned scope that verified, or - the best-aligned scope that failed verification, or - a no-signature result otherwise. Anything more complex imposes a gratuitous data collection burden on the reporting domain and reduces aggregation significantly. On the technical side, it has already been noted that variable-length lists are particularly problematic for calculating aggregates. I would also suggest dropping the requirement to include all authentication test results. Only SPF and aligned DKIM are relevant, and anything more causes disaggregation. Aggregation Controls We have discussed whether the target domain should be included in the report. I understand that doing so is not reasonable for the large hosting services. On the other hand, including the target domain would be a trivial matter for smaller operations, and I think it would be valuable for some research. Similarly, DKIM scopes are known to be useful for most investigations, but John has already observed that proliferation of DKIM scopes can be used to force disaggregation down to the individual recipient level. I wonder if the solution to both of these is to use variable aggregation. When the number of target domains is small, reporting the source domain is probably not an issue for either the report sender or the report receiver. So we could make the field optional, where some organizations report an actual target domain and others report a placeholder, with the level of aggregation chosen by the needs of the reporting organization and by overall constraints on report size (probably based on number of result rows). The same could apply to DKIM: If disaggregation by DKIM scope provides a report that is too large, the scope can be replaced with a placeholder to increase aggregation and reduce report size. DF On Mon, Jan 25, 2021 at 1:38 PM Alessandro Vesely <ves...@tana.it> wrote: > On Mon 25/Jan/2021 18:59:16 +0100 Brotman, Alex wrote: > > > > I’m not suggesting that we add anything that would report “Signature > > validation not attempted”, that sounds horrible. Will the original > source > > potentially care that the message was signed in three other places as the > > message bounced around? > > It can be useful to understand the mail flow. For example, a signature by > a > Mediator can reveal a mailing list, even if the receiver didn't evaluate > it. > > > > Should we put the onus on the reporting entity to do the filter out the > > non-aligned (what if none aligned) signatures, or just realize it’s some > > automated job and including all logged/validated signatures is the better > > way? > > The order in which signatures appear in a report can be significant too. > > > Best > Ale > -- > > > > > > > > >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
