On Tue, Oct 20, 2015 at 5:01 AM, <[email protected]> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain-based Message Authentication,
> Reporting & Conformance Working Group of the IETF.
>
> Title : Interoperability Issues Between DMARC and
> Indirect Email Flows
> Authors : Franck Martin
> Eliot Lear
> Tim Draegen
> Elizabeth Zwicky
> Kurt Andersen
> Filename : draft-ietf-dmarc-interoperability-08.txt
> Pages : 23
> Date : 2015-10-19
>
> Abstract:
> DMARC introduces a mechanism for expressing domain-level policies and
> preferences for email message validation, disposition, and reporting.
> The DMARC mechanism can encounter interoperability issues when
> messages do not flow directly from the author's administrative domain
> to the final recipients. Collectively these email flows are referred
> to as indirect email flows. This document describes interoperability
> issues between DMARC and indirect email flows. Possible methods for
> addressing interoperability issues are presented.
>
>
Sorry it took me so long to get to this, but here's the review I managed to
crank out on my flight to Tokyo today. It's largely editorial.
Section 2:
- I think p=none should be quoted.
Section 2.1:
- s/domain the SPF analysis/domain that the SPF analysis/
...or better yet:
"domain checked by SPF"
- s/Also note that/Also note that the/
- s/different from/different from the/
Section 2.2:
I can't parse the last bullet in the list. Should it be "...will likely be
in a different organizational domain than the..." ?
Section 2.3:
- s/here mentionned/mentioned here/
- s/headers and body/header and body/ (either both singular or both plural)
- s/whitespace folding/whitespace and folding/ (we also deal with
consecutive unfolded whitespace)
- "While the prevalence is unknown" -- Do we not have stats on this by now?
- s/checkers which/verifiers that/
Section 3.1.1:
- s/domains which publish/domains that publish/
Section 3.1.2.1:
- s/domain might also/domain could also/ (just for contrast with the
previous bullet)
Section 3.1.2.2:
- s/headers to bring headers/headers to bring them/
Section 3.2:
- s/Mail From/RFC5321.MailFrom/
Section 3.2.1:
- s/freemail/free email ("freemail")/ (define on first use)
Section 3.2.3:
- The bullet list has an odd format in terms of punctuation. Suggest:
o thing1;
o thing2; and
o thing3.
- The final bullet could reference RFC6377, which talks about that very
problem in more detail.
Section 4:
- s/still used and/still used, although/
- s/Ezmlm/ezmlm/ (2x)
- s/still deployed and has not/still deployed but has not/
Section 4.1.1.1:
- define "bounces" on first use; I think RFC5321 or RFC5322 has a more
formal definition
- s/risks which should/risks that should/
- "carefully managed" -- doesn't RFC6376 discuss this? If so, a reference
would be prudent here.
Section 4.1.1.2:
- end of first bullet: doesn't RFC6376 talk about this as well?
Section 4.1.3.3:
- s/policy which/policy that/
- Is that fist bullet talking about things like "On behalf of"? Also, what
sort of collision is the concern here?
- second bullet: s/Another mitigation policy is to configure/Configuring/
(for consistency with the second bullet)
- third bullet: s/Another mitigation policy, is to configure/Configuring/
- fourth bullet: s/Another mitigation policy, is to reject/Reject/
- s/understood and adjusted to/understood and accommodated/
Section 4.2:
I'm generally unsure about this section. It will eventually (sooner than
later) refer to a number of expired documents. It might be more helpful to
the reader to just summarize the idea behind each approach in a paragraph
rather than forcing the reader to chase down specific expired I-Ds.
The description of conditional signatures is over-reaching; there's no
requirement that the forwarder's signature "fully" sign the message.
A better description for dkim-list-canon: "record a canonical list posting
format for signing, so that typical MLM changes do not invalidate
signatures” or something.
- s/provides a proposed mechanism to provide/proposes a mechanism to
provide/
Section 6:
Suggested simplifications:
Section 4.1.1.1 discusses appropriate DKIM key management with third party
email senders.
Section 4.1.3.3 warns that rewriting of the RFC5322.From header field and
changing the domain name should not be done with any domain.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
