> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MH Michael 
> Hammer (5304)
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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

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

Reply via email to