This thread has been hijacked by the lack of reading comprehension. Nobody (in
this thread) has complained of DMARC reports being too large.
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.
I now return you to our normally scheduled programming.
> On Oct 13, 2016, at 10:53 AM, John Levine via dmarc-discuss
> <firstname.lastname@example.org> wrote:
>> There's another question to raise in the IETF working group - do we need
>> to re-consider the use of HTTPS as an alternative transport for reports?
>> (Background: HTTP was in the original spec, but hadn't been implemented,
>> and so was dropped several years ago.)
>> If we're running into the common size limits on email messages for
>> reports at the largest senders/receivers today, what should we be
>> planning for in five years? In ten? Maybe it's time to re-establish an
>> alternate channel in the spec, so it will be ready when we need it.
> It's a poor idea to put stuff into a spec if nobody's planning to
> implement it, because that generally results in a spec that doesn't
> work when someone tries later. The original http language was
> hopelessly broken, so I offered something different that I think
> would have worked, but nobody ever tested.
> So if DMARC reports are getting too big, I'd be happy to resuscitate
> the http language in a short draft to update RFC 7489, but only if
> there are a few people who plan to implement each side of it so we can
> be sure that it works.
> Technically it's really simple, a single HTTP PUT operation which
> is not as common as GET or POST, but should be supported by every
> web server, and automagically provides for compression and duplicate
> report elimination.
> dmarc-discuss mailing list
> NOTE: Participating in this list means you agree to the DMARC Note Well terms
dmarc-discuss mailing list
NOTE: Participating in this list means you agree to the DMARC Note Well terms