We feed received DMARC reports through Open-Report-Parser and visualize
with Open DMARC Analyzer.
Sometimes the ingestion step fails, because we receive aggregate DMARC
reports with invalid contents. Particularly from senders that seem to
have just started sending DMARC reports.
RFC 7478 says:
The aggregate data MUST be an XML file that
SHOULD be subjected to GZIP compression.
The name of the filename is then specified, and the extension further
implies only gzip as an optional compression method.
extension = "xml" / "xml.gz"
The extension MUST be "xml" for a plain XML file,
or "xml.gz" for an XML file compressed using GZIP.
However, some send zip compressed files, with a ".zip" extension, one
notable sender being google.com.
I have also seen zip files declared as application/gzip, and gzip files
declared as application/zip. They are few and far between, but cause
annoying failures.
1&1 started sending DMARC reports for at least some of their domains
today, and fell into the trap of sending gzipped data declared with
content-type application/zip.
Their reports are also sent with a NULL envelope sender, and a quick
look through my report archive suggest they are alone in this.
The RFC says very little about envelope sender, only that:
Email streams carrying DMARC feedback data MUST
conform to the DMARC mechanism, thereby resulting
in an aligned "pass" (see Section 3.1).
Another category of failures are what I call 'NULL reports' -
superficially valid-looking DMARC report XML files (but does not follow
the DMARC XML schema, as far as I understand it), but with no real
aggregate data;
<feedback>
[...]
<record>
<row>
<source_ip/>
<count>0</count>
<policy_evaluated>
<disposition/>
<dkim/>
<spf/>
</policy_evaluated>
</row>
[...]
</feedback>
which appear to be a bit pointless. wp.pl, I'm looking at you.
I've reported this to the involved parties, and are waiting to see
improvements.
These NULL-reports, I just ignore for now.
Regarding the first type of mis-declared content-types, I've resolved to
using a Sieve script to fix up the content-type on a case by case basis
while waiting for the sender to fix their process, but would it perhaps
be better if the processing tool did its own content-type sniffing?
Could this type of sniffing have or cause other problems?
I'm thinking about improving the ingestion step by adding Content-Type
sniffing, but are wondering if it should be done at all, or if it will
be considered an anti-feature.
Any advice?
Daniel K.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
