Arvel,
Thank you. Eric Allman and I went over your suggestions while we were
marking up the SSP draft, and they help a lot. Most of them we're just
going to incorporate, so I won't comment on those. Here are our
comments on the rest:
Arvel Hathcock wrote:
Just a few small suggestions:
1) In several places the language "SHOULD be considered
non-Suspicious" is used. This seems an awkward way to say it. Since
the term "Suspicious" is defined in section 2.8 "SHOULD NOT be
considered Suspicious" might be a better way? Also "MUST be
considered non-Suspicious" -> "MUST NOT be considered Suspicious"?
We were a little mixed on this. Agree that non-suspicious is probably
not a word; it should be "not suspicious". But considering something to
be not suspicious is not quite the same thing as not considering
something to be suspicious. Even though SSP only produces one of two
results, it seems clearer to say that the answer is "not suspicious"
than to say that the answer isn't "suspicious". We're doing some
wordsmithing on this, including being more consistent on the use of
SHOULD and MUST.
3) "not to be legitimate" -> "to be illegitimate"
The whole use of the word "legitimate" is being removed; it creates
confusion about legitimate vs. not suspicious and so forth. So this
will be a moot point.
4) ", and any verifiable signature is present from some signer other
than the Originator Address in the message" -> "and the message
contains a Verifier Acceptable Third-Party Signature"
I like your wording, although this part of the text will be removed when
we collapse the text in removing the use of "legitimate".
7) Section 4.1 states that syntactically incorrect SSP records should
be considered as NODATA. This is different from the 4871 approach of
simply ignoring unknown tag/value combinations. This also precludes
the ability to extend an existing SSP record with some future new tag
(should that need ever arise). Was this intended? It seems to
contradict what's stated later in 4.3 that unknown tags are to be
ignored.
What this points out is that there isn't actually a formal definition of
the record syntax. We need some ABNF for this, and will consider the
need for future new tags.
11) Personally, I like the suggestion someone else made of changing
"unknown" to "?" but this isn't particularly important really.
Eric and I like "unknown" because it's less cryptic and there isn't any
reason to save a few characters here. If there's consensus to the
contrary, we'll of course change it.
12) Section 4.4 - "including any where the Alleged Signer is" -> did
you mean "including anywhere the Alleged Signer or"
This sentence will go away.
13) Algorithm 2 - "to the domain part of the Originator Address" - it
seems like you'd want to define "Originator Domain" in the definitions
section and use that in a few places.
Yes; thanks for pointing out the repetition.
14) Algorithm 2 - "with one or more answer which is a
syntactically-valid SSP response" -> "with one or more syntactically
valid SSP responses"
Right. This points out that we need to think about what happens if we
get more than one SSP response. Any opinions?
15) Algorithm 3 has me a little worried. It would prevent the use of
domains unless they explicitly exist in DNS. So, if I wanted to send
a message out from message(_at_)sms(_dot_)altn(_dot_)com I would have to make
sure and
create a DNS A record or something for sms.altn.com first right?
(sorry, my knowledge of DNS is not so good)
You should probably have an MX record anyway for sms.altn.com,
especially if that's also the envelope-from address (so it can receive
bounces). It doesn't need to be an A record; any record type will do.
17) Algorithm 4 - "is a top-level domain" how can that be determined
in practice? I don't think it can can it? If not, we're giving
algorithmic instruction here that is impossible to implement.
A top-level domain is one that has exactly one component, e.g., "com",
"org", "uk", or "tv". We also talk about suffixes, which would probably
include "co.uk", "k12.ca.us", and "edu.au". We mandate not querying the
top-level domains, since they can be algorithmically determined and we
really don't want to unnecessarily load the TLD servers. Not querying
suffixes is optional, as the definition for what a "suffix" is, because
there is no formal definition and this is really an optimization.
18) Algorithm 5 - unless we can figure out how to stop queries at
top-level domains, Algorithm 5 will send lots of queries to the root
servers right (.co.uk for example)?
.co.uk isn't a root server, it's a suffix. The root servers are the
places you query to find the name servers for ".com", ".us", ".hr", and
so forth. It may send quite a number of queries to the .co.uk name
servers, which is why you may want to have it in your suffix list, but
even if it's not, the number of queries should be limited by the minimum
TTL of the zone it's in (the negative caching time).
Again, thanks for your comments!
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html