[dmarc-discuss] About those DMARC reports

Monica Chew mmc at googlers.com
Fri Feb 3 15:08:26 PST 2012


Hi John,

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.

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).

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.

Thanks,
Monica

On Fri, Feb 3, 2012 at 1:59 PM, John Levine <johnl at taugh.com> wrote:

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


More information about the dmarc-discuss mailing list