Subject: [ietf-dkim] DKIMcore

From: Franck Martin <[email-masked]>
Date: Thu, 12 Mar 2009 09:48:07 +1200 (ANAT)

http://dkimcore.org/dkimcore.pdf 

I just stumbled on this document, this seems strange to me. What do you think? 

I find that adding a hash on the body and putting it in the DKIM record will certainly break the DKIM spec, as it stops mailing lists to forward a DKIM email and add a footer to the email as the first example that comes to mind. 

Correct? 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: HLS <[email-masked]>
Date: Wed, 11 Mar 2009 18:24:45 -0400

Well, anonymous domains and documents should not be trusted, especially
since PDF   has recently suffered with Zero-Day PDF Exploit.
     Google:  PDF  Zero Day Exploit

Its fresh out of the press.

This domain has no content, totally blind.  I would not trust this dkimcore
. org until they reveal themselves.

--

On Wed, Mar 11, 2009 at 5:48 PM, Franck Martin <[email-masked]> wrote:

> I find that adding a hash on the body and putting it in the DKIM record
> will certainly break the DKIM spec, as it stops mailing lists to forward a
> DKIM email and add a footer to the email as the first example that comes to
> mind.
>
> Correct?
>

-- 
hls

---

From: SM <[email-masked]>
Date: Wed, 11 Mar 2009 20:47:48 -0700

At 15:24 11-03-2009, HLS wrote:
>This domain has no content, totally blind.  I would not trust this 
>dkimcore . org until they reveal themselves.

The person who wrote that document revealed himself/herself. :-)

Regards,
-sm

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Thu, 12 Mar 2009 09:44:13 +0530

> The person who wrote that document revealed himself/herself. :-)

And if people missed that, then I am sure a simple whois query on the
domain isnt past the capabilities of people on this wg :)

---

From: Hector Santos <[email-masked]>
Date: Thu, 12 Mar 2009 02:45:29 -0400

> domain isnt past the capabilities of people on this wg :)

Call me paranoid. :-)

Sure I was going to go that far, but it didn't matter.
To post something like this, with no authorship, an empty domain.org 
content and just 48 hours ago, Adobe PDF was just hit with the 
Zero-Day Exploit (or the flaw was made public). Well, not very smart.

-- 
Sincerely

Hector Santos
http://www.santronics.com

---

From: Steve Atkins <[email-masked]>
Date: Thu, 12 Mar 2009 10:20:19 -0700

> I just stumbled on this document, this seems strange to me. What do  

It's a work in progress to provide operational documentation for
typical senders who want to use DKIM, but for whom the dry
RFC-style specification isn't as helpful as a more HOWTO set
of docs.

There was some text around the intent of the document and
it's relationship to DKIM in the mail you received in confidence
prior to sharing it here, but that's not ready to go up publicly on
the website yet. Maybe next week.

(Part of the reason for the delay is that in the process of putting it
together I may have found what looks like a hole in the DKIM spec or,
more likely, some common implementations of it, and I want to
see whether that's so or not first).

>
> I find that adding a hash on the body and putting it in the DKIM  
> record will certainly break the DKIM spec, as it stops mailing lists  
> to forward a DKIM email and add a footer to the email as the first  
> example that comes to mind.

Well, that's the DKIM signing algorithm, so if it's broken you should
take it up with the authors of 4871.

Cheers,
   Steve

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 13 Mar 2009 14:38:44 +0100

> RFC-style specification isn't as helpful as a more HOWTO set

That's been a big problem when talking to operationally-minded folks -- 
which includes a very large percentage of likely implementers.  Steve's 
document is a good start, and I've made a bit of an attempt with a blog 
series currently ongoing on returnpath.net and CircleID, but we need more 
people who actually understand DKIM -- all of whom are on this list -- to 
write in a more readable manner about what it really means and how it really 
works.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 13 Mar 2009 07:39:48 -0700

J.D. Falk wrote:
>>       but for whom the dry
> which includes a very large percentage of likely implementers.  
...
>      we need more 

Won't the Overview, as well as the Deployment, documents help?

(Comments on the Deployment draft have been less than sparse...)

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 13 Mar 2009 15:48:07 +0100

> Won't the Overview, as well as the Deployment, documents help?

I hope so.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 13 Mar 2009 08:26:23 -0700

>> Won't the Overview, as well as the Deployment, documents help?
Hmm. Overview's been around a long time...

Can you list off some bullets of what you think is missing from an ops
standpoint? A DKIM cookbook could be helpful, especially if it takes
into account day to day realities and the inevitable "oh crap, how do we
deal with this???" that is likely for all but simplest of domains. We 
certainly
had enough of them at Cisco.

       Mike