Hi John,<div><br></div><div>Apologies for the crufty workflow. In the spirit of not letting the perfect be the enemy of the good enough, for the first iteration of the reporting we wanted to stick with a format that covered 95% of reports and not do any extra work coming up with things like tackling registration of a new application/gzip mime type, which doesn't exist, believe it or not.</div>

<div><br></div><div>The purpose of zipping the report was to delay as long as possible that day when the attachment size exceeds what most MTAs can handle (for us that's around 20MB outbound). Actually, that day has already come and for certain senders we have to truncate the reports when they experience high volume. (Normal senders do not ever have to worry about this, but if it ever happens to you, there will be a <reason> truncated </reason> in the report metadata blob).</div>

<div><br></div><div>I fully support the idea of a more scalable transport layer like HTTP for reporting. However, due to the rather prosaic fact that DMARC is an email project and email engineers tend to have more flexibility speaking SMTP than HTTP in production environments, none of us, especially me, wanted to delay prototyping or making the draft public in order to support a fuller-featured transport for reports from the beginning. After all, all of the salient data gets there in the end.</div>

<div><br></div><div>Thanks,</div><div>Monica<br><br><div class="gmail_quote">On Fri, Feb 3, 2012 at 1:59 PM, John Levine <span dir="ltr"><<a href="mailto:johnl@taugh.com">johnl@taugh.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Google has been sending me swell daily summaries, so I should start<br>
logging and analyzing them.<br>
<br>
If I may whine slightly, the process to deal with the reports is<br>
impressively complicated:<br>
<br>
1) Receive mail message<br>
2) Decode and save attachment from the message<br>
3) Extract XML file from ZIP<br>
4) Parse XML from the XML file<br>
5) Do whatever with the reports<br>
<br>
If I were tsar, I would say just to send the XML as a text/xml message<br>
body, and if you're worried about the size of incoming reports, make<br>
your reporting URL an HTTP one and accept compressed content-coding.<br>
<br>
Failing that, is the point of the ZIP file that there might be<br>
multiple XML files, that the XML might be big, or something else?<br>
Even a really big report seems unlikely to be more than a few<br>
megabytes, which in the overall traffic flow, is pretty tiny.<br>
<br>
R's,<br>
John<br>
<br>
_______________________________________________<br>
dmarc-discuss mailing list<br>
<a href="mailto:dmarc-discuss@dmarc.org">dmarc-discuss@dmarc.org</a><br>
<a href="http://www.dmarc.org/mailman/listinfo/dmarc-discuss" target="_blank">http://www.dmarc.org/mailman/listinfo/dmarc-discuss</a><br>
NOTE: Participating in this list means you agree to the DMARC Note Well terms (<a href="http://www.dmarc.org/note_well.html" target="_blank">http://www.dmarc.org/note_well.html</a>)<br>
</blockquote></div><br></div>