The more we move "policy" information or in this case Jim's reputation-based
policy r= idea to the DKIM policy record, the better, where it ought to be
to better cover the legacy transactions (those without signatures).
--
hls
On Wed, Mar 11, 2009 at 12:01 PM, MH Michael Hammer (5304)
<MHammer(_at_)ag(_dot_)com>wrote:
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of John Levine
Sent: Wednesday, March 11, 2009 6:40 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Cc: barryleiba(_at_)computer(_dot_)org
Subject: Re: [ietf-dkim] Moving on to ADSP - was RE: Handling the
errataafter the consensus call
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 view introducing a new tag at this point as problematic.
Using i= or even going to using d= does not require any changes to
current DKIM signing implementations. Introducing a new tag means that
implementers are at the mercy of the timeframes that vendors choose to
change how they sign DKIM.
As I have said before, I can personally accept using d= because of how
we chose to implement DKIM signing for our domains. I lean towards i=
for ADSP because I believe it gives others benefits.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html