On Wed 20/May/2020 18:51:32 +0200 Hector Santos wrote:
> On 5/20/2020 12:26 PM, Alessandro Vesely wrote:
>>
>> Hector, what are you talking about?
>
> hhmmm, I don't known any other way of describing this simple concept.
>
>> Can you show us how does a CSV report look like?
>
> Like a standard format for CSV:
>
> line #1, name of fields, separated by a comma
> line #2, transaction #1 values separated by comma
> ..
> ..
> ..
> Line #N, transaction #N-1 values separated by comma
Transaction? I thought we were talking about aggregate reports. There are no
transactions there.
I mean, what is the CSV format of the following report, that I sent yesterday
for this list:
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>tana.it</org_name>
<email>[email protected]</email>
<report_id>eb74db90c32d432ea1652a0eb656fe5a</report_id>
<date_range>
<begin>1589846400</begin>
<end>1589932800</end>
</date_range>
</report_metadata>
<policy_published>
<domain>dmarc.ietf.org</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
</policy_published>
<record>
<row>
<source_ip>4.31.198.44</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>dmarc.ietf.org</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>ietf.org</domain>
<selector>ietf1</selector>
<result>pass</result>
</dkim>
<dkim>
<domain>ietf.org</domain>
<selector>ietf1</selector>
<result>fail</result>
</dkim>
<dkim>
<domain>akamai.com</domain>
<selector>jan2016.eng</selector>
<result>fail</result>
</dkim>
<spf>
<domain>ietf.org</domain>
<result>pass</result>
<scope>mfrom</scope>
</spf>
</auth_results>
</record>
<record>
<row>
<source_ip>4.31.198.44</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>dmarc.ietf.org</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>ietf.org</domain>
<selector>ietf1</selector>
<result>pass</result>
</dkim>
<dkim>
<domain>ietf.org</domain>
<selector>ietf1</selector>
<result>fail</result>
</dkim>
<dkim>
<domain>cisco.com</domain>
<selector>iport</selector>
<result>fail</result>
</dkim>
<spf>
<domain>ietf.org</domain>
<result>pass</result>
<scope>mfrom</scope>
</spf>
</auth_results>
</record>
<record>
<row>
<source_ip>4.31.198.44</source_ip>
<count>2</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>dmarc.ietf.org</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>ietf.org</domain>
<selector>ietf1</selector>
<result>pass</result>
</dkim>
<dkim>
<domain>ietf.org</domain>
<selector>ietf1</selector>
<result>fail</result>
</dkim>
<dkim>
<domain>junc.eu</domain>
<selector>default</selector>
<result>fail</result>
</dkim>
<spf>
<domain>ietf.org</domain>
<result>pass</result>
<scope>mfrom</scope>
</spf>
</auth_results>
</record>
<record>
<row>
<source_ip>4.31.198.44</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>dmarc.ietf.org</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>ietf.org</domain>
<selector>ietf1</selector>
<result>pass</result>
</dkim>
<dkim>
<domain>ietf.org</domain>
<selector>ietf1</selector>
<result>fail</result>
</dkim>
<dkim>
<domain>valimail.com</domain>
<selector>google2048</selector>
<result>fail</result>
</dkim>
<spf>
<domain>ietf.org</domain>
<result>pass</result>
<scope>mfrom</scope>
</spf>
</auth_results>
</record>
</feedback>
> A standard csv layout. Most if not all table like "tools" like a spreadsheet
> or
> SQL, support a CSV import, maybe a XML import and if you are lucky, the JSON
> format. But XML is older than JSON so you may see CSV and XML with older
> tools.
> But relatively soon, JSON will be the more common comm I/O technique.
>
>> XML, like JSON, support complex template schemata. CSV templates require
>> fixed
>> columns. I doubt you're talking seriously if you make such claims.
>
> It is possible to have XML and JSON represented in a table-like flat name
> space
> with multiple columns.
>
>>
>> Yes, and I am Catherine Deneuve...
>>
>
> Who?
>
>> ... Can we get back to work, please?
>
> Sorry, but I consider a rude, disrespectful and ignorant statement, to be
> saying that.
No personal attack intended. I'm being rude because I have the impression that
you are not defending a concrete, well defined need, but instead find new
arguments opportunistically to pursue a vague sense of format fashion. You
shifted from an asserted necessity of producers to a possible desire of
consumers. Now you introduce formats like CSV which make no sense in DMARC
context. Is that work?
> We are working. If you don't agree or lack the ability to support anything
> [but
> XML] others can, you should note it and but also not push your limitations on
> others.
I don't think that the inability to support CSV is a limitation of mine. I
hold that CSV cannot satisfy DMARC requirements. Please do contradict me by
showing us how an aggregate report in CSV would look like, as well as some
ideas for defining the corresponding template, similar to what Appendix C of
RFC 7489 specifies for XML.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
