My comments inline below. They can be summarized as follows:
1. SSP does not dictate receiver behavior. SSP bends over backwards to
state receiver behavior is at receivers' discretion. If someone can find
someplace where SSP dictates receiver behavior please identify it so it
can be fixed.
2. Some IETF particiants believe certain SSP statements such as "strict"
and "deny" are not useful SSP constructs for them. Some are explicit
that these constructs would not be used by their own mail servers.
However there is a large part of the Internet community that desires
these constructs. The brilliance of "strict" and "deny as defined in SSP
is that a strict/deny proponent like myself can build a system using the
strict/deny data provided by other strict/deny proponents' SSP records
AND strict/deny opponents can simply publish "unknown", "all" and
"process" policies and then use their discretion to ignore results
related to strict/deny. Everybody wins! I believe it would be an epic
mistake for the strict/deny opponents to prevent others from utilizing
these capabilities. I have no desire to prevent someone from ignoring
strict/deny at their discretion; why can't I have a syntax I desire to
state strict/deny for those who will use it?
pat
PS: SSP does not dicatate receiver behavior :)
> In general, the draft needs to consider adoption incentives
> for receivers. My
> guess is that such an analysis will show that there is a
> relatively small set
> of publishers and receivers who are highly motivated to
> implement the more
> advanced features -- advanced relative to earlier SSP drafts
> -- but that true,
> Internet-scale adoption will be elusive for quite some time.
I strongly disagree. There are a significant number of large receivers
that are highly motivated to adopt the draft. Take one example: Y! has
been public about their work with PayPal to ensure non-delivery of
unsigned or invalidly signed DK messages. (I know this is DK but the
incentive of SSP is the same for DK or DKIM.) I have been very public
about IronPort's desire to implement SSP based on the proxied desires of
our customers. The 100 US Financial Services Roundtable companies (BITS)
have also been public about their desires in this area.
> In my opinion, the draft should be broken into an initial
> core, with optional
> extensions. The core should define the publication mechanism
> and the smallest
> set of features that are deemed useful and likely to receive
> a broad base of
> initial adoption. The extensions would target the smaller
> set of adopters who
> are viewed as being strongly motivated for these enhancement.
> The core would
> be appropriate for direct standardization, while the options would be
> experimental.
Again disagree. I feel the extensions are critical.
> 1. Signer/Validator practices "negotiation" scope
>
> SSP's description of itself as including "how verifiers
> should... interpret
> those results" states a scope of protocol semantics that is
> new to the IETF;
> the protocol is not constrained to "interpret" with respect
> to defining what
> the published information means, but rather is meant to guide, or even
> mandate, how the mail receive-side participant should handle messages.
This is not true. draft-ietf-dkim-ssp-01 states:
"deny Messages which are Suspicious from this domain MAY be
rejected, bounced, or otherwise not delivered at the option of
the verifier."
There is no mandate here.
> I believe the IETF has not previously standardized a
> specification which
> attempts to have one network participant dictate the internal
> operating
> behaviors of another, outside of the protocol interaction
> itself. As such,
> efforts in this direction need to be careful, modest and incremental.
Again, there is obviously no dictation here. The ability for a sender to
state a policy in such a manner that certain receivers find it most
beneficial but in a way that does not constrain other receivers is a
benefit, not a limitation.
> 2. Unsigned vs. Mismatched Signature
>
> The original SSP specification applied only to unsigned
> messages. The current
> version includes mail that is signed but has different
> domains between the
> DKIM i= attribute and the rfc2822.From field. Presumably,
> this new capability
> overrides whatever reputation is associated with the message signer.
>
> If a signer has a good reputation, then why is that not sufficient for
> enabling delivery? In other words, with a signature of a
> domain with a good
> reputation, what threats is SSP trying to protect against?
Reputation systems are designed by organizations to optimize delivering
good mail and stopping bad mail. They will design the reputation system
however they see fit to achieve this goal. The market dynamics and
innovation will define reputation systems' design, not SSP. Hypothetical
statements about how reputation systems may develop aren't relevant to
SSP>
> 6. Signature Semantics
>
> DKIM was devised to provide a means of declaring an
> (organization's) identity
> that is taking "responsibility" for placing a message into
> the transit stream.
> This is a very constrained semantic for the signature, and
> really pertains to
> no more than a delivery decision.
>
> In reviewing the apparent semantics of full SSP use, I
> believe it seeks to
> move a DKIM signature, which uses the same domain name as is
> in the From
> field, into the realm of declaring content to be valid. This
> is a much more
> demanding semantic and, I believe, moves the DKIM/SSP service
> into direct
> competition with S/MIME and PGP. At best, this seems
> entirely ill-advised.
> At the least, it is considerably more ambitious than the
> initial functions
> discussed for SSP. For an initial version of a standard,
> more ambitious means
> more risky.
I have no idea what "declaring content to be valid" means.
For example, I can sign a DKIM message with SSP and this DKIM message
with matching i= and From domains can state "2+2=5". Certainly I'm not
validating the content here?
I think you mean something else.
References to S/MIME and PGP are unclear and irrelevant. I was unable to
follow this thread on the list a few weeks ago.
Let's determine what the requirements are and build a system to meet
those requirements rather than state "this design moves into the realm
of blah where blah is undefined."
> DETAILED COMMENTS
> =================
> > In the absence of a valid DKIM signature on behalf of the "From"
> > address [RFC2822], message verifiers implementing this
> specification
> > MUST determine whether messages from that sender are
> expected to be
> > signed, and what signatures are acceptable. In
> particular, whether a
>
> Normative text in the Introduction?
>
> I initially thought that the statement, here, provided a
> crisp statement
> of scope, but then realized that the "signature on behalf of
> the From address"
> left things unclear.
>
> For one thing, it means that SSP will apply to some signed
> messages, and not
> only to unsigned messages.
>
> For another, it appears that the test to perform is with the DKIM i=
> parameter. This can get a bit tricky. For example, since
> the DKIM base
> specification does not require that the i= parameter directly
> relate to the
> From field, this seems to carry an implied modification to
> DKIM base? So it
> seems to require that i= be entirely redundant with (one of?)
> the rfc2822.from
> address(es) in every detail?
>
> As for "what signatures are acceptable", the implied,
> open-ended complexity in
> this statement is huge. Think, for a moment, of just how varied the
> description of 'acceptable' signatures could become.
>
> Given that DKIM pertains to domains that are trusted, rather
> than to domains
> that are untrusted, this line of SSP effort appears to be
> conflating the two
> worlds.
DKIM applies to both. I can determine bankofamerica.com is trusted and
bankofamerica.cl is untrusted. I can use DKIM to authenticate the use of
each of these domains and then apply my trusted and untrusted logic
accordingly.
> > techniques such as DKIM is limited since unsigned messages will
> > always need to be considered to be potentially legitimate. This
>
> A declaration of the limited utility of DKIM, without SSP, is
> gratuitous,
> probably wrong, and probably counter-productive for early
> DKIM adoption.
I disagree. For domains which are forged regularly DKIM without SSP is
limited IMHO.
> > 2.9. Suspicious
> >
> > Messages that do not contain a valid Originator
> Signature and which
> > are inconsistent with a Sender Signing Practices check (e.g., are
> > received without a Valid Signature and the sender's
> signing practices
> > indicate all messages from the domain are signed) are
> referred to as
> > "Suspicious". The handling of such messages is at the
> discretion of
> > the Verifier or final recipient. "Suspicious" applies
> only to the
> > DKIM evaluation of the message; a Verifier may decide the message
> > should be accepted on the basis of other information
> beyond the scope
> > of this document. Conversely, messages not deemed
> Suspicious may be
>
> This is the strongest indication that the SSP specification
> has moved from
> describing sender-side practices to, instead, attempting to
> tell receive-side
> validators how to behave.
Receiver-side validators are explicitly *not* being told how to behave.
Their behavior is at their discretion. Some receivers may use this SSP
information and it shouldn't be denied to them based on a clearly
misreading of "discretion" for "dictating". I think many will use this
information beneficially.
> A term like "suspicious" is emotionally charged. Given that
> breakage can (and
> will) sometimes account for the condition being described,
> here, it would be
> better to use a term that is descriptive of the situation,
> rather than having
> it assert a qualitative assessment.
"suspicious" may be emotionally charged but "Suspicious" should not be.
capitalized "Suspicious" means something very specific in the SSP
document
> > rejected for other reasons.
>
> So, the term 'suspicious' will be applied to some acceptable
> messages and not
> applied to some bogus messages?
First the term "suspicious" is irrelevant. The term "Suspicious" is at
play.
Some acceptable messages will be "Suspicious" because they will be
unsigned or have a broken signature. That's ok because the receiver can
term them "Suspicious" and then, at their discretion, deem them
acceptable and deliver them.
Some bogus messages will have valid DKIM signatures and matching SSP
policies. Such a message from an *untrustworthy* domain like
bankofamerica.cl is not "Suspicious" but is bogus.
> > handling= Non-compliant message handling request for the domain
> > (plain-text; OPTIONAL). Possible values are as follows:
>
> For some reason, the above language seems awkward to me. I
> assume the meaning
> is "Author domain request for handling of non-compliant messages"?
>
> In any event, this again makes clear that SSP has moved from
> describing
> 'sender' practices into an attempt by a sender to dictate
> validator behaviors
> when using sender practices information.
Again, nothing is being dicated. The receiver has their full discretion.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
