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