We would like to close this ticket by Dec 15, two weeks from now, so short
trenchant comments are welcome.
Ticket #1 is about https reporting. Early drafts of the DMARC spec had a
poorly defined http report which we took out. I propose we add back https
reporting similar to that for mta-sts, with a POST of the gzipped report to
the HTTPS URI.
I still think that reporting by POST is a swell idea, since it's
considerably faster and more secure than e-mail for large reports.
(There's no attachments or base64 coding, and the report goes direct to
the recipient server, no mail relays or possible misrouting or bounces.)
There was some discussion about the detail that if there are multiple
addresses in the rua= tag you send the report to all of them. People were
quite clear that is a feature. I proposed as a hack a ruap= tag for rua
preferred, if the reporting system can send reports to all of the URIs in
the ruap tag it does so, otherwise it uses rua as it does now. That lets
you put the https URIs in the ruap tag which existing code will ignore.
Didn't get a lot of comments pro or con on that one.
R's,
John
We can adapt the approach MTA-STS uses in RFC 8460.
If rua= has an https URI, the reporter uses HTTP POST to that URI with
the report as an uncompressed or gzipped XML file as the POST body.
The media type is the same as is used in mail reports, application/xml
or application/gzip. Reports SHOULD be gzipped. If we keep the !size
hack, they MUST be no larger than the size limit.
Regards,
John Levine, [email protected], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
