>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. R's, John _______________________________________________ dmarc-discuss mailing list dmarc-discuss@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)
