ietf-dkim
[Top] [All Lists]

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

2007-03-30 16:20:55
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

<Prev in Thread] Current Thread [Next in Thread>
  • [ietf-dkim] Comments on draft-ietf-dkim-ssp-requirements-03, Jim Fenton <=