[ietf-dkim] Resigner Support of RFC 5617 (ADSP)
gmail.sant9442 at winserver.com
Sun Oct 11 15:48:50 PDT 2009
First, I was probably and still am, the biggest promoter for 3rd party
considerations, even wrote the DSAP proposal. So I was not too happy
with ADSP with its exclusion of 3rd party considerations.
Second, I think the Hector/Levine interpretations are the same as it
was always expected. Unlike SSP, ADSP was 100% never about 3rd party
But its never going to be a surprise to me that others, such as
yourself, will desire 3rd party considerations. That was the problem
with ADSP - its ignorance of this very high potential and worst, its
lack of support by its author which doesn't help the process.
So what happen?
DKIM become a hop to hop resigning concept. ADSP POLICY in inherently
conflictive with this.
A mailing list is just one form of a resigner. You don't have to a
mailing list server to be a DKIM resigning clearing house.
So again, as strong supporter of policy, how do authorize the resigner.
With all the work done over the last few years, I think simplest
solution to add two new policies:
DKIM=NEVER is designed for the migration market who wish to add DKIM
signing support to their domains but during the migration or
development period, they want a policy that says this DOMAIN never
signs its mail.
DKIM=ALWAYS says my mail is always signed by someone.
I always felt the benefits are not in proving the positive assertion
by proving the negative assertion or deviation from the assertion.
In other words, a VALID 1st or 3rd party signature proves nothing.
Reputation or Domain Certification helper technology of some sort is
But for failures, there is a strong assertion that it is not what the
o Current Policies:
When no 1st party signture is found - REJECT
When no 1st party signature is found - No Semantics.
o Extended Policies:
When no signature is found - REJECT
When a signature is found - REJECT, not expected must be spoof.
Hope this clarifies my position.
Michael Deutschmann wrote:
> On Sun, 11 Oct 2009, Michael Thomas wrote:
>> On 10/11/2009 02:41 AM, Michael Deutschmann wrote:
>>> If this is indeed the official semantics of the protocol, then I would
>>> petition to add a "dkim=except-mlist" policy. Which means "I sign
>>> everything that leaves my bailiwick, but may post to signature-breaking
>> No need. That is exactly what the semantics of "all" is.
> That appears to be a contentious issue.
> While I don't think the Hector/Levine interpretation is very useful, I
> think it would be a sound strategic move to yield to them regarding
> dkim=all, and instead create our own dkim=except-mlist space where our
> semantics are in place with *no ambiguity*.
> ---- Michael Deutschmann <michael at talamasca.ocis.net>
> NOTE WELL: This list operates according to
More information about the ietf-dkim