[ietf-dkim] Seriously.

[Siegel, Ellen]

> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of MH Michael Hammer (5304)
>> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Hallam-Baker, Phillip
>> There are two questions that you can answer with a DKIM like
>> specification: 
> I would phrase the questions slightly differently
>>1) Is there an authentic claim of responsibility from a trustworthy party?
> Can I authenticate a claim of responsibility from a party (that party may 
> or may not be trustworthy but I can authenticate they are making the
> claim)?
 
>>2) Is there an authentic claim of origin from an identified party?
> Is the identified party the originator of the message and can I
> authenticate them as such?
 >> A claim of responsibility is not the same as a claim of origin. If all
 >> you want to do is to whitelist email for spam control 
 >> purposes you simply do not care if the signer of the email is the 
 >> originating party in any sense (author, employer, etc.). The multiple
 >> from issues is irrelevant. 
> Agreed
 
>> If you do care about authenticated origin the RFC 822 headers are 
>> frankly irrelevant. The only claim(s) of origin you care
>> about are those that are authenticated. If you have multiple From and 
>> only one is 
>> authenticated then you are only going to tread that one as authenticated
>> for purposes where you require authentication. If all the From addresses
>> are authenticated then you are fine. 
> Agreed except that the Sender field should not be used unless it is in the
> same domain as (authenticated) From. 

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.

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. 

Ellen