[ietf-dkim] Change the SSP o= to use words, break out 3rd party?

william(at)elan.net william at elan.net
Tue Nov 8 11:27:52 PST 2005


On Tue, 8 Nov 2005, Jim Fenton wrote:

> william(at)elan.net wrote:
>
>> 
>> Its quite clear from above that one policy would be better represented
>> as separate components:
>>  1. Signature required/optional:
>>    sig=MUST/SHOULD/NEVER/USER (sig=STRONG/NEUTRAL/NEVER)
>>  2. 3rd parties allowed/not
>>    3ps=ALLOW/DENY/USER
>> 
>> (Or if you like o=STRONG/3PS | o=NEUTRAL/NO3PS | o=USER/USER)
>
> I like the separation of third-party policy (for lack of a better word) from 
> the rest.  But I disagree with the "signature required/optional" aspect. 
> All the represented domain can say is whether they sign everything they 
> originate, which is a declarative and not an imperative statement.

There is really only two statements of value:
  1. signature is present for all emails originating from that source.
  2. signature is present in none of the emails
     (no emails originate from source)

How strong above statement should be viewed as should be controlled by 
separate "axis" (which is the one you use for testing right now).

> I'm really not sure what SHOULD means.

- Signature "should" be present (maybe "may" be present) -
Same as your current neutral. I actually don't care about names, so this 
just gives you an overview.

> Somewhat at odds with this is the t= flag, signifying testing.  We should 
> recognize it for what it is, a request to the verifier/recipient to "be 
> gentle" in the event of a failure.  It's worth discussing whether it is 
> appropriate for such requests to be part of SSP, or conversely whether there 
> should be finer granularity in such requests, e.g., "suggest you delete 
> non-conforming messages" or "suggest that you tag the subject line of such 
> messages".
>
> While we're on the subject of SSP, Doug Otis remarked to me yesterday that 
> he feels that the existence of r= (reporting address) in SSP only invites 
> abuse; it's reasonable to solicit [abuse] reports on signed messages but not 
> on unsigned ones.  I think this deserves consideration.

He's correct that it would open for DoS attack where the origin 
could direct multiple others to do it.

>> I think there are legitimate cases when one may want to specify 3PS
>> as DENY for entire domain and not allow user policy to change. Opposite 
>> cases can also exist, when one knows that all email from domain would be 
>> signed but if 3ps signature is allowed or not is dependent on particular 
>> user.
>
> As the -ssp-01 is written, domain policy is consulted first and user policy 
> is consulted only if the policy is USER.  DNS lookups would go way up if we 
> ever consulted user policy without a domain telling us to do so.

That is not what my post said. What it said is in some cases its usefull
to allow user policies to specify only certain part of the global domain 
policy (only 3ps required/not for example) but not allow it to override
other parts of it. Obviously the global policy would be consulted first
in all the cases. In other words I view redirection to user policy as
an attribute of any "axis" and not neccessarily as global attribute.

-- 
William Leibzon
Elan Networks
william at elan.net


More information about the ietf-dkim mailing list