>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
dmarc-discuss mailing list
NOTE: Participating in this list means you agree to the DMARC Note Well terms