Hi Tony,
My technical and "product attraction" opinion is:
The original scope (SSP) was on track with addressing with what I
believe were the most marketable features of the product:
- High benefits for exclusive domain policies
- High benefits in exposing the nature of domain usage
As a product producer, this is how I am going to be able to "help" the
"world of domains" outside my own control. It is what I see my customers
will desire, and at the same time, as a USER of the product, I would
like to also protect my own domains being exploited and used at other
compatible DKIM/SSP systems out there. I would rather that they honor
our DKIM/SSP own policies.
We are simply not going to protect the entire spectrum of DKIM with no
or flexible SSP policies. But we can MOST definitely address domains
(HIGH VALUE or not, but HIGH VALUE will probably be most interested)
with "tigher" policies who simply do not expect MIDDLE WARE and/or LIST
SERVERS to be "touching" or passing thru such mediums.
In effect, we want to provide "increased assurances" to the domains
wanting to increase security value with direct communications with their
end-users and target recipients.
In short, speaking as one vendor, we will not expose our customers with
a "out of the box" DKIM solution until we have a SSP or similar concept
wrapper concept. I see absolutely no value in a DKIM-BASE only system
and in fact, could hurt more than it helps and the longer DKIM-BASE is
used and ignored, the more it becomes obsolete.
So if all possible, I "vote" for concurrent (or near) release of both
specs, whatever that means in terms of IETF. I think Jim Fenton's
updated SSP-03 is good enough to start and it covers the "features" that
I outlined in my own (now expired) draft DSAP which was strategically
written to simply highlight the concerns. With that, I support SSP-03
rather than continue with DSAP.
--
HLS
Tony Hansen wrote:
Internet-Drafts(_at_)ietf(_dot_)org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : DomainKeys Identified Mail (DKIM) Message
Signing Service Overview
As you read through this, you will find that the stuff in it dealing
with SSP is only part way there. This is hardly unsuprising since SSP
itself is only part where there.
An outstanding issue from the last IETF was (quoting the minutes):
Tony Hansen reviewed the status of the DKIM Overview document,
and we got another "hum" from the room about preference to put
the document out soon, to aid implementations of the DKIM base,
with a possible second version later, covering subsequent
topics... or to publish the overview document only after the
working group completes (or largely completes) the rest of its
work. The consensus was again not overwhelming, and was
marginally in favour of publishing a first version now.
Given the lukewarm consensus before about publishing this document now
versus later, we didn't push hard one way or the other for the latest
update.
However, I'd like to hear some discussion on the issue: Should we put
out a version now (without the SSP references), or hold off until SSP is
totally finished?
Tony Hansen
tony(_at_)att(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html