On Tue 21/Oct/2025 00:31:43 +0200 Todd Herr wrote:
Here are my comments on the subject document:
In both the Abstract and the first paragraph of the introduction, we find
the phrase "DMARC is a scalable mechanism". The word "scalable" does not
appear in DMARCbis, and while there is a section in DMARCbis titled
"Scalability", it makes no claim that DMARC mechanism is scalable per se;
instead, "Scalability" here refers to the fact that there is no need for
any pre-sending agreements between senders and receivers. I would recommend
just removing the word "scalable" in both instances.
The phrase appears in the abstract of RFC 7489. I agree it can be slashed.
Second paragraph of the Introduction contains the phrase "Sender domain".
DMARCbis defines the term "Author Domain", which is I think what's meant
here, and I would argue that "Sender domain" should be changed to "Domain
Owner of the Author Domain" here.
"Sender domain" was in the Michael's proposed text[*]. "Domain Owner of the
Author Domain" seems to be overly long, also because the Author is faked in
this case (direct domain abuse). How about just "Domain Owner"?
[...]
Broken link in the Terminology section for the definitions section of
DMARCbis (at least in the HTML version).
The markdown source is the same as the similar link in Section 2, that is:
[@!I-D.ietf-dmarc-dmarcbis, section 3.2]
except that the line wrapped after the comma.
The similar link in Section 2, [@!I-D.ietf-dmarc-dmarcbis, section 4.7], is
rendered correctly as: <xref target="I-D.ietf-dmarc-dmarcbis"
sectionFormat="of" relative="#" section="4.7"></xref>. However, the generated
https link misses the "#section-4.7" fragment.
These have to be checked in AUTH48.
Regarding the Reporting Format Update, specifically sub-section 2 of
section 4, if a message has multiple DKIM signatures and more than one DKIM
signature fails to validate, does this mean that multiple failure reports
will be produced? It says that each dmarc-method may appear at most once in
an id-align.
I think "dkim" should be mentioned in Identity-Alignment if one or more failed
DKIM signatures are present. Which signature(s) failed could be deduced from
the Authentication-Results field as defined in RFC 5965. Note that RFC 6591
limits the Authentication-Results field in the message/feedback-report part to
only reflect the result of a single authentication method. For the "dkim"
method, it seems to me that multiple signatures can be reflected.
I would strike the parenthetical "(sometimes referred to as 'forensic
reports')" entirely from the first paragraph of the Privacy Considerations
section. The word "forensic" doesn't appear in either DMARCbis or the
Aggregate Reporting document.
Agreed.
I'm not quite sure that section 7.2 (Report Recipients) is even necessary.
One presumes that a Mail Receiver has reviewed its policies before deciding
to go ahead and do failure reporting (or not), and the seemingly implied
need in section 7.2 for a Mail Receiver to do independent additional
vetting of a Report Consumer goes against any claim of scalability
associated with DMARC. Maybe pull a sentence or two out of it and add it
the first paragraph of Privacy Considerations, something like:
"The generation and transmission of DMARC failure reports raise significant
privacy concerns that must be carefully considered before deployment.
Additionally, Mail Receivers must be aware that Report Consumers may be
able to extract and/or infer metadata from the reports, metadata that is
not necessarily directly associated with the failed message."
I don't offer the "Additionally...." sentence here as a possible
contribution to the text so much as I present it as a placeholder for what
might be pulled from section 7.2 if the authors go that route.
I have no particular preference in this regard. However, Section 7.2, as it
stands, could be interpreted as a suggestion toward a policy along the lines of
"Report entire message if the destination is not external, otherwise only
headers." The proposed replacement is not as impactful.
I'm confused by the Example Failure Report (Appendix A) in two respects:
1. There is no redaction in the example, not even of the To: address
Setting up a consistent redaction, as required by RFC 6590, is not trivial.
For example, it's unclear whether the local-part of the recipient's email
address should also be obscured in general places, i.e., not in an addr-spec.
In fact, many spam messages begin with "Dear local-part," so if you don't
obscure it there you can allow it to be inferred. OTOH, a local-part which is
also a word in the message language can appear in a sentence in the message
body, where it can be deduced if it's obscured.
Without redaction, the example is much more straightforward.
2. There are two Authentication-Results headers in the example, one of
which reads, in part, "auth=pass (details omitted)" and so I'm not sure how
this would appear in a Failure Report.
That is one of the four Authentication-Results fields that appear in the
message/rfc822 part of the report. It was written by the consumer.example MSA
after authenticating the user's login. Neither forwarder.example nor
gen.example bothered to remove it, so it was reported.
I wonder if perhaps a more straightforward example, one that doesn't
attempt to show a message that passed through a mailing list as this one
seems to but rather is just a direct point A to point B message that
failed, might be better?
I adapted the example from a report I received. And I only received mailing
lists failures.
That is all...
Thanks a lot for the review.
Best
Ale
--
[*] https://mailarchive.ietf.org/arch/msg/dmarc/XQq5HyFxZhPksxZ9qAyhu3kNsKQ
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
