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