Thanks for putting this together. Here are the results of a late-night
first-time reading:
Section 2:
The sentence starting "This the secondary" appears to be mangled. I can't
parse it.
Section 2.1, paragraph 1:
The first sentence reads like a basic tautology: "A fundamental aspect of X
is the method of X." I think you could strike that sentence, and add "to
message source validation" to the next one, and it's more readable while
saying the same thing.
Also, I believe it should be DKIM and SPF, not DKIM or SPF.
"organizational domain" should be defined before first use here. I suggest
capitalizing it ("Organizational Domain") and indicating, perhaps in
Section 1, that the definition of it is in dmarc-base.
Section 2.3:
MIME should be at least an informative reference given the discussion here.
Section 3.1.1:
"5322.From header" should be "5322.From header field". Also, I suggest
calling it the RFC5322.From header field (including "RFC") to align with
what's in dmarc-base, though that's not strictly necessary. (This appears
throughout the document, not just this section.)
There's a reference to "authenticated domain identifiers", but also a
reference earlier to "Authenticated Identifiers". Should we just pick one
and stick to it? The latter seems better since we have an existing
definition in dmarc-base to reference.
Suggest "aligned with" instead of "related to", to use consistent
terminology.
Section 3.1.2.1:
s/8bits/8-bit/
s/7bits/7-bit/
Section 3.1.2.2:
s/transfers message,/transfers a message/
Section 3.2.1:
s/alternate/alternative/
The list of ways aliasing can happen isn't complete; for example, an MTA's
alias table isn't covered. The way one sets up forwarding in
Outlook/Exchange is probably something else again. I suggest including
"such as".
The "local-part of the addr-spec" -- Which addr-spec are you referring to?
Section 3.2.3:
Might want to mention that RFC7372 was produced to help this, but it's too
early to tell if it's going to be successful.
The unsubscribe problem is described in RFC6377, and I think also in
dmarc-base. A reference from here might be helpful.
Section 3.3:
Change "...." to "etc."
Section 4:
I think we need to say something here about the uphill battle of getting
any or all of these suggestions into widespread adoption.
Section 4.1:
I wouldn't call dkim-list-canon "light transformations", but rather
something like "constrained transformations". You could add a gigantic
MIME part under that proposal and still be able to recover some valid
content.
Section 4.3:
RFC6648 discourages the use of X- header field names, and I don't think
"X-Original-From" was ever registered or otherwise permanently described,
so is it a good idea to include it here?
In the next paragraph you refer to "Original-From". Is that one registered?
Section 4.3.1:
This isn't a complete sentence.
Section 4.4.1.3:
There's too much comma splicing going on here. Suggest a rewrite.
Also, I don't understand the point about considering that syntax
"suspicious".
Section 4.5.1:
Some mitigations are described in RFC6377, if that might be helpful to
reference here. Also, it looks like another place where RFC7372 might be
useful.
Section 4.6:
s/alignement/alignment/
Section 5:
More traditionally:
"This document contains no actions for IANA. [RFC Editor: Please delete
this section prior to publication.]"
Section 6:
More traditionally:
"This document is an analysis of DMARC's impact on indirect email flows.
It describes the possibility of accidental denial-of-service that can be
created by false rejections of messages by DMARC-aware Mail Receivers.
However, it introduces no new security issues to Internet messaging."
-MSK
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
