On Fri 14/Oct/2016 08:37:08 +0200 Juri Haberland via dmarc-discuss wrote:
On 2016-10-13 20:06, Matt Simerson via dmarc-discuss wrote:

The problem in this thread is an issue with some DMARC report senders
failing to parse the DMARC URIs properly, if that DMARC URI includes
size limits.

Right again. That's why I hesitated to re-post my findings on the IETF dmarc 

Please, don't hesitate. We need to fix bugs, and they're difficult to find in a fully automated system where people seldom watch gearings directly.


Let's set up a DMARC receiver whose only job is to check the correctness of DMARC aggregate reports. Size limits is just one of the due tests. For more, external addresses, reporting period determination in the face of changed ri= tag, compression (.zip vs .gz), authentication, and, last but not least, accuracy of data.

I'm willing to dedicate one or two domains to sending a few mails per day just to check if/how/what reports get delivered. If someone volunteers for the main job, verification and selection of target domains, that is. Anyone?

For what it's worth, the largest report I ever got is ~2kB (compressed, 46kB
uncompressed), but I run only a small system with a handful of users and lists.
Would be interesting to hear what sizes larger sites receive (or send), but I
doubt it gets into the region of ~1MB (compressed) - if the sender has a decent
implementation (which OpenDMARC currently has not).

Agreed, correct aggregation has to be tested too.

So again: Some report senders do not parse reporting URIs correct - please
check your implementations... That was my point.

I wrote a C program to send reports, zaggregate[1]. Possibly, I'm its only user. At any rate, I never found a bug in it. How come?!? How can I check?


[1] if you're curious:
dmarc-discuss mailing list

NOTE: Participating in this list means you agree to the DMARC Note Well terms 

Reply via email to