Subject: [ietf-dkim] DKIM-RCVD I-D

From: Hector Santos <[email-masked]>
Date: Sun, 05 Sep 2010 16:10:48 -0400

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?

-- 
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

---

From: Steve Atkins <[email-masked]>
Date: Sun, 5 Sep 2010 13:40:44 -0700

> 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. And there's no suggestion
that DKIM is intended for use at the MUA.

I'd rather developers expend effort on something like the
Authentication-Results header than on this halfway approach.

Cheers,
  Steve

---

From: Hector Santos <[email-masked]>
Date: Sun, 05 Sep 2010 18:06:21 -0400

Steve Atkins wrote:
> 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.

> 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.