On Mon 02/Dec/2025 23:25:19 +0100 Steven M Jones wrote:
On 12/2/25 03:34, Alessandro Vesely wrote:
That was the wording proposed by Marco Tiloca
https://datatracker.ietf.org/doc/review-ietf-dmarc-failure-reporting-20-artart-lc-tiloca-2025-11-26/
I chose the first alternative he proposed, as it makes explicit the concerns
associated with sending these reports to an external destination, thus
allowing the reader to assess the extent to which they are dispelled by the
verification described in the protocol. I understand, however, that it may
seem awkward. Marco probably thought so too, so much so that he proposed a
second alternative, "This prevents a bad actor from publishing ...", which is
even smoother than the one you proposed.
Further thoughts?
I'm aware, and of course defer if Marco or the other reviewers have concerns.
If you prefer to use the "This prevents..." option that's fine, but for
agreement change the following sentence to something like: "This also prevents
a Domain Owner from unilaterally publishing a DMARC Policy Record..."
It also introduces a tense/agreement issue (send -> sending), so -- meh, here's
a suggestion for the whole paragraph:
"This prevents a bad actor from publishing a DMARC Policy Record requesting
that failure reports be sent to an external destination, then deliberately
sending messages that will generate failure reports as a form of abuse. This
also prevents a Domain Owner from unilaterally publishing a DMARC Policy Record
with an external destination for failure reports, forcing the external
destination to deal with unwanted messages and potential privacy issues."
It looks good, I shortened it a bit and swapped the paragraphs. I'm pasting the
resulting Section 5 below, because commit[*] isn't very readable.
5. Verifying External Destinations
It is possible to specify destinations for failure reports that are
outside of the Organizational Domain of the DMARC Policy Record that
was requesting the reports. These destinations are commonly referred
to as "external destinations" and may represent a different domain
controlled by the same organization, a contracted report processing
service, or some other arrangement.
In case of external destinations, a Mail Receiver who generates
failure reports MUST use the Verifying External Destinations
procedure described in Section 4 of
[I-D.ietf-dmarc-aggregate-reporting], substituting the "ruf" tag
where the "rua" tag appears in that procedure.
This prevents a bad actor from publishing a DMARC Policy Record
requesting failure reports to an external destination, and then
deliberately sending messages that will generate failure reports as a
form of abuse. It also prevents a Domain Owner from unilaterally
publishing a DMARC Policy Record with an external destination for
failure reports, forcing the external destination to deal with
unwanted messages and potential privacy issues.
I'll post it tomorrow unless otherwise advised.
Best
Ale
--
[*]
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/commit/e87ed5f743acb4e6223edda02df0a133705f57ab
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
