Below is my participant review of draft-ietf-dmarc-dmarcbis-15. I
have two other change proposals that are more substantive and go
beyond "review comments", so I will post those separately for Todd to
track as issues and for further working group discussion.
— Section 1 —
Abusive email often includes unauthorized and deceptive use of a
domain name in the RFC5322.From header field.
This would benefit from a reference. Maybe reword it this way, to set
up for subsequent uses?:
NEW
Abusive email often includes unauthorized and deceptive use of a
domain name in the “From” header field, defined in section 3.6.2
of [RFC5322] and referred to as “RFC5322.From”.
END
As with SPF and DKIM, DMARC classes results as "pass" or "fail".
I had to read this a few times to sort out the use of “classes” as a
verb (I was trying to parse it as a noun). Maybe “classifies” or
“categorizes” instead?
Therefore,
reputation assessment of that stream by the mail-receiving
organization is not encumbered by accounting for unauthorized use of
that domain in the RFC5322.From field.
Does it make sense to put this in positive wording rather than negative, as:
NEW
Therefore,
reputation assessment of that stream by the mail-receiving
organization can assume that the use of the domain in the RFC5322.From
field is authorized.
END
— Section 2.4 —
* Attacks in the RFC5322.From header field, also known as "display
name" attacks;
As it does deal with the addr-spec portion of RFC5322.From, maybe it
would be better this way?:
NEW
* Attacks in the display-name portion of the RFC5322.From header
field, referred to as "display name attacks”;
END
— Section 3.2.3 —
The term "owns"
here indicates that the entity or organization being referenced holds
the registration of that DNS domain.
Is holding the registration really the right angle? If someone is
providing a service at example.org and gives out
barryleiba.example.org for my use, I could be the domain owner for
DMARC purposes, but I don’t “hold the registration”. I might even
have complete control of the DMARC record for barryleiba.example.org.
Maybe “has legitimate control of the use of that DNS domain, most
often by holding its registration.” ?
— Section 4.2 —
* Of all the identifiers that are part of the message itself, this
is the only one guaranteed to be present.
I think I would say “required”, rather than “guaranteed”.
* Many high-profile email sources, such as email service providers,
require that the sending agent have authenticated before email can
be generated.
“has” authenticated, for agreement with “the sending agent”.
* The absence of a single, properly formed RFC5322.From header field
renders the message invalid.
I suggest:
NEW
* The absence of a single, properly formed RFC5322.From header field
renders the message invalid — non-compliant with [RFC5322].
END
— Section 4.4.1 —
DMARC requires Identifier Alignment based on the result of a DKIM
authentication because a message can bear a valid signature
“based on” seems odd here. Maybe:
NEW
DMARC requires that Identifier Alignment be applied to the result of
DKIM authentication because a message can bear a valid signature
END
— Section 4.4.2 —
DMARC permits Identifier Alignment based on the result of an SPF
authentication. As with DKIM, Identifier Alignement can be either
strict or relaxed.
Same comment as above. Also, is “permits” right here? Isn’t
alignment required either way — don’t we always have to make sure that
the authenticated MailFrom is aligned with the RFC5322.From?
— Section 5.5.2 —
I suggest adding more information here as follows:
ADD
While it is possible to secure a DMARC pass verdict based on only SPF
or DKIM, it is commonly accepted best practice to ensure that both
authentication mechanisms are in place in order to guard against
failure of just one of them. This is particularly important because
SPF will always fail in situations where mail is sent to a “forwarding”
address offered by a school or other institution, where the address
simply relays the message on to the recipients current “real” address.
Many recipients use such addresses, and with SPF alone, and not DKIM,
messages sent to such users will always produce DMARC fail.
The Domain Owner SHOULD choose a DKIM-Signing domain (i.e., the
d= domain in the DKIM-Signature header) that aligns with the Author
Domain.
END
— Section 5.5.4 —
Once SPF, DKIM, and the aggregate reports mailbox are all in place,
it's time to publish a DMARC record. For best results, Domain Owners
SHOULD start with "p=none", with the rua tag containg a URI that
references the mailbox created in the previous step.
I think this is a “should”, not a BCP 14 “SHOULD”. And maybe
highlight the connection to the next section, as:
NEW
Once SPF, DKIM, and the aggregate reports mailbox are all in place,
it's time to publish a DMARC record. For best results, Domain Owners
should start with "p=none" (see Section 5.5.5), with the rua tag
containg a URI that references the mailbox created in the previous step.
END
— Section 5.7.2 —
5. Conduct Identifier Alignment checks. With authentication checks
and policy discovery performed, the Mail Receiver checks to see
if Authenticated Identifiers fall into alignment as described in
Section 4.4. If one or more of the Authenticated Identifiers
align with the RFC5322.From domain, the message is considered to
pass the DMARC mechanism check. All other conditions
(authentication failures, identifier mismatches) are considered
to be DMARC mechanism check failures.
I find the last sentence to be confusing as part of the whole
paragraph, to the point where I’m not sure what it’s actually meant to
say. If I have three DKIM sigs and an SPF check, the SPF check fails,
one of the DKIM signatures fails, and one of them is not aligned… but
the third DKIM signature validates and is aligned, then the DMARC
mechanism check passes (according to the third sentence). What is the
fourth sentence trying to tell me here?
I worry that readers will think that those other failures make the
DMARC mechanism check fail, and bullet 6 gets a “fail”.
— Section 10.3 —
* Signing DNS records with DNSSEC [RFC4033], which enables
recipients to detect and discard forged responses.
To differntiate what DNSSEC does and what, say, DoT and DoH do with
respect to response forging, I suggest this:
NEW
* Signing DNS records with DNSSEC [RFC4033], which enables
recipients to verify the integrity of DNS data and detect
and discard forged responses.
END
--
Barry
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
