I finally managed to finish my review of the DMARCbis. I think it is
in good enough shape to go forward but here are my comments when
reviewing it:
----------------------------------------------------------------------
Section 3.2.6 is conflicting with later text.
Historically, Domain Owner Assessment Policies of "p=quarantine" or
"p=reject" have been higher value signals to Mail Receivers (#mail-
receiver). Messages with Author Domains for which such policies
exist that are not validated using the DMARC mechanism will not reach
the inbox at Mail Receivers that participate in DMARC and honor the
Domain Owner's expressed handling preference.
I think we should add note, that even if this was true before,
DMARCbis now says that in case of DMARC fail the mail receivers
handling can be influenced by DMARC policy record, but also other
considerations should be taken care of.
----------------------------------------------------------------------
Section 4.5 says:
Per [RFC1035], a TXT record can comprise several "character-string"
objects. Where this is the case, the module performing DMARC
evaluation MUST concatenate these strings by joining together the
objects in order and parsing the result as a single string.
This text is fine when we are talking about one TXT record, but some
implementors might read it to talk about multiple TXT records, so
perhaps a note about that should be added. So character-strings inside
one TXT records are concatenated, but each TXT record is processed
separately.
----------------------------------------------------------------------
It would be better to use name of the RFC when referencing to it, and
only use the number in the [RFC1234] part, i.e., instead of saying:
Readers are encouraged to be familiar with the contents of [RFC5598].
it would be better to say:
Readers are encouraged to be familiar with the contents of
Internet Mail Archtecture ([RFC5598]).
The rfc numbers 1035, 8020, 4343 etc might be familiar to writers of
this document, but there are most likely lots of readers who are not
as familiar with them, and expanding them in the document will make it
easier for people who do not have full RFC mapping from all RFC
mumbers to document title in memory, to read this document.
Same should apply to the internet draft names also, as while the
[I-D.ietf-dmarc-aggregate-reporting] actually tells what that document
is, but when it gets replaced with RFC9951 and RFC10923 even people
who are familiar with number to title mapping now, might have to
update their internal mapings... I.e., instead of saying:
DMARC, in the associated [I-D.ietf-dmarc-aggregate-reporting] and
[I-D.ietf-dmarc-failure-reporting] documents, also specifies a
reporting framework.
say:
DMARC, in the associated Aggregate raporting specification
([I-D.ietf-dmarc-aggregate-reporting]) and Failure Reporting
specification ([I-D.ietf-dmarc-failure-reporting]) documents, also
specifies a reporting framework.
Getting new people to be involved is hard anyways, and making it
harder by forcing everybody to learn lots of different number -> title
mappings makes it even harder.
I am very familiar with certain subset of the RFC numbers (ipsec,
security area etc), but most of the email RFC numbers are new to me,
so while I was reviewing this, I always needed to go and check those
numbers, which made reading it more difficult.
----------------------------------------------------------------------
In section 4.10 step 1, there is text saying:
1. Query the DNS for a DMARC Policy Record at the appropriate
starting point for the Tree Walk. A possibly empty set of
records is returned.
what is this "appropriate starting point" used here? It is not defined
before, and for the first read it seems like something is missing. It
will be defined in the 4.10.1, but adding reference to that section
here would make things easier, or even move the starting point
definition from there to here, or before this section.
Or perhaps move the actual tree walk steps from the section 4.10 DNS
Tree Walk to come after 4.10.1, i.e. add new "4.10.2 DNS Tree Walk
Steps", and move text:
The generic steps for a DNS Tree Walk are as follows:
...
<end of 4.10>
there.
----------------------------------------------------------------------
5.4. Policy Enforcement Considerations
At a minimum,
Mail Receivers SHOULD add the Authentication-Results header field
(see [RFC8601]), and it is RECOMMENDED when delivering messages that
fail the DMARC validation check.
What is this text trying to say. It seems to say authentication-
results header is SHOULD, but it is also SHOULD when DMARC validations
fails? Perhaps just change "...it is even more important when ...".
----------------------------------------------------------------------
10.6. External Reporting Addresses
To avoid abuse by bad actors, reporting addresses generally have to
be inside the domains about which reports are requested.
Is there any special cases we should think when talking about public
suffix domains, i.e., what if the subdomain of the PSD points to the
higher up to the tree, i.e., listat.iki.fi has dmarc record having rua
pointing to iki.fi while iki.fi is PSD, thus is outside the
organizational domain (listat.iki.fi). Or does the listat.iki.fi need
to have rua that points to *.listat.iki.fi or listat.iki.fi, or does
the iki.fi need to have TXT records allowing listat.iki.fi to report
to it??
----------------------------------------------------------------------
Appendix C. Changes from RFC 7489
This document is intended to render obsolete [RFC7489].
I think this should say "This document intends to obsolete RFC7489."
or "This document is intendeded to render RFC7489 obsolete.". The
current sentence looks funny.
----------------------------------------------------------------------
The tree walk procedure is quite complicated and it took me several
hours to parse what it means for different cases for iki.fi (which is
PSD that also sends emails). I created a wiki page of my parsing of
the tree walk procedure with different cases in iki [1], and I hope I
managed to properly parse the process. It looks like things will work
fine with iki.fi and dmarc (on the other hand we would be even happier
if we could get rid of the SPF completely from the DMARC and from the
world :-)
Anyways I think we are going to need a test vectors for the tree walk
procedure. I.e., real DNS records having dmarc records and then a list
of test saying:
Inputs:
- from: [email protected]
- RFC5321.MailFrom: [email protected]
- Dkim: d= psd-domain.dmarc-testvectors.com
- SPF source ip: a.b.c.d
Result:
- Author domain: psd-domain.dmarc-testvectors.com
- Authenticated identifiers: psd-domain.dmarc-testvectors.com
- Organizational domain: psd-domain.dmarc-testvectors.com
- DKIM: Aligned
- SPF: Aligned
- DMARC: pass
and for all kind of cases, including psd=y, psd=n, no dmarc, etc...
[1] https://ikiwiki.iki.fi/faq/ikidmarcbis
--
[email protected]
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
