On Thu 21/Jan/2021 01:05:53 +0100 Michael Thomas wrote:
On 1/20/21 3:10 PM, Steven M Jones wrote:
I think we should specify HTTPS URIs, and following 7489 section 12.6
"Secure Protocols" and current practices, HTTP should not be
specified/permitted.
However I don't yet see a compelling case for the OR- syntax or a
separate "ruap" tag. Duplicate reports to the same destination are not
the base case, and the bandwidth for unintended duplicates will likely
be much smaller than, say, per-message DNS tree walks being discussed
elsewhere. Report processors annoyed by receiving duplicates can work
with the domain owners in question, and if that doesn't work they can
withdraw their report authorization record.
The point is that if you specify both mailto: and https:, a compliant report
generator should send to both URLs. OTOH, if you only specify https:, you are
going to miss a lot of reports.
See this before spending too much time. It's probably better to just junk this
enhancement.
https://trac.ietf.org/trac/dmarc/ticket/99
The proposed workaround implies sending base64, which is what https: is meant
to avoid. Your suggestion to use it as an authentication mechanism for https:
sounds better. You just need to add From: and DKIM-Signature: header fields,
where the binary body is hashed as-is, that is, with no canonicalization. It
seems to require an easy software enhancement.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
