John Levine:
I'm not sure what my opinion is on that last point, but on the first
point I think it's best to define an identifier that's specifically
for ADSP's use, if we want that function. Some signers may give that
tag the same value they give i=, and there's no harm done. Some
signers may use a different value, which would demonstrate the wisdom
of separating them.
Seems like a reasonable way to avoid the i= fight. If there's interest,
I can whip up a new ADSP draft with an r= tag.
I am not sure how adding an r= tag would help deciding whether a
specific d= domain has made a first-party signature on behalf of
the rfc822.from.
Another way to avoid the i= fight is to design it out of ADSP
(leaving it in DKIM, if it can't be eliminated there).
ADSP is looked up for mail without a first-party DKIM signature.
In an ADSP without i=, the ingredients for the "first-party"
signature decision are:
1) DKIM signature check: Is the DKIM signature valid per DKIM rules
(this may or may not involve i=, but that is outside ADSP's scope).
2) First party check: Do rfc822.from and d= have the proper
relationship. This check is ADSP-specific.
If these checks fail, look up the ADSP policy for rfc822.from and
make a ruling.
Wietse
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html