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) <[email protected]>wrote: > > > > -----Original Message----- > > From: [email protected] [mailto:ietf-dkim- > > [email protected]] On Behalf Of John Levine > > Sent: Wednesday, March 11, 2009 6:40 AM > > To: [email protected] > > Cc: [email protected] > > 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
