Below is a number of “minor issues and editorial comments” on
dmarcbis-30. I have a larger issue regarding the draft as a whole that I
have yet to write up and will post separately.
-Jim
=====
1\. Introduction
----------------
Paragraph 3 introduces alignment, and goes into relaxed and strict
alignment (which seems like a lot of detail this early). But then
paragraph 4 doesn’t talk about alignment at all, but rather whether
the RFC5322.From domain has been authenticated. This seems like a
disconnect from alignment, since it doesn’t say what
“authenticated” means.
Paragraph 5 again jumps terms, from “authenticated” to “passes
verification”. It seems like this means the same thing, and should use
the same term (or at least explain the difference).
Paragraph 5, last sentence: perhaps “should not affect its
reputation.”
Paragraph 6, don’t need quotes
Paragraph 7, “identify, not only sources”: Does “identify” mean
that it claims to know where they came from? Seems like a different word
like “flag existence of mail” might be better.
2.1 High level goals
--------------------
PSOs: Define this abbreviation on this first use. Since it’s talking
about a public suffix, “the domain” doesn’t seem sufficient, maybe
“the domain or suffix”.
Side note: I’m very dubious about the allowances for DMARC records to
be published by public suffixes since the PSO is much less likely to
know the usage of the domains under it, and whether a policy like Reject
is appropriate. But I suspect the WG decided to include the public
suffix policies so this would be a relitigation.
2.2 Anti-Phishing
-----------------
“Claims to come from legitimate senders” — should specify in what
way this claim is made.
“Informed by ongoing efforts” - Can any be cited here? Otherwise
this is a throw-away sentence.
2.4 Out of scope
----------------
Entities other than domains: Public suffixes aren’t (necessarily)
domains, but they aren’t out of scope. I would say authentication at a
finer grain than domain is out of scope.
4.1 DMARC Basics
----------------
Paragraph 1: “verification” again
Paragraph 2: Awkward wording: aligned supported authentication mechanism
Paragraph 5: “feedback component”: maybe “reporting component”?
Feedback seems like an inappropriate term when the reports might go to a
third party and not the purported source.
4.2 Use of RFC5322.From
-----------------------
Second bullet: “most MUAs display some or all of the contents of that
field”. I find this becoming less and less true. Many MUAs that I use,
including Apple Mail (iOS) and Outlook, display only the Display Name,
which is not authenticated at all as pointed out much later (11.4).
Third bullet: “Many high-profile email sources…”: This doesn’t
seem actionable since DMARC does not have a means for the source to
assert that it authenticates the individual sender. So the recipient
would just be guessing.
Last paragraph: I don’t see a profile of RFC5322.From in section 5.7.
4.3 Authentication Mechanisms
-----------------------------
Bullet 1: “verified DKIM-Signature” vs. bullet 2 “SPF, which can
authenticate”.
4.4 Identifier Alignment Explained
----------------------------------
Drop the word “Explained” from the section title.
Paragraph 1: “DKIM authenticates” (compare with Sec. 4.3 use of
“verified”)
Paragraph 2: This would be a much better place to put the examples of
relaxed and strict alignment that appear in later sections. The
definitions weren’t sufficient for me.
Paragraph 3: Also site the profile of RFC5322.From (wherever it is) when
talking about non-compliant cases.
4.4.1 DKIM-Authenticated Identifiers
------------------------------------
Paragraph 1: Authenticity of the Author Domain: “Authenticity” seems
more like it has to do with whether it’s a real domain or not. Maybe
“association with” or something like that?
Paragraphs 2-4: This would be better back in Sec. 4.4 and reference back
to it.
Paragraph 5: “aligned and verified”. “Authenticated and aligned”
maybe?
4.4.2 SPF-Authenticated Identifiers
-----------------------------------
Paragraphs 2-4: Repetitive; also better back in Sec. 4.4. Or is there
some subtle difference between SPF and DKIM alignment that I missed?
4.5 Flow Diagram
----------------
This diagram and accompanying explanation doesn’t help me at all.
“Solid lines”: Dashed lines, maybe?
4.6 DNS Tree Walk
-----------------
Step 2 starts talking about the psd flag without telling what it is. It
would be much better if this discussion came after the flags and their
meanings was introduced.
I’m concerned that some (admittedly rare) public suffixes with
multiple components are not well served by this algorithm, such as
pvt.k12.ma.us.
What happens if a domain that is not a public suffix publishes psd=y,
either accidentally or maliciously?
Side note: I got well into this document before I realized that DMARC is
publishing an assertion of being a public suffix. Some mention of that
belongs back in the introduction.
4.7 DMARC policy discovery
--------------------------
Paragraph 3: “domain does not exist”: How is that determined,
NXDOMAIN, NODATA? What happens with SERVFAIL (e.g., DNSSEC problem) or
no response? And if a domain really doesn’t exist, isn’t that a
reason to reject “with prejudice”?
Paragraph 4 bullet 1: “syntactically valid”: It seems like there are
a lot of URIs with valid syntax that would not make sense here. What if
someone publishes [sip://example.org](sip://example.org) or
[gopher://example.org](gopher://example.org)? Also, don’t a lot of
these things that have to do with reporting belong in one or both of
those drafts (which I haven’t read yet)?
4.8 Organizational Domain Discovery
-----------------------------------
Paragraph 2, bullet 2: “DMARC mechanism does not apply”: What if
there is a PSO policy? Or is that covered by the tree walk? (I may have
gotten lost here)
5\. Policy
----------
Paragraph 2: “A Domain Owner…may choose not to participate...by not
publishing an appropriate DNS TXT record”. But what if the PSO did? If
they disagree with that record, they do need to publish a TXT record of
their own, don’t they?
5.3 General Record Format
-------------------------
Finally, a definition of those tags I have been reading about! I think
this belongs much earlier.
adkim and aspf: “Domain Owner requires”: should this be Domain Owner
or PSO requires?
fo, rua, ruf: Should these be in the reporting documents instead?
sp: “applies only to subdomains”: Does this mean an immediate
subdomain or sub-subdomain, etc.?
5.5.3 Setup a Mailbox…, 5.5.5, etc
----------------------------------
Does this belong in the reporting documents?
6\. DMARC Feedback
------------------
Again, I don’t think “feedback” is the best term here.
7\. Changes
-----------
The changes section usually appears very close to the end.
7.5.1 Tags Added
----------------
Probably inappropriate to cite \[RFC9091\] in this way — it’s being
obsoleted, and this looks like a normative reference.
8.6 Interoperability Considerations
-----------------------------------
Paragraph 1: Alumni forwarders can also break DKIM signatures (although
frequently not), and this should be acknowledged.
10.1 Aggregate Report Considerations
------------------------------------
Aggregate reporting could reveal sensitive traffic patterns, for example
if Company A is in the process of an acquisition of Company B.
11.4 Display Name Attacks
-------------------------
This goes to one of the overarching concerns I have about DMARC. I am
getting lots of spam and phishing with plausible display names but
obvious throwaway addresses controlled by attackers. “Further
exploration…needs to be undertaken” is not a sufficient response
IMO.
Paragraph 3, bullet 2: Since this is easily defeated, why even mention
it?
11.5 Denial of DMARC Processing Attacks
---------------------------------------
Paragraph 3: Regarding multi-valued From, I thought these were out of
scope. They are not a “particular challenge” then.
References
----------
RFC7489 and RFC9091 should not be listed as normative references; they
are being obsoleted by this document.
A.3 Sender Header Field
-----------------------
I don’t recall any use of Sender by DomainKeys. Where I do remember it
was in Microsoft’s alternative to SPF, SenderID \[RFC4406\].
A.4 Domain Existence Test
-------------------------
This is the sort of thing I was looking for in Sec. 4.7 paragraph 3:
this needs normative language saying how nonexistence of the domain is
to be established.
A.5 Issues with ADSP in Operation
---------------------------------
Maybe include an informative reference to \[RFC5617\] here.
Item 1: Wildcards cannot be used, as RFC 5617 points out, because it
isn’t possible to wildcard anything except the first element. One
can’t wildcard \_adsp.\*.example.com. A tree walk was proposed and
extensively discussed for ADSP, but working group consensus was that it
was harmful to include (overhead, etc.).
Item 2: NXDOMAINs were considered out of scope for ADSP because ADSP is
a policy published by the author domain, and there is no way to publish
a policy for a nonexistent domain. The same argument could apply to
DMARC as well.
Item 5: DMARC also has no mechanism for a slow rollout now that the pct:
tag has been removed.
Item 6: ADSP has an intermediate policy, “all”. ADSP policies are
declarative rather than imperative because WG consensus was that the
author domain can’t tell the recipient what to do, hence “all”
rather than “quarantine” and “discardable” rather than
“reject”.
A.6 Organizational Domain Discovery Issues
------------------------------------------
It seems much safer to just point to RFC 7489 for a description of the
PSL method than to repeat it here, where a non-careful reader might
think that this is a recommended method.
A.7 Removal of the “pct” tag
----------------------------
Already mentioned in 7.5.2, I don’t think this much description is
needed for something that isn’t part of the spec.
??? Not Found
-------------
I expected to find some text at least recommending a rewriting strategy
for From addresses to be used by mailing lists and the like. But I guess
that’s in RFC 7960, which is informational, so you can’t reference
that normatively. Not sure what to do about that._______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
