ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Seriously.

2008-01-22 13:28:43

On Jan 22, 2008, at 10:40 AM, Siegel, Ellen wrote:


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
...
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 [treat] 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?

The SSP requirements are for From headers since only From headers are assured to be included within the signature's hash. When a valid unrestricted signature is by a domain above or at the From domain, this signature should meet "all" or "strict" compliance based upon From headers. The signature itself might be on-behalf-of the email- address within the Sender header. IMHO, DKIM must not attempt to impose explicit authentication requirements of identities within a domain.

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.

A trusted 3rd party signature can be handled in any manner a verifier deems appropriate, despite definitions for "strict". However, SSP compliance should not impose requirements on the on-behalf-of feature of a DKIM signature.

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.

Agreed, but more than just asserting "all" email is signed is being attempted by SSP at this time. Imposing requirements on a signature's on-behalf-of feature creates more problems that it solves. A signing domain should be able to decide whether they wish to "authenticate" the identities of individuals. The only exception might be for g= restricted keys, where the restricted signature's compliance should be limited to the From domain.

-Doug



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

<Prev in Thread] Current Thread [Next in Thread>