Dave CROCKER wrote:
I think that that's entirely the wrong question.
For this stage of the document, the questions are:
1) What problems have been documented as being due to this wording?
2) What technical errors does this text clearly represent.
In both cases, the answer for this text is "none".
Hence, no change should be contemplated.
Dave, the SDID is not always the responsible identity for transporting
a message.
2.5 implies the SDID is responsible for moving the message.
Using your criteria, I believe it falls closer to #2, but closer to an
functional error.
Maybe an example will help when viewed from a receiver or MUA standpoint:
Non-list:
Sender: Dave @ somewhere.com
From: user @ hosted-user-domain.com
To: Dave @ somewhere.com
DKIM-Signature: d=trustme.com
List:
Sender: list-admain @ list-galore.com
From: user @ hosted-user-domain.com
To: Dave @ somewhere.com
DKIM-Signature: d=trustme.com
Who introduced the message into the mail stream in both cases?
Certainly not the SDID trustme.com.
A small fix to section 2.5 clears up the SDID transport responsibility
ambiguity:
A single domain name that is the mandatory payload output of DKIM and
that refers to the identity claiming responsibility for signing the
message.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html