On Tuesday 01 August 2006 10:56, Michael Thomas wrote: > 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. > Scenario 3a:
1) A is a popular phishing target and prefers to suffer message rejections for messages that don't carry a valid signature by A (or a designated third party) than to have messages that are unsigned or signed by other parties delivered. 2) C sends message on A's behalf using C's identity. 3) B would like to know if C's signature has any relationship to A. 4) If C's signature does not have a relationship to A, then A prefers that the message not be accepted for delivery (note that I say prefers because I understand we can't mandate receiver policy). This is only a variant of #3 and not an entirely new scenario. It's intended to highlight was Stephen referred to as an expected signature missing. Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
