+1
On 6/14/21, 6:42 AM, "dmarc on behalf of Brotman, Alex"
<dmarc-boun...@ietf.org on behalf of Alex_Brotman=40comcast....@dmarc.ietf.org>
wrote:
To summarize,
We'd like to see extensions available both below the "feedback" and
"record" elements. The -02 draft only has it below the "feedback" element. I
agree that all elements, each time they are utilized, should mention a
reference as to how they are to be utilized.
We'd also like to have extensions go through an IETF process, however, we
also understand that we cannot exclude third parties from defining/deploying
their own extensions. I suppose we could tell report receivers they "MUST"
ignore any extensions which are not IETF-approved, though that seems a bit
heavy-handed.
So, a sample report may look something like:
<feedback>
<version>2.0</version>
<report_metadata>
<version>2</version>
<org_name>Sample Reporter</org_name>
<email>report_sen...@example-reporter.com</email>
<extra_contact_info>...</export_contact_info>
<report_id>3v98abbp8ya9n3va8yr8oa3ya</report_id>
<date_range>
<begin>161212415</begin>
<end>161221511</end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<p>quarantine</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>192.168.4.4</source_ip>
<count>123</count>
<policy_evaluated>
<disposition>quarantine</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.com</domain>
<result>pass</result>
<selector>abc123</selector>
</dkim>
<spf>
<domain>example.com>
<result>fail</result>
</spf>
</auth_results>
<extensions>
<extension_name definition="url">
.........
</extension_name>
</extensions>
</record>
<extensions>
<extension_name definition="url">
....
</extension_name>
</extensions>
</feedback>
The goal being to allow extensions to live either at the reported-IP level,
or at the domain level.
Does this seem reasonable?
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -----Original Message-----
> From: dmarc <dmarc-boun...@ietf.org> On Behalf Of Matthäus Wander
> Sent: Saturday, June 5, 2021 7:56 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback
> Requested
>
> Alessandro Vesely wrote on 2021-06-04 11:26:
> > Second, I'm not sure we need an <extensions> container.
> > I'd go for an example like, say, so:
> >
> > [...]
> > <extension_metadata name="bimi"
> >
xmlns="https://urldefense.com/v3/__http://ietf.org/xml-namesapaces/bimi-xml?*1.0__;Lw!!ORgEfCBsr282Fw!5jPsNDxnYoaeo_HCTDHZOSs5McSKUik5frtgdFxHB_wL9O6VDywrZhokLOwusINU$
">
> > [...]
> > <extension name="bimi"
> >
xmlns="https://urldefense.com/v3/__http://ietf.org/xml-namesapaces/bimi-xml?**A1.0__;Py8!!ORgEfCBsr282Fw!5jPsNDxnYoaeo_HCTDHZOSs5McSKUik5frtgdFxHB_wL9O6VDywrZhokLNemKNFV$
">
>
> If we use an attribute for the extension name, then we don't the container
> section.
> As the current schema does not use attributes at all, I'm more inclined
to define
> the extension name in a different way for consistent non-use of
attributes. But
> that's a minor detail.
>
> >> 1) Extensions in their own section (as it is now) or within each
> >> <row> element
> >
> >
> > Both, and both optional. An extension can have some data to add in
> > some <record>, but not necessarily in all of them.
>
> +1
>
> Regards,
> Matt
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!5jPsNDxnYoaeo_HCTDHZOSs5McSKUik5frtgdFxHB_wL9O6VDywrZhokLIcIrQ-o$
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
