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: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: ....
Subject: .....
or even include the sender:
Sender: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
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" <[EMAIL PROTECTED]>
To: <[email protected]>
> Lets have some parties:
>
> Party claiming responsibility for content: [EMAIL PROTECTED]
> Party that has the signature key: remailer.com
>
> ...
>
> remailerkey._domainkey.example.com TXT
> "[EMAIL PROTECTED]"
> "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
