----- Original Message -----
From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Hector Santos wrote:
Subject: Check your account
Date: Sun, 27 Aug 2006 05:04:42 -0700
From: accounts(_at_)bank(_dot_)com
To: PoorUser(_at_)ISP(_dot_)COM
Sender: support(_at_)asp(_dot_)com
DKIM-Signature: d=bank.com # invalid 1st party
DKIM-Signature: d=asp.com... # valid 3rd party
[...]
According to DKIM-BASE, the valid 3PS signature would make
this an valid DKIM message, even if the 1st party signature
failed.
...
So from your POV it's invalid if the bank.com SSP says so, and
if you didn't forget to mention an important header field. But
your user might have arranged his forwarding via a munger, then
it's the known SPF problem.
Correct. How the verifier will address it can be various ways, including
SPF.
In the general sense Frank, in a DKIM only would, it is failure analysis and
protocol consistency.
Sherlock Holmes now has more evidence to work with when there is a DKIM
"fingerprints" and DNA available. Checking SSP concept would easily solve
this for bank.com simply because it may not be expecting 3rd party
signatures - very simple or asp.com to be the signer.
Hmmmm, maybe we have a compromise here with a special policy?
"I don't care if 3rd party exist, I don't want them, but
if they DO exist, it BETTER not destroy my 1st party
signature."
Its about keeping the *purpose* of the Digital Message Signature Alive - the
survivability. If a domain does not have control of the transport hops and
who can sign, can it atleast say:
"If you going to stick your fingers into this, then you better
do it right. Don't destroy my signature."
Sounds like we are heading into the same RELAXED issues of SPF and the
debates of needed SRS and the arguments of who (forwaring mta) is at fault.
The problem with SRS (in my view) is that it required a change to the SMTP
process.
With SSP for DKIM, I think it is natural part of the protocol - Signature
Authorization.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html