It appears that Daniel K. via mailop <dan...@vendo.no> said: >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.
Right, the original draft said ZIP and we later changed it to gzip. Your report analyzer should accept either. You can try it one way and if that fails, try it the other. >Their reports are also sent with a NULL envelope sender, and a quick >look through my report archive suggest they are alone in this. That is not unreasonable. They don't want bounce reports for these autogenerated messages. If someone puts the wrong address in their DMARC record, that is their own problem. >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; I think that's a bug in one of the open source reporting scripts. Not much you can do about it, discard it and move on. >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? Yes, see above. >Could this type of sniffing have or cause other problems? For just these two types, I don't think so. R's, John _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
