On Nov 30, 2006, at 9:11 AM, Michael Thomas wrote:
Dave Crocker wrote:
Michael Thomas wrote:
Hi,
One of the things I noticed from recent discussions is that we
need to
have clarity in SSP on what, exactly, qualifies as a valid
signature for
"I sign everything".
Michael,
To carry your point farther than I suspect you intend:
From the virtually all of the SSP discussions, including recent
exchanges, I keep thinking that we are starting with mechanism and
only secondarily worrying about utility. Hence the grou confusion
that is persistent.
Some folks think of SSP as being for unsigned mail. Some folks
think of SSP to facilitate end-user interpretation. Some folks
think... And so on.
What we do not seem to have is anything that looks like a clear
consensus about what problem is being solved and why it will be
useful to solve it.
Until the group settles on specific benefits to be obtained, for
which there is a solid basis to think recipient operators will
find them useful, we are chasing our collective tail.
I suggest that discussion about technology -- that is, mechanisms
-- should be deferred until the receive-side benefits (and, for
that matter, the receive-side consuming component) are established.
Dave --
I view this exercise as a largely unproductive rathole.
+1
I think there's been a consensus
for quite a while that the information provided would be
interesting to a pretty widely
varying set of people. Like dkim-base, I don't think we need to
enumerate with any
precision what those benefits are as will undoubtably fall into the
false dilemma of
trying to rank them, categorize them, etc. I can't see how that is
helpful because it's
very clear that that way consensus does not lie. Nor need it, IMO.
-1.
I don't believe that that's been demonstrated yet, at least not
with plausible real-world use cases. Certainly none are
documented in anything other than the vaguest, least useful,
most abstract way anywhere that I've seen.
Enumerate? No. But demonstrating the existence of enough
use cases (>0) to show that some people sending email actually
have a need for SSP, and that enough diverse groups (>1) have
a need for it to justify a public standard created by someone other
than those users would go a long way towards justifying SSPs
benefits as outweighing its costs and risks.
On the sender/signer side there is a fairly simple benefit: SSP is
an information
service which domains publish to give receivers more accurate
details for their
delivery decisions. Nothing more. I think that's pretty much all of
the justification
we need.
Much more interesting in my mind is whether there's potential
*harm* that
might come from SSP, and if so whether the draft can do anything to
avoid that
harm, how likely the harm would be, etc.
Well, SSP will cause legitimate email to be rejected, so there is
non-zero potential harm. It's likely that in at least some cases the
benefit will outweigh that harm, but we'd really need to look at
some of the actual use cases that a sender may use SSP for
to say for sure.
(Depending on how SSP is used it's possible that it may cause much
more drastic harm, but I don't want to go into that possibility again,
given the abuse it provoked last time.)
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html