----- Original Message -----
From: "Frank Ellermann" <[EMAIL PROTECTED]>
To: <[email protected]>
> Hector Santos wrote:
>
>> Subject: Check your account
>> Date: Sun, 27 Aug 2006 05:04:42 -0700
>> From: [EMAIL PROTECTED]
>> To: [EMAIL PROTECTED]
>> Sender: [EMAIL PROTECTED]
>> 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
