It appears that Martin Kealey <[email protected]> said: >-=-=-=-=-=- > >I'm not quite sure how I'm supposed to submit nitpickery like this, so if >there's a better forum please let me know. > >1. Filename & content-type > >Section 2.6.1 among other things says that the name for the mime-part >containing the report MUST end with ".xml" or ".xml.gz", yet the example >given ends with neither of those (it ends with just ".gz").
The example is wrong. It should obviously be .xml.gz >It seems strange to vary the content-type based solely on what amounts to a >transport optimization, namely gzip; this smells of working around >deficiencies in other standards. It does, but that's how we've been doing compressed MIME forever. Early on, the DMARC drafts said to commpress with ZIP and send files ending in .zip as application/zip. A lot of reporters still do that so the draft needs to say to accept those even though nobody, not even Google, should be generating them any more. >I'm concerned that specifying the maximum report size *after* compression >is possibly focussing on the wrong costs, and distorts the conceptual model: The problem is that many mail systems have a maximum message size they will accept. It's true that the expanded XML can be pretty big but on modern computers, a few gigabytes of RAM are not a big deal. >3. Scheduling > >Concern about processing load also brings me to section 2.4.2, which >essentially directs everyone to send their reports simultaneously. ... It does, but as far as I know it is not a problem in practice. I could see getting rid of the 0000 UTC advice since I don't see that it solves any real problem. R's, John _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
