On Wed 20/Jan/2021 03:31:51 +0100 John Levine wrote:
In article <CAHej_8=K_x5xOw47XBtPYBWzCbfpPSAs=i9woweznaa1ofc...@mail.gmail.com>
you write:
Can you provide more details, please?
Are you receiving reports by HTTPS, or have you not seen any reduction in
reports, or both, or other?
No, I didn't put a real server's URL. Just this:
"v=DMARC1; p=none; rua=mailto:[email protected], OR-https://service.example/report/;
ruf=mailto:[email protected];";
I didn't try Ale's OR- thing but I did add an https URL to my rua= tag and set
up
a web server to catch any POST or PUT traffic.
John's record looks more workable, but it's still fluffy:
"v=DMARC1; p=none; rf=afrf;
rua=mailto:[email protected],https://dmreport.abuse.net/dmreport/;
ruf=mailto:[email protected]";
I suppose the good news is that nobody implemented the underspecified
report URL in one of the earlier DMARC drafts.
It is not underspecified. It specifies the /mailto:/ scheme. With
forward-looking shrewdness, it further specifies:
7.2.1.2. Other Methods
The specification as written allows for the addition of other
registered URI schemes to be supported in later versions.
However, one cannot make guesses about what a receiver would do with, say,
rua=fax:+13165550321. For mailto: they know to send a gzip attachment.
Nothing is specified for https:, even if the scheme is known. OR-https: is an
unknown pseudo-scheme which, as far as parsing is concerned, can be discarded
just like https: and fax:.
Likewise, the spec provides for a registry of tags and says that unknown tags
must be ignored. Therefore it is possible to safely add a new tag. Let's see
two cases:
"v=DMARC1; p=none; ruap=mailto:[email protected],
https://service.example/report/; rua=mailto:[email protected],
mailto:[email protected];";
"v=DMARC1; p=none; ruap=https://example.com/dmarcaggr,
https://service.example/report/; rua=mailto:[email protected],
mailto:[email protected];";
Using my OR- syntax, they would be, respectively:
"v=DMARC1; p=none; rua=mailto:[email protected], mailto:[email protected],
OR-https://service.example/report/;";
"v=DMARC1; p=none; rua=mailto:[email protected],
OR-https://example.com/dmarcaggr, mailto:[email protected],
OR-https://service.example/report/;";
One last case. The user has an oldish mailto:-only record, the service
introduces https: for those who can support. The service can override the rua=
thanks to step 8 of Section 7.1, Verifying External Destinations:
8. If a "rua" or "ruf" tag is thus discovered, replace the
corresponding value extracted from the domain's DMARC policy
record with the one found in this record. This permits the
Report Receiver to override the report destination. However, to
prevent loops or indirect abuse, the overriding URI MUST use the
same destination host from the first step.
So we have:
at _dmarc.example.com:
"v=DMARC1; p=none; rua=mailto:[email protected],
mailto:[email protected];";
at example.com._report._dmarc.service.example the verification record can
specify a preferred reporting address:
"v=DMARC1; ruap=https://service.example/report/;
rua=mailto:[email protected];";
(Question: is it necessary to also specify rua= if it is unchanged?)
or it can use OR- syntax:
"v=DMARC1; rua=mailto:[email protected],
OR-https://service.example/report/;";
IMHO, both methods are valid and equally well interoperable. We should choose
the one that can be more easily and clearly specified.
For OR-, it is an advantage to be able to keep step 8 above unchanged. OTOH,
the concept of pseudo-scheme requires a new paragraph to be explained. Perhaps
we should provide tentative text, rather than examples?
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
