Subject: [ietf-dkim] Comments on draft-ietf-dkim-ssp-requirements-03

From: Jim Fenton <[email-masked]>
Date: Fri, 30 Mar 2007 16:11:04 -0700

With apologies that this didn't get done before (I think) the last day 
of WG last call, here are my comments on ssp-requirements-03. 

1. Introduction

"first party" is used here before being introduced.  Should probably 
either refer ahead to the glossary or use a term like "author" that is 
less jargony.

"a priori" is overused, perhaps inappropriately.  Suggest s/there is no 
expectation of a priori knowledge/there is in general no knowledge/   
Also "a priori invalid" doesn't make sense, because it was observed, and 
we haven't defined what "invalid" is.

2. Definitions

s/Listid/List-id/
s/adjacent SMTP./adjacent SMTP server./

3.1

My first problem is with the title of this section:  Is "All Mail Signed 
with DKIM" really a problem scenario?  I think the problem scenario is 
really that an unsigned message was received, and the recipient has to 
figure out what to do about that.

s/insured/ensured/

Paragraph 2, "what their expectations are for unsigned mail." sounds 
like a question about that this domain does with their incoming mail, 
not what their practices are with respect to signing.

Paragraph 3, s/allowed/allows/

Paragraph 5, s/bias filters/bias its filters/

Following paragraph 5 is a numbered list of steps that should be 
preceded by some introductory text.

Step 1, s/purportedly sends/is sent/

Step 4, "looks somewhat more suspicious" sounds like a UI issue, and 
conflicts with the definition of Suspicious that we're likely to be 
using in the SSP draft itself.

3.2

Paragraph 1 first sentence is worded as though a particular class of 
mail is the target; the domain is actually the target.

Paragraph 2 should perhaps mention the usage patterns of such domains, 
that they don't typically send to mailing lists, which are a significant 
contributor to signature breakage.

Paragraph 3 Informative Note:  Isn't this whole document informative? 
(Applies to other informative notes too)

Again, the numbered list of steps could use some introduction.

Step 4, same comment about use of "suspicious".

4.2

SSP's is awkward; I would word things to avoid this ("Sender Signing 
Practices's" is a mouthful!)  Same comment elsewhere.

Paragraph 1, s/SSP's client will generally be deployed/SSP lookups will 
generally be performed/

The 4844.From address isn't a "trust basis" but rather a key (in the 
database sense, not the crypto sense) to the policy.

Where does this section talk about determinism (first word of the title)?

4.4

Paragraph 3, "strong practice" isn't defined anywhere.  You might want 
to say "signing complete" practice or something like that.

4.5

I'm not sure "transport scenarios" fits that well with the content of 
this section.

Paragraph 2, s/sadly a vector for those sending mail for anti-social 
reasons/unfortunately an attack vector for those wishing to spoof email 
addresses/

4.6 through 4.9

Are these really deployment scenarios?  They don't read that way to me.

5.1

Item 4, "The process of obtaining the parent domain's practices MUST 
complete..." is a duplicate of item 2.  The following sentence, "In 
widening the scope..." isn't a requirement at all but a discussion of 
implementations.

5.3

The whole thing about the X-Silly header field makes it sound like there 
is a requirement here that SSP has to be able to publish expectations 
about presence of header fields.  Is that requirement intended?

Item 1, do you mean the entire RFC2822.From address or just the domain part?

Item 2 sounds like a requirement for the protocol but really it's a 
requirement that the specification define this, correct?

Item 6 should also mention the ability of the domain holder to delegate 
individual keys by registering them.  Isn't there something else we can 
reference that describes the way to do this delegation?

Item 6 doesn't reference any scenarios.  I think it refers to Deployment 
Scenario 1.

Item 10, I disagree that this requirement should stand.

5.4

Item 1, s/able to extend/extensible/

6.

Item 1, where is the requirement?

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