Tony,
I see your point.
Does this presume that BS will be taking responsibility for the original
domain?
If Resent-From: becomes the source for DKIM verification, in essence, it has
become a 3rd party signature system in the eyes of downlink verifiers? Yes?
If it is viewed as a brand new submission, then I think it is more
consistent, but this is why SSP plays a vital role here.
As long as we have uncontrolled potential of 3rd party signers, we will also
have a big mess of who is truly valid or not, especially when it comes to
unsigned original mail.
In my view, the DKIM compliant BS server (router/resender) should be "picky"
on what it signs as original or as a resend. This is where SSP helps.
Also another no so minor point:
Will DKIM mandate support for RESENT-* fields? That's an awful big jump if
so.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Tony Hansen" <tony(_at_)att(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Thursday, July 13, 2006 9:02 AM
Subject: Re: [ietf-dkim] Draft minutes...
Person A sends the message to Person B. A's server AS does not sign the
message. Person B decides to resend the message to Person C, and B's
server BS duly adds a Resent-From: header and does signing.
As far as BS is concerned, the Resent-From: header is the one that
*should* be signed, not the From: header.
Tony Hansen
tony(_at_)att(_dot_)com
Hector Santos wrote:
----- Original Message -----
From: "william(at)elan.net" <william(_at_)elan(_dot_)net>
So if message has Resent-From field would SSP check be done against
From
or Resent-From or both?
The verification is already done before the Resent-From was added.
i.e., Resent-* should not be in original mail.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html