Philip,
Off the top of my head, this looks like it will work. This will provide
also for an optimal single lookup for the low to mid tier market where 1st
party delegation is all that is required.
However, the question remains if what is the policy _association_ with the
legacy x822 headers, in particular when and where there is no signature?
If the verifiers sees just this:
From: alice(_at_)example(_dot_)com
To: someuser(_at_)sometarget(_dot_)com
Date: ....
Subject: .....
or even include the sender:
Sender: MailRoom(_at_)remailer(_dot_)com
From: alice(_at_)example(_dot_)com
To: someuser(_at_)sometarget(_dot_)com
Date: ....
Subject: .....
Are we going to ignore addressing the highly detectable and thus highly
possible protection in legacy facsimiles of the unsigned message?
Remember, if this remains to be an ignored condition, then bad actors simply
will just avoid mail with signatures good or bad, 1st or 3rd party, what
have you. All they need to do is simply just broadcast old standard
unsigned mail as they do now. In this case, we lost a major opportunity to
protect the 1st party domain, the abuse on the receiver system, and also
lost the opportunity to force bad actors to adapt in our direction.
If we conclude there is a value here to extract policy from default legacy
headers, I believe we are in the right direction with your proposal.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Lets have some parties:
Party claiming responsibility for content: alice(_at_)example(_dot_)com
Party that has the signature key: remailer.com
...
remailerkey._domainkey.example.com TXT
"sender=alice(_at_)example(_dot_)com"
"delegate=**.remailer.com"
examplecomkey._domainkey.remailer.com TXT
"authority=remailerkey._domainkey.example.com"
"key=423249671234986u3hf89713ty49y=="
...
We have successfully achieved both types of delegation
semantics without recourse to any additional DNS feature and
without doing damage to the DNS semantics. We are much less
likely to face unexpected interactions.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html