On Mon 07/Dec/2020 23:17:16 +0100 Marc Bradshaw wrote:
There is value in including these in one report, especially where the extended
property being reported on influences how DMARC is evaluated.
I think I represent a meagre minority of people who reads individual DMARC
reports. Most other people I heard of pour their reports into a database and
then query the latter. For them, it is indifferent whether reports come in a
single file or spread among multiple ones.
Using ARC as the example, when a p=reject policy was overridden by the receiver
because of an ARC evaluation, when that data is included in the report the
indirect mail flow can be clearly seen, which would not be the case if ARC were
included as a separate report.
When I look at an aggregate record whose relaying IP is 4.31.198.44, SPF domain
is ietf.org, and some DKIM signatures are also tagged ietf.org, it is clear to
me that it is an indirect mail flow.
Sometimes I get:
<reason><type>local_policy</type><comment>arc=pass</comment></reason>
If I had a separated ARC file keyed on relaying IPs, I could have found ARC
values in there and matched them against that row in the DMARC report.
This could be included in an <extension> element, or could be included directly
in the auth_results section of the report, based on an assumption that the
things being reported SHOULD have an authentication results entry in processed
mail.
<auth_results>
<dkim>...</dkim>
<spf>...</spf>
<arc> (as defined in arc standard) </arc>
<foo> (as defined in foo standard) </foo>
</auth_results>
Say you have:
<arc><domain>example.com</domain><result>pass</result></arc>
What would that mean? Perhaps that, according to example.com, the message did
pass, but by what authentication method?
An <arc> stanza in auth_results would have to be succinct. If there is more
structured data, auth_results doesn't seem to be the right place to stuff it.
I'd propose to first define what data ARC would report. How to report it comes
after.
These would be defined in a registry with reference to each standard, and
parsers would ignore any sections they did not understand.
I'd hope we'll come out with proper XML syntax, a namespace like, say,
urn:ietf:params:xml:ns:dmarc:aggregate:1.1 or some such, and a proper schema
location. I think the <selector> element of <dkim> has to become mandatory,
which makes a difference between reports using a pre-standardization schema and
upgraded ones. Then, an XML schema can import other schemata, but dependencies
and increased complexity will have to be weighted in.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
