On Thu 03/Dec/2020 20:54:03 +0100 John R Levine wrote:
Why do you believe that people would not send reports by mail and by https
at the same time?
Oh my. Hadn't thought about that. It will certainly cause duplicates.
I meant "at the same time" as in during the same reporting run. As Dave noted,
if you sent any particular report by https, there's no need to send it again by
mail.
Got it. However, the spec says it's a list of addresses to which aggregate
feedback is to be sent. When there are multiple entries, up to now, reports
are sent to each. If services like dmarcian switch to an https URI, a sender
could end up with that URI along with its local mailto one. How does a report
producer know whether multiple URIs are mutually exclusive or inclusive?
Systems receiving reports have to be prepared for duplicates anyway since
double deliveries of mail messages happens. That's the point of the filename
on the report, to provide a unique name for each report so it's easy to tell if
you've seen a report before.
Right, but if that happens everyday the (small) efficiency gain is lost.
$ gpg -u 500982D49712C507C236B2D6B8ABBBF9A091CC0D --clearsign < this text
Can you verify it? I cannot find how to transform the delta selector public
key into a pgp public key block.
It says it can't find a public key which is not surprising. I still don't
think this is a productive direction to go.
Not for the subject at hand, maybe. The possibility to further deploy DKIM key
distribution by coding some dkim2openpgp utility seems interesting to me.
If people really are worried about fake reports, there is a well defined way to
put a signature in an XML document.
However, XML signatures require a certificate, not just a key. Consider that a
DNSSEC-authenticated DKIM signature is semantically superior to CA
certificates. First, because registrars know what they're signing better than
CAs. Second, because the way to associate DKIM signatures with the issuing
domains is better standardized than X509 subject common name or alternative name.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
