Subject: [dmarc-ietf] Comments on dmarc-base-09

From: Jim Fenton <[email-masked]>
Date: Mon, 05 Jan 2015 13:43:08 -0800

I went back over my -04 comments while looking at -09, and the great
majority have been resolved. There are still a few things that haven't
been adequately addressed, as far as I can tell, nor resolved on-list. 
I haven't thoroughly gone through the -09 draft, and don't think that
would yield much new at this point.

Here are the residual items. Apologies if I'm re-raising something that
has been discussed, but I forgot about. Section numbers have been
corrected for the -09 draft.

Section 3, definition of Report Receiver: "...reports about the messages
claiming to be from a third party." Comparing with the previous
sentence, the third party referred to here seems to be another operator
that is sending reports to the Report Receiver. Suggest substituting,
"...reports about messages relating to another operator."

Section 3.1/3.2, organization nit: It seems a little odd for the
Overview and Authentication Mechanisms to be subsections of the
Terminology and Definitions.

Section 5.3, definition of fo: parameter: I had reported that there
isn't any prohibition on specifying both 0 and 1, and I thought someone
said that was fixed but I can't find it. More generally, I struggle to
find any real utility for a colon-separated list of options here.

Section 5.3, definition of pct: parameter: "However, this MUST NOT be
applied to the DMARC-generated reports, all of which must be sent and
received unhindered." This is strong normative language, but there is no
procedure specified anywhere for how to identify a DMARC-generated
report in order to apply this requirement. Consider the possibility that
bad actors may try to craft messages to look like DMARC reports.

Section 6.1, paragraph 3: "...the following verification steps are to be
taken"  It looks like this was changed in response to my earlier
objection to a SHOULD here, but now we have language that isn't clear.
Suggest "...the following verification steps MUST be taken"

Section 6.3, paragraph 4, "The format for failure reports is defined in
[AFRF]."  This is redundant with the previous paragraph and can be deleted.

Section 6.2.1.1, "The filename is typically constructed..." Again, this
is fuzzy normative language; it sounds like it's trying to say, "The
filename MAY be constructed..."

Section 6.3.1: "Operators implementing this specification also
implement..."  This needs a normative term, SHOULD or MUST. Not sure
which one.  Again, I think the SHOULD requirement on the Subject header
field is likely to trick an implementer into depending on it, and you
can't unless it's a MUST. The information is included in the report anyway.

Not mentioned anywhere: Which SPF modes are considered to be a "pass"
for purposes of DMARC? Presumably +, presumably not -, but it should say
something about ? and ~ if it doesn't already.

-Jim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Jan 2015 14:11:17 -0800

> would yield much new at this point.

Unfortunately, -10 is now current per feedback received last week.  I had
expected that to be the last one, especially this close to the telechat.
However:

> "...reports about messages relating to another operator."

Fixed, since it's minor.

> Terminology and Definitions.

Actually I think this is more major than a nit, even though it's really the
result of an unfortunate little XML error.  This is the main reason I'm
preparing a -11 now (sigh).

> find any real utility for a colon-separated list of options here.

I'm inclined to punt this to the working group to sort out if it decides
this is a problem.  It's too late in this document's lifecycle to be making
possibly non-trivial syntax or semantic changes such as this.

> bad actors may try to craft messages to look like DMARC reports.

Same answer here.  This is an ISE document recording current practice; it's
OK for us to have gotten technical details wrong, and up to the working
group to decide if and how to fix them.

> Suggest "...the following verification steps MUST be taken"

What's the normative difference between "are to be taken" and "MUST be
taken"?  In either case, if you don't take these steps, you're
non-compliant.  Either way, the risk is already described.

> [AFRF]."  This is redundant with the previous paragraph and can be deleted.

Removed; redundant it is.

> filename MAY be constructed..."

This is intentionally not normative, and thus also something to be decided
by the WG at this stage.

> can't unless it's a MUST. The information is included in the report anyway.

I believe Pete, and probably others, would assert that the present language
is normative.  RFC2119 terms are not the only ways we have to say normative
things.

> something about ? and ~ if it doesn't already.

Not only is that another late-stage technical issue to punt to the working
group, but I also claim that's a layering violation.  SPF simply reports a
pass/fail/temperror/etc.  It's not the purview of DMARC to ask what kind of
"pass" it was any more than it is the purview of DMARC to ask which header
fields or how much body was covered by an aligned DKIM signature. Neither
SPF nor DKIM report those things.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 05 Jan 2015 18:10:04 -0500

> On Mon, Jan 5, 2015 at 1:43 PM, Jim Fenton <[email-masked]> wrote:
...
> SPF nor DKIM report those things.

Right, pass is pass.  The more interesting question is what is fail.  I think 
with the recent hand wringing over temporary DNS errors we can reasonably say 
that fail is not pass or temporary DNS error.  I don't think the spec needs 
further changes in this regard.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 6 Jan 2015 02:18:59 -0000

>group, but I also claim that's a layering violation.

RFC 7208 is quite clear about what constitutes an SPF pass.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Tue, 06 Jan 2015 10:21:18 -0800

> RFC 7208 is quite clear about what constitutes an SPF pass.

Perhaps it should be referenced rather than RFC 4408 then.

-Jim

---

From: "John R Levine" <[email-masked]>
Date: 6 Jan 2015 13:25:05 -0500

> Perhaps it should be referenced rather than RFC 4408 then.

Right, 4408 is now obsolete.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 6 Jan 2015 11:41:35 -0800

> Right, 4408 is now obsolete.

Fixed in -11.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Tue, 06 Jan 2015 15:50:22 -0500

> Right, 4408 is now obsolete.

Not operationally.

SPF PASS is what "Local Policy" implementation options has allowed for 
the last past 10 years. In our package implementation, an +ALL policy 
is acceptable by default (option is provided to continue testing 
additional filtering scripts).  For the most part, we are looking for 
the obvious failure which is where the highest payoff is realized. 
All else pretty meaningless or not well defined how to best handle the 
anonymous, unsolicited +ALL policy checks.

-- 
HLS