As I have said in the past, I can live with using d= instead of i= for ADSP
implementation but I prefer i= from a standard perspective. The key thing for
me is matching the "From" email address domain to a value (d= or i= works
equally well for me) in the signature.
If we stay with i= then:
* We do not need the informative note in Jim's proposed substitute text.
* We provide a mechanism for private experimentation and testing of finer
granularity using the full email address as some have expressed interest in.
I'm not looking for this personally but I believe that the draft/RFC can
accommodate these stated desires without causing any issues.
The only potential downside I see to sticking with i= is the assertion that
some people might be confused by the format that looks like an email address
but doesn't necessarily have to be an email address.
Domains publishing an ADSP "all" or "discardable" record undertake certain
risks that are associated with such assertions. This implies that domains
wishing to implement ADSP will impose constraints on how their mail is sent.
Not all domains are appropriate candidates for ADSP implementation.
Mike
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Barry Leiba
Sent: Tuesday, March 31, 2009 10:06 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Consensus point on ADSP
My problem is that the semantics of the signature that the mailing
list applies shouldn't depend on whether the original author
happens to be in the same domain as the list.
Of course. That's why list mail should use a different signing
domain. It's clearly a poor idea to sign mail from lists that have
contributors in multiple unknown domains with a d= that has an ADSP
assertion
There still does not seem to be a problem. A DKIM signature allows
source differentiation.
I'm enjoying this whole discussion, and I think it's productive.
Can we draw in the WG participants who haven't yet commented on this?
I'd like to hear your opinions too, and get your ideas on how you'd
like to see this question resolved.
Barry
_______________________________________________
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