The use of i= allows multiple subdomains to have the same d= DKIM
signature. As I said, I can live with d= personally but viewing it from
a standards approach I recognize the value of using i= for organizations
that use a number of subdomains.
Sometimes simplifying in one place (eliminate use of i= in favor of d=)
creates (operational) complexity in another.
J.D. gets where I'm going with this.
Mike
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Dave CROCKER
Sent: Wednesday, March 11, 2009 1:15 PM
To: J.D. Falk
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Moving on to ADSP - was RE: Handling the
errataafter the consensus call
Isn't it much simpler, and entirely sufficient, to have ADSP use SDID
(d=)?
I am not understanding the downside to the choice.
The alternatives all seem significantly more complicated and probably
problematic.
d/
J.D. Falk wrote:
MH Michael Hammer (5304) wrote:
I view introducing a new tag at this point as problematic.
Agreed.
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.
So then i= would be effectively meaningless to verifiers, EXCEPT
when
used
in conjunction with ADSP, where it needs to match the author (From:)
address?
Seems reasonable to me, assuming we're all agreed that i= is opaque
to
verifiers in all other cases.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
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