ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] Seriously.

2008-01-22 11:46:24

From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of MH Michael 
Hammer (5304)
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)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

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