[ietf-dkim] Re: Responsibility concerns with DesignatedSigning
hsantos at santronics.com
Mon Aug 28 03:35:21 PDT 2006
----- Original Message -----
From: "Frank Ellermann" <nobody at xyzzy.claranet.de>
To: <ietf-dkim at mipassoc.org>
> Hector Santos wrote:
>> Subject: Check your account
>> Date: Sun, 27 Aug 2006 05:04:42 -0700
>> From: accounts at bank.com
>> To: PoorUser at ISP.COM
>> Sender: support at asp.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
> 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
In the general sense Frank, in a DKIM only would, it is failure analysis and
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
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
With SSP for DKIM, I think it is natural part of the protocol - Signature
Hector Santos, Santronics Software, Inc.
More information about the ietf-dkim