Re: [ietf-dkim] Seriously.

Siegel, Ellen wrote:
> If you have an authentic claim of responsibility from a trustworthy party (as 
> per #1), why should it matter whether that party is represented by the From: 
> header or the Sender: header? And why, if the authenticated party in the 
> Sender: field is trustworthy, should it be required that the From: domain is 
> authenticated directly?
>   
> This all seems counter to the idea that reputation is the real differentiator. You seem to be saying that a trustworthy, authenticated signature related to the Sender field is worthless, but any authenticated signature related to the From: field is goodness. Taking that to its logical conclusion, spam signed with a signature based on the bogus From: domain will be rated better than valid mail signed with a well-know, trusted 3rd party signature based on the Sender field.
>   
The SSP result is by no means the final judgment on a message; 
regardless of the SSP result, a recipient is free to ignore that and 
accept the message anyway.  But when you say things like "well-known" 
and "trusted" you're implying some sort of accreditation or reputation, 
even if that reputation is locally held (i.e., a white list).
SSP is about providing advice in the absence of sufficient trust to just 
accept/deliver the message.  How much is "sufficient" is up to the 
receiver, and may depend on the claimed author.
> Using SSP as a backup if your first-level reputation check yields uncertain results is one thing, but claiming that receivers should automatically be invoking it any time that a signature fails to match the originator domain (independently of the trust status of the existing signature) seems like it's potentially creating more problems than it's solving. 
>   
This is a fair point.  We need some words that don't create a normative 
dependency on reputation and accreditation systems that are out of 
scope.  Suggestions welcomed.
-Jim

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html