ARC shows the need for extension data within <record> elements:
<https://datatracker.ietf.org/doc/html/rfc8617#section-7.2.2>
Example from RFC 8617:
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
<reason>
<type>local_policy</type>
<comment>arc=pass as[2].d=d2.example as[2].s=s2
as[1].d=d1.example as[1].s=s3
remote-ip[1]=2001:DB8::1A</comment>
</reason>
</policy_evaluated>
With proper extension support, this example could look like this:
<row>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
<reason>
<type>extension</type>
<comment>arc=pass</comment>
</reason>
</policy_evaluated>
</row>
<auth_results>...</auth_results>
<extensions>
<arc xmlns="(...)">
<result>pass</result>
<sets>
<as>
<instance>2</instance>
<domain>d2.example</domain>
<selector>s2</domain>
</as>
<as>
<instance>1</instance>
<domain>d1.example</domain>
<selector>s3</domain>
<remote_ip>2001:DB8::1A</remote_ip>
</as>
</sets>
</arc>
</extensions>
An IANA registry could serve as repository of IETF-approved extensions.
It's worth considering whether certain elements should be defined as
extensible. In the above example, the <arc> element could be placed
below <auth_results> next to the existing <dkim> and <spf> elements.
Implementations support this behavior by simply ignoring unknown
elements. XML Schema supports extensibility in well-defined places with
the <xsd:any> element.
Regards,
Matt
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
