On Wed, Apr 20, 2011 at 8:29 PM, Murray S. Kucherawy
<msk(_at_)cloudmark(_dot_)com> wrote:
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of J.D. Falk
Sent: Wednesday, April 20, 2011 1:25 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] ADSP stats
On Apr 20, 2011, at 4:36, <Bill(_dot_)Oxley(_at_)cox(_dot_)com> wrote:
Indeed lack of support for 3rd party signers was where I gave up any
interest at all in adsp
As I remember it, there was (or appeared to be) consensus to get ADSP
out there for testing by the entities it might work for, AND
simultaneously work on something for the 3rd party scenarios.
What ever happened to that work? I know there were a couple of drafts,
and Murray added support for one to OpenDKIM...if the 3rd party stuff
is really that important, why isn't anyone using it?
Indeed, I asked this question at a couple of industry trade groups I attend,
MAAWG being one of them. The answer I generally get is that the key
delegation already supported by DKIM works just fine, so why do we need some
other mechanism that hits the DNS yet again and employs some complex policy
expression language?
Sorry I'm late to the party. Perhaps it it just me, but I think when
talking third-party, folks could be talking about two different
things.
1) Key delegation, as Murray mentions. I believe this means when the
party that authors the message uses a third party to send the message.
The first party delegates the signing domain to the third party*. I
agree that there doesn't need to be another mechanism to do such
things.
2) The RFC5322FromDomain doesn't match DKIM's d= parameter. This means
that a RFC5322From of example.com and a d= of
transactional.example.com is considered third party.
There has been no uptake at all in OpenDKIM for ATPS, and almost none is
apparent with ADSP
I can see ATPS gaining momentum in two ways:
a) ADSP adopts it to allow third party signing (using the definition
from #2 above)
b) an author wants to assert a relationship with a DKIM signer.
I see b being useless for receivers. I believe the RFC5322FromDomain
should never match the d= parameter.
* many ESPs do not do DNS delegation, but instead simply generate key
pairs for their clients and have clients put the public key in DNS.
--
Jeff Macdonald
Ayer, MA
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html