On Tue 26/Jan/2021 13:02:46 +0100 Douglas Foster wrote:
DKIM ScopesI 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.
Let me attach an HTML rendering of a report I received today, so we can talk about something real.
Lines with IP 4.31.198.44 bear a ietf.org identifier. I see no reason to remove it. It is useful for understanding the mailflow, which is what DMARC reporting is designed to do.
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.
Even if this is a small example, learning the disaggregated, or even individual recipients does not help my understanding. Authentication is obviously conditioned by how the Mediator treats my messages.
I expect that Fastmail Pty Ltd carries out SPF and DKIM validation using the same algorithm, irrespective of the recipient. That is what I, as a sender, am interested in. Splitting the report in 66 lines wouldn't tell me anything more, it would just consume more eyeballs. And is useless for people who sum up all reports and just look at the totals. In any case, I cannot verify if the messages I didn't send directly are real.
If a multi-domain host allows personalized validation algorithms for some domains, I'd expect they send separated aggregate reports, if any.
Best Ale --Title: Feedback from Fastmail Pty Ltd
Feedback from Fastmail Pty Ltd
Id: 419588072; begin: 2021-01-25T00:00:00Z; end: 2021-01-25T23:59:59Z
Domain: tana.it; DKIM: ; SPF: ; policy published: none none 100
| Relaying IP | message count | reason and disposition |
From header
(opt. envelope) | SPF | DKIM | 2nd DKIM | 3rd DKIM |
|---|---|---|---|---|---|---|---|
| 62.94.243.226 | 1 | tana.it | tana.it mfrom | tana.it delta pass | |||
| 4.31.198.44 | 15 | trusted_forwarder Policy ignored due to local white list | tana.it | ietf.org mfrom | ietf.org ietf1 pass | ietf.org ietf1 pass | tana.it delta fail (body has been altered) |
| 4.31.198.44 | 50 | tana.it | ietf.org mfrom | ietf.org ietf1 pass | ietf.org ietf1 pass | tana.it delta pass |
Legend
disposition: quarantine,
reject.
spf: pass,
fail,
softfail,
temperror or permerror.
dkim: pass,
fail,
policy.
This is a DMARC aggregate report for tana.it 3 records. 2 passed. 1 failed. Submitted by Fastmail Pty Ltd Generated with Mail::DMARC 1.20180917
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
