Dave Crocker wrote:
Tony Hansen wrote:
Dave Crocker wrote:
Alas, it was pointed out to me that SSP does indeed have a requirement for a
lookup even when the message is signed. This is when there is so-called
third-party signing. (I believe this means when the domain in the rfc2822.From
does not make the DKIM d= domain.)
I would at a minimum include rfc2822.Sender in this check: third part
signing is when the DKIM d= domain is not equal to either the
rfc2822.From's domain nor the rfc2822.Sender's domain.
Tony, et al,
Switching back to the 'requirements' suggestion I have been making:
I would like to see a scenario described that explains exactly what problem
needs to be detected and why it is a compelling, immediate requirement.
I would like to see the description done in a way tht talks about particular
individuals and organizations, without referring to particular protocol units.
In other words, I'd like to see the non-technical description of the requirement
and its rationale, before it gets translated into the technical details, such as
citing particular header fields.
Right, this would be enormously helpful I think.
Scenario 1:
1) A sends to B with a missing or broken DKIM signature
2) B would like to know whether that is an acceptable state of affairs.
Scenario 2:
1) C sends a message on A's behalf by having been delegated a selector by A
This is a normal -dkim-base usage scenario, but there are some deployment
related issues related to how the delegation is done. What are the
requirements
from that?
Scenario 3:
1) C sends message on A's behalf using C's identity
2) B would like to know if C's signature has any relationship to A
This is the "ISP" scenario discussed on the list often. It has scaling
issues
naively because the number of acceptable third party signers for A may be
large, and perhaps troublingly not uniform in the trust of the third
parties.
Etc. If people can come up with other use scenarios, please feel free.
Please
do not follow them on with long tomes on how to solve it, or why it makes
a particular protocol well suited, etc... this is about requirements.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html