I'm serving as document shepherd for
draft-ietf-dmarc-aggregate-reporting, and here's my shepherd review:
First, thanks, Alex, for being the editor for this!
— Section 1.1 —
The only thing in this section that belongs there is the last
paragraph; the rest, which is copied from RFC 8174, should be removed.
You also need to add normative references to RFCs 2119 and 8174.
— Section 2.1 —
Aggregate DMARC feedback provides visibility into real-world email
streams that Domain Owners need to make informed decisions regarding
the publication of DMARC policy.
“Domain Owners need to make informed decisions” can be read two ways,
and I trip over this all the time. We can avoid the “trip” by making
it “Domain Owners need in order to make informed decisions” or “Domain
Owners need so they can make informed decisions”.
* For both DKIM and SPF, an indication of whether the identifier was
in alignment
As this is the first use of “alignment” in this document, I suggest
making it “DMARC alignment” here, and adding “(see
[I-D.ietf-dmarc-dmarcbis] Section 3.2.7)”.
The date_range field which will
contain begin and end fields as epoch timestamps.
This isn’t a sentence. I think the right fix is just to delete “which”.
The other element
will be the policy_published, and record the policy configuration
observed by the receiving system.
This is an awkward and probably ungrammatical sentence. I think the
right fix is to change “and” to “which will”.
For each IP address that
is being reported, there will be at least one record element, which
will then have each of a row, identifiers, and auth_results sub-
element.
“each of a row…” feels awkward. Maybe this?:
NEW
For each IP address that
is being reported, there will be at least one record element. Each
record element will have one “row”, one “identifiers”, and one
“auth_results” sub-element.
END
In general, it would seem better for each (sub-)element name to be
marked up as such, shown in plain text as quoted (and maybe in rich
text as italic). I’d say that we could leave this to the RFC Editor,
but this section is really hard to review without that visible
distinction.
The dkim sub-element is
optional as not all messages are signed, while there MUST be at least
one spf sub-element.
As I read DMARCbis, I think it requires the use of SPF *or* DKIM, but
does not *require* SPF. A sender doesn’t have to supply an SPF
record, and a receiver doesn’t have to check SPF if there is aligned
DKIM. What do I put in the spf sub-element if your domain doesn’t use
SPF or if I didn’t check it?
— Section 2.1.5 —
sampled_out: The message was exempted from application of policy by
the testing mode ("t" tag) in the DMARC policy record.
The name of this item reflects its use with the old “pct” tag, and
doesn’t make sense any more. Shouldn’t we be phasing in a change for
that?
forwarded: The message was relayed via a known forwarder, or local
heuristics identified the message as likely having been forwarded.
There is no expectation that authentication would pass.
trusted_forwarder: Message authentication failure was anticipated by
other evidence linking the message to a locally maintained list of
known and trusted forwarders.
It would be good to (1) put these together in the text (next to each
other, rather than at opposite ends of the list) and (2) say something
about the difference that’s expected between the two, given that they
both talk about “known forwarder”.
— Section 2.3 —
Therefore, it is the responsibility of report consumers and Domain
Owners to be aware of this situation and allow for such mixed reports
What’s the difference between report consumers and Domain Owners?
Does it make sense to change “allow for” to “expect”? What other
allowance are they to do?
— Section 2.6.1 —
It might be good to point the reader to UUIDs [RFC9562] (as an
informative reference, not normative), saying that it’s not necessary
to use them, but that they fit the bill nicely.
— Section 2.6.2 —
A human-readable
portion MAY be included as a MIME part (such as a text/plain part).
The correct term is “body part”, and that’s what’s used in RFC 2045.
I would phrase this as ‘A human-readable annotation MAY be included as
a body part (with a human-friendly content-type, such as “text/plain”
or “text/html”).’
It is presumed that
the aggregate reporting address will be equipped to extract MIME
parts with the prescribed media type and filename
“body parts”
For instance, this is a possible Subject field for a report to the
Domain Owner "example.com" from the Mail Receiver
"mail.receiver.example". It is line-wrapped as allowed by [RFC5322]:
Subject: Report Domain: example.com Submitter: mail.receiver.example
Report-ID: <2002.02.15.1>
(1) Someone looking for “line-wrapped” or anything like it in RFC 5322
will be sad. The term is “folding” (in Section 2.2.3), so probably
change to “folded”.
(2) The example is not, in fact, correctly folded. Please make sure
the “Report-ID” line is indented as required by header field folding.
— Section 3 —
A Mail Receiver might decide not to enact this procedure if, for
example, it relies on a local list of domains for which external
reporting addresses are permitted.
This contradicts the “MUST” above, and it seems like a bad idea.
Local lists can get stale, and having receivers use local lists
doesn’t allow the domain receiving reports to change their mind and
stop them (by removing or changing the permission record). I strongly
suggest taking it out of the standard, as domains with special
circumstances or agreements will do what they want anyway. If we do
leave it in, I would want to see it worded differently, as something
involving an external agreement (rather than something the receiver
does unilaterally).
— Section 6.3 —
Multi-organization PSDs (e.g., ".com") that do not mandate DMARC
usage: Privacy risks for Organizational Domains that have not
deployed DMARC within such PSDs are significant. For non-DMARC
Organizational Domains, all DMARC feedback will be directed to the
PSO. Any non-DMARC Organizational Domain would have its Feedback
Reports redirected to the PSO. The content of such reports,
particularly for existing domains, is privacy sensitive.
This is true only for PSDs that themselves have DMARC records.
Looking at the three paragraphs for the three cases, I’ll note that
.mil (as well as .gov) and .bank do have DMARC records (and they do
specify rua=), but .com does not (nor do .net, .org, .info). That can
change, of course, but if someone reading this should think that the
exposure noted here applies to .com today, that someone would be
misinformed. Do we need to make that clear, or do we think it doesn’t
matter? I think all that would be needed is this:
OLD
Privacy risks for Organizational Domains that have not deployed DMARC
within such PSDs are significant. For non-DMARC Organizational
Domains, all DMARC feedback will be directed to the PSO.
NEW
Privacy risks for Organizational Domains that have not deployed DMARC
within such PSDs can be significant. For non-DMARC Organizational
Domains, all DMARC feedback will be directed to the PSO if that PSO
itself has a DMARC record that specifies an RUA.
END
PSD DMARC feedback MUST be limited to Aggregate Reports. Feedback
Reports carry more detailed information and present a greater risk.
For “Feedback Reports”, did you mean to say “Failure Reports”?
Due to the inherent privacy and security risks associated with DMARC
at the PSD level for Organizational Domains in multi-organization
PSDs that do not participate in DMARC, any feedback reporting related
to multi- organizational PSDs MUST be limited to non-existent domains
except in cases where the reporter knows that PSO requires use of
DMARC.
(1) I don’t think “related to” works. I think “sent to” is right
here. Or am I misunderstanding?
(2) How is one meant to know whether a PSD is single- or
multi-organizational, in the general case. We used to know that when
we had a limited set (the old com, org, net, edu, mil, gov thing), but
there are thousands now, and a human might assume that .starbucks is
single and .coffee is multiple, but the human might be wrong (maybe
Starbucks bought .coffee for itself). And surely humans aren’t
expected to evaluate this manually anyway, and how can the machines
know?
By which I’m saying that I don’t see how this is actionable in practice.
— Section 7 —
* See also the security considerations of dmarc-bis (Section 11).
A citation here would be useful; I suggest this:
NEW
* See also the security considerations (Section 11) of
[I-D.ietf-dmarc-dmarcbis].
END
The appendices should be marked up as such, rather than having section
numbers. But if you can’t easily figure out the right markup for
that, we can leave it to the RPC and check it during AUTH48.
--
Barry, shepherding
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
