>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 

Reply via email to