On Jan 16, 2008, at 1:49 PM, Arvel Hathcock wrote:
The debate here is whether or not it's mission-critical for SSP to
use From: in all cases or whether some other sender identity (like
Sender: header) could be used to equal effect generally or in
specific cases (like when there are multiple addresses in From).
There should _not_ be a restriction on who the signature is on-behalf-
of, be it "Sender", "second author" or "opaque identity". A signature
of the "first author's" domain should be the only requirement for
compliance with "strict" and "all". This is not how SSP is currently
defined.
The only exception might be for g= restricted keys, where the
signature must be on-behalf-of the "first author" to offer "strict" or
"all" compliance. This is not how SSP is currently defined either.
Given that it would solve the problem described in 1525 and also
bring us closer to a consensus position perhaps this thread should
discuss what is lost through utilization of the Sender header in at
least some cases.
Nothing is lost when just the _domain_ of the signature is
significant. DKIM/SSP is not about identifying individuals. DKIM/SSP
is about deciding whether a message contains a compliant signature.
The DKIM signature can indicate which identity it is on-behalf-of. In
this regard "first author" is not sacrosanct as it could be for _any_
identity.
Dave Crocker wrote:
Whereas SSP began as a simple idea as a means of deciding whether
an unsigned message should have been signed, it has morphed into an
effort to validate the From field. That is a very, very different
goal. While DKIM has the goal of assigning *any* identity to a
message, so that that identity can be assessed, the current work on
SSP is attempting to instead validate authorship.
I am in complete agreement with this statement.
For the purposes of ensuring the presence of any valid identity,
using the Sender: field is just as acceptable as From:. It also
has the appeal of being far simpler and, by the way, supporting a
wider range of legitimate usage scenarios. Rather than deal with
the problems caused by rigidly insisting on using the author
string, you seem intent on ignoring the feedback about those
problems and the remarkably simple and useful suggestion to switch
to the Sender: field. But, then, this focus on using author
information goes back to a belief that SSP can somehow be useful
directly to end-users, in spite of there being no empirical basis
for believing this and plenty of empirical basis for knowing that
it will be trivial for bad actors to bypass this bit of "protection".
Agreed. When a signature is not found, there was agreement that the
domain within the email-address contained within the From header
establishes policy. Using the domain of the first email-address made
good sense. I agree a signature should be able to be on-behalf-of
"Sender", "second author" or for that matter an opaque identity within
the i= parameter and not associate with any header. When the policy
for "first author's" domain indicates "all" or "strict", the only
requirement this should establish is a signature by the "first
author's" domain on-behalf-of _any_ identity.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html