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>
|
- Re: [ietf-dkim] Seriously., (continued)
- Re: [ietf-dkim] Seriously., ned+dkim
- New Issue: signed vs. unsigned header fields as input to SSP (was: Re: [ietf-dkim] Seriously.), Stephen Farrell
- [ietf-dkim] Re: New Issue: signed vs. unsigned header fields as input to SSP, Michael Thomas
- Re: [ietf-dkim] Seriously., Michael Thomas
- RE: [ietf-dkim] Seriously., Hallam-Baker, Phillip
- RE: [ietf-dkim] Seriously., MH Michael Hammer (5304)
- RE: [ietf-dkim] Seriously., Siegel, Ellen
- Re: [ietf-dkim] Seriously.,
Douglas Otis <=
- Message not available
- RE: [ietf-dkim] Seriously., SM
- Re: [ietf-dkim] Seriously., John Levine
- RE: [ietf-dkim] Seriously., robert
- RE: [ietf-dkim] Seriously., Hallam-Baker, Phillip
- RE: [ietf-dkim] Seriously., MH Michael Hammer (5304)
- Re: [ietf-dkim] Seriously., Jim Fenton
- Re: [ietf-dkim] Seriously., Dave Crocker
- Re: [ietf-dkim] Seriously., Damon
- RE: [ietf-dkim] Seriously., Siegel, Ellen
- RE: [ietf-dkim] Seriously., MH Michael Hammer (5304)
|
|
|