[ietf-dkim] Comments on draft-ietf-dkim-ssp-requirements-03
mike at mtcc.com
Fri Apr 6 12:04:13 PDT 2007
No comment means I'll roll it in somehow...
Jim Fenton wrote:
> 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/adjacent SMTP./adjacent SMTP server./
> 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.
> 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.
How about "what their expectations are for unsigned mail purportedly
originating from their domain". It's not strictly a practice per se,
it's what their expectations are wrt the ultimate survivability which
is not something that they control (= practice).
> 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
First it doesn't have to have anything to do with a UI, and second
I'd say that you have it cart before horse here about suspicious:
if there's a problem, you need to tell me what it is, not that it
conflicts with the ssp draft.
> Paragraph 1 first sentence is worded as though a particular class of
> mail is the target; the domain is actually the target.
I'd say that's debatable. It is transactional mail that is the prime
problem, not the day-to-day conversational mail. Whether those two
coincide is largely a question of how you lay out your namespace.
> 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)
No, the document still lays out normative behavior for the protocol.
PS, etc are for actual protocols. Also: plenty of informational rfc's
have normative language.
> Again, the numbered list of steps could use some introduction.
> Step 4, same comment about use of "suspicious".
> 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.
I'm not groking this.
> Where does this section talk about determinism (first word of the title)?
> Paragraph 3, "strong practice" isn't defined anywhere. You might want
> to say "signing complete" practice or something like that.
> 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
> 4.6 through 4.9
> Are these really deployment scenarios? They don't read that way to me.
If you can think of another bucket to put them under... I mainly didn't
want to get too elaborate on the taxonomy.
> 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
This is going to get rewritten in 2, so it probably won't be a dup after
> 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?
Yeah, I'll reword this.
> Item 1, do you mean the entire RFC2822.From address or just the domain
> 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.
> Item 1, s/able to extend/extensible/
> Item 1, where is the requirement?
Good question :)
> NOTE WELL: This list operates according to
More information about the ietf-dkim