Steve Atkins wrote:
On Sep 5, 2010, at 1:10 PM, Hector Santos wrote:
In 2006, I submitted the I-D
http://tools.ietf.org/html/draft-santos-dkim-rcvd-00
Is there any interest for me to renew this I-D to help address some of
the possible time-shifting issues related key expiration and
revocation as detailed by the I-D?
I believe this proposal is useful for systems that might want to
support verifiers but are not ready to do it themselves yet - a
migration consideration.
Is there any reason why this proposal would not assist DKIM?
If you've done the DNS work to look up the DKIM TXT record then
validating the message is pretty simple.
But not a simple component to add on top of just a simple TXT lookup
and creating of a DKIM-Received: to add.
And there's no suggestion that DKIM is intended for use at the MUA.
Not quite true Steve and I believe you know this.
It was a DESIRE that the backend do the DKIM work, but it has long
been suggested that MUAs could also do the work. IMPO, not desirable
but nonetheless possible.
In fact, Doug Otis can remind us of this because he did extensive
work and reported this research here. There might be already a few
vendors with MUA plug-ins for SPF and DKIM support.
I'd rather developers expend effort on something like the
Authentication-Results header than on this halfway approach.
Did you even read the I-D? DKIM-RCVD covers the entire picture. Its
not half-way at all. It helps resolves the time-shifted key expiration
and revocation issues.
Having an A-R would assume the verifier exist and the process
performed and be trusted via A-R tags which I believe the consensus is
- you should not use this for trust.
Since DKIM-RCVD predated the A-R consideration, if the interest is
there I can update it to throw in A-R support. If the A-R is found,
an assessor MAY use this as part of its assessment logic.
But its really two independent ideas. One addresses the time-shifting
issues with keys, the other does not.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html