Subject: [dmarc-ietf] Comments on draft-ietf-dmarc-interoperability

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 30 Jan 2015 01:23:48 -0800

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

---

From: Franck Martin <[email-masked]>
Date: Fri, 30 Jan 2015 18:05:31 -0600 (CST)

----- Original Message -----

> From: "Murray S. Kucherawy" <[email-masked]>
> To: [email-masked]
> Sent: Friday, January 30, 2015 1:23:48 AM
> Subject: [dmarc-ietf] Comments on draft-ietf-dmarc-interoperability

> Thanks for putting this together. Here are the results of a late-night

Thanks for suggestions after late-night reading 

> The sentence starting "This the secondary" appears to be mangled. I can't

Me neither yet, it is Friday, asking co-authors for suggested text, will fix later... :P 

> Section 2.1, paragraph 1:

Fixed all the rest, you can see a diff at 
https://github.com/dmarc-ietf/id/commit/24ccb9507086e05732ff477ec7330a481bebcee9#diff-8b30e28a625f335e70d97d9b89dcd243 

if you are ok, and when I have section 2, I'll push as -01.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 30 Jan 2015 16:36:09 -0800

That diff format is a little challenging.  You might try using "rfcdiff",
which eliminates a lot of the reporting of changes that amount to just
moving across page breaks and the like.

Anyway, I'll give it a thorough review this evening.  Thanks for the quick
turnaround!

-MSK

On Fri, Jan 30, 2015 at 4:05 PM, Franck Martin <[email-masked]>
wrote:

> ------------------------------
>
> *From: *"Murray S. Kucherawy" <[email-masked]>
> *To: [email-masked]
> *Sent: *Friday, January 30, 2015 1:23:48 AM
> *Subject: *[dmarc-ietf] Comments on draft-ietf-dmarc-interoperability
>

---

From: Franck Martin <[email-masked]>
Date: Fri, 30 Jan 2015 19:32:02 -0600 (CST)

----- Original Message -----

> To: "Franck Martin" <[email-masked]>
> Cc: [email-masked]
> Sent: Friday, January 30, 2015 4:36:09 PM
> Subject: Re: [dmarc-ietf] Comments on draft-ietf-dmarc-interoperability

> moving across page breaks and the like.

Using github tools... :( 

The diff of the xml later on that page is may be easier to read.