ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Tracing SSP's paradigm change

2007-12-13 01:43:24
Mark Delany wrote:
On Dec 12, 2007, at 10:36 PM, Jim Fenton wrote:

Mark Delany wrote:
On Dec 12, 2007, at 6:01 PM, J D Falk wrote:

Jon Callas wrote:

I offer as a suggestion that we issue an SSP document that describes
only the basic broken-signature-only model of SSP with only the one
policy (sign-all). After that, we look at enhancements to the model
carefully. We seriously discuss whether they are outside the charter
because of the effect it has on the global email infrastructure to
turn DKIM from an opt-in protocol to a you-must protocol. We also
seriously have to look at other policies to discuss their
effectiveness along with their environmental effects.

+1

This will let us experiment and learn through real-world operational
experience, rather than continually rehashing the same arguments.

Plus One. I'm inclined to this approach if we can't reconcile the
differences that appear to have stalled SSP progress.

Is there a common subset of SSP that most everyone agrees on?

I thought we had documented it in RFC 5016.

From an IETF procedural perspective that may well be so - my question
is more about whether the sentiment of the WG matches 5016?

That's a good question.  5016 went to Working Group Last Call in March;
the only substantive issue is whether it should include information on
application of multiple signatures by a domain.  But I suppose that
since the draft was Informational everyone was excused from commenting
at that time.

It's purely a strawman, but I sense that sub-setting a core might help
us move forward. I am likely wrong, but it's a question I'd like to ask.

My sense from reading the list traffic is that there are a lot of
differing opinions on what the subset might contain, with results
ranging from making SSP vaguely useful to actively hostile to DKIM
deployment.

-Jim
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html