Subject: Re: [ietf-dkim] Nits with section 4 Detailed Description

From: Jim Fenton <[email-masked]>
Date: Wed, 07 Nov 2007 17:37:31 -0800

Arvel Hathcock wrote:
> Yet more suggestions:
>
> 4.1  DNS Representation
>
>      "Sender Signing Practices records" -> "Sender Signing Practices
> Records" (assuming you agreed to the previous suggestion of making
> this an explicit definition change in 2.7).

Agreed.
>
>       "Records not in compliance with that syntax or the syntax of
> individual tags described in Section 4.3 MUST be ignored"    This
> seems like you're saying two things:  First, records with overall
> syntactic problems (like SPF record put into SSP location) should be
> ignored.  Second, that records with individual tags that are not
> syntactically correct result in the entire SSP record being ignored
> (rather than the specific tag in question being ignored).  Is this
> what you mean?

No, it isn't, I meant what Section 4.3 says, which is, "Unrecognized
tags MUST be ignored," although I mean that the lack of a tag which is
REQUIRED does invalidate the entire record.  I'll correct the inconsistency.
>
>      "for purposes of message disposition,"  - I would just delete
> this bit as it's not necessary and could stur up the distaste some
> have with the entire question of SSP determining message disposition.

Uh, OK.  I guess it's not strictly required.
>
>     "SSP records for a domain are published at a location...."  -  I
> keep forgetting where this is and trying to find it in the document is
> not as easy as it could be yet this is a major issue of practicality. 
> I think this is just my own stupidity coming into play but perhaps
> this point could be highlighted with a 4.1.1 and a title of like "SSP
> location in DNS" and maybe it should be put into 4.2 since that
> section is entitled "Publication of SSP Records".

I agree it fits in section 4.2 and will think about how to structure that.

>
> 4.2   Publication of SSP Records
>
>     I see we have done away with the tree-walking completely which I
> think is great.

:-)

>
> 4.3  Record Syntax
>
>    So, if I encountered an SSP record with dkim=foo this value is
> invalid and so the SSP contains a tag that is syntactically
> incorrect.  This causes the rejection of the entire SSP record
> right?   If so, I think this should be made more clear because I
> missed it.  Is this what the text in 4.1 is saying?

The syntax of the tag-value is incorrect, so it should be thrown out,
and since the tag is REQUIRED that renders the record invalid.

>
>  The descriptive text for "all", "strict", "process" should be
> indented some to aid readability.

I'm probably limited there by what XML2RFC does.

>
>    Non-Normative Rationale:  Strict may also be used by domains who
> simply don't want their domain spoofed.  Not sure if you want to say
> something about that or not.

I'd rather not say that because it depends on the definition of "spoof",
which is a can of worms.  You'll notice that "spoof" is not used in a
normative context in the document.

>
>   The section on "process" says that messages "SHOULD be processed by
> the verifier" - that's good because this is what got us the result of
> "process" in the first instance :P   
>    Suggested rewrite:          process - Messages which are Suspicious
> from this domain SHOULD NOT be rejected although an SSP failure MAY be
> considered in subsequent evaluation of the message.

It does sound a bit circular, but if we had used the keyword "foo" you
probably wouldn't have had a problem with the word "process" in the
definition, right?  I don't think we should have to approach the
definition indirectly just because we chose a mnemonic keyword.  Also,
the definition you propose doesn't have the exact same meaning.  The
current definition boils down to "do what you would normally do with the
message, but consider the SSP result if you want" which is different
from "SHOULD NOT be rejected" since what one might "normally do" might
include rejecting the message.
>     "intende" -> "intended"

Can't find that -- did your printer cut it off?

>
>  Suggested rewording of the t=y text:
>
>    "The domain is testing Sender Signing Practices and the message
> SHOULD NOT be considered Suspicous based solely on it's results."

Solely?  SSP is the sole determiner of Suspicious (which I should have
capitalized), so I'm not sure what you're getting at.  How about: 
"...the Verifier SHOULD NOT consider the message Suspicious."

-Jim
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Wed, 07 Nov 2007 21:02:49 -0500

> "...the Verifier SHOULD NOT consider the message Suspicious."

Small comment.

I was preferred the approach for outlining WHAT is expected in the 
protocol design and when there is a deviation from the expectation, then 
the insights about what is or is not viewed as suspicious should be 
worked out.

Case in point,  t=y (testing mode).

Do you really believe that verifiers are going to tolerate a "MUST NOT" 
be view as suspicious for a domain that is perpetually in testing?

What is the expectation behind the testing?

Should it be limited?  How long should one continue to process a t=y 
site?  What is is always a failure?

Another is the MX issue.

What if the SMTP system already has a MX concept BEFORE that data stage 
or the mail is accepted?   How are the results to this apply to any DKIM 
fascimile in the message?  Should a pre-emptive MX lookup result be pass 
to the headers to help verifiers skip the DKIM processing if a NXDOMIN 
is found?

I don't think enough is place in the SSP/DKIM specs about tolerance for 
failure where things continuely to go wrong but the specs recommend no 
action.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 08 Nov 2007 11:11:04 -0600

Understood, thanks for clearing me up on these points!   I'm happy with 
what you said about each point.

Arvel