On Wed, 2006-07-26 at 08:55 -0400, DKIM Chair wrote:
We have Internet-Drafts from Phill and Doug, as well as the now-expired
-allman-ssp draft, which Jim is working on an edit to resubmit, so it
soon will no longer be expired. Note that the new draft will still be
-allman-ssp for now, not -dkim-ssp. So how will we proceed?
Dave suggested in Montréal, to the agreement of at least some
(including the chairs), that we have to step back and sort out SSP
*requirements* before we can do an SSP specification. Mike has
volunteered to put together a first pass at that, which he is working
on feverishly as I type this (OK, I'm typing this at 5:40 in the
morning his time, so that's probably an exaggeration, but you get the
point).
A major objection received from the approach regarding listing
"designated signing domains" using a PTR RR was due to incorporating the
list syntax of "*.", and "." and the concern that although this would be
restricted to a specific underscore label, bad implementations might
consider this syntax to be valid host names. A similar problem occurred
with the "." used with SRV records.
One solution for this problem would be to combine two different RR
record types or to create a specific RR that combines both a name list
and rather simple set of policy assertions reflected by that syntax. A
name list overcomes several difficult administrative issues related to
using the signing services of a large organization allowing users the
freedom to include their desired email-address within the "originating"
header.
The current SSP syntax is overly complex. The possible weighting of the
dubious states also appear easily structured to punish domains without
conforming policy assertions. This outcome should be avoided. The
approach should be extremely sensitive to administration overhead and
support efforts. In addition, policy searches or user level policy may
represent an inordinate amount of traffic, especially when applied
against more than one identity per message.
As DKIM depends upon some type of annotation to convey verification
results, the dispensation of identities without direct policy can be
dealt with by way of specific annotation. This might represent a
special folder reserved for messages with matching OA and signing
domains for example. This treatment could include designated signing
domains as well.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html