Bug #27106 for Mail-DKIM: Failed Header Verification When "h=" Is Missing

Sat May 12 13:51:48 2007 imacat [...] cpan.org - Ticket created

Subject:

Failed Header Verification When "h=" Is Missing

Dear Jason Long, Hi. This is imacat from Taiwan. I found that DKIM verification may fail if 1. "h=" is not present in the DomainKeys-Signature: header. 2. The local mail filters adds their own headers. As far as I know, several mail filters like ClamAV, MIMEDefang adds their headers such as "X-Virus-Scanned:", "X-Virus-Status:", "X-Scanned-By:". If a mail is fetched and forwarded with Fetchmail, there may be "X-UIDL:", too. This caused many of my legitimate mails be blocked (including yours). In fact, in the current IETF draft, draft-ietf-dkim-base-10, 3.5 http://www.ietf.org/internet-drafts/draft-ietf-dkim-base-10.txt "h=" becomes REQUIRES comparing to the original Yahoo! draft: draft-delany-domainkeys-base-01.txt, 3.3 http://antispam.yahoo.com/domainkeys/draft-delany-domainkeys-base-01.txt I consider this as a bug in the Yahoo!'s original draft. Should Mail::DKIM fixes this accordingly, by allowing missing "h=" results "pass" or "none"? Thank you.

Mon May 14 16:11:15 2007 jason [...] long.name - Taken

Mon May 14 16:12:26 2007 jason [...] long.name - Correspondence added

On Sat May 12 13:51:48 2007, IMACAT wrote: Show quoted text

> I consider this as a bug in the Yahoo!'s original draft. Should > Mail::DKIM fixes this accordingly, by allowing missing "h=" results > "pass" or "none"? Thank you.

I think ignoring signatures that don't have "h=" is a reasonable solution. (Maybe a configurable option.) I'll put it on my TODO list. Jason

Mon May 14 16:12:36 2007 The RT System itself - Status changed from 'new' to 'open'

Fri May 18 00:14:08 2007 imacat [...] cpan.org - Correspondence added

On 2007-05-14 16:12:26 Mon, JASLONG wrote: Show quoted text

> On Sat May 12 13:51:48 2007, IMACAT wrote:

> > I consider this as a bug in the Yahoo!'s original draft. Should > > Mail::DKIM fixes this accordingly, by allowing missing "h=" results > > "pass" or "none"? Thank you.

> I think ignoring signatures that don't have "h=" is a reasonable > solution. (Maybe a configurable option.) I'll put it on my TODO list.

Dear Jason, I saw this is missing in the newly-released Mail-DKIM-0.25. Maybe you have missed it, or changed your mind? Also, may I ask the status of bug#27077? https://rt.cpan.org/Ticket/Display.html?id=27077

Tue Aug 12 12:18:44 2008 jason [...] long.name - Correspondence added

On Fri May 18 00:14:08 2007, IMACAT wrote: Show quoted text

> I saw this is missing in the newly-released Mail-DKIM-0.25. Maybe > you have missed it, or changed your mind? >

Well, this ticket is still open, so it's still on my TODO list. But maybe I did change my mind. I thought I might provide an option to "ignore" DomainKey signatures that do not have an "h=" tag, so that they do not "fail". However, the DKIM/DomainKey specifications tell us that a "fail" signature should never be considered worse than a "missing" signature, so in that sense (in my mind) there's no harm in leaving these signatures "fail". Jason

Thu Aug 21 13:42:50 2008 imacat [...] cpan.org - Correspondence added

Dear Jason, Hi. This is imacat from Taiwan. Sorry for the delay of my reply. On 2008-08-12 12:18:44 Tue, JASLONG wrote: Show quoted text

> On Fri May 18 00:14:08 2007, IMACAT wrote:

> > I saw this is missing in the newly-released Mail-DKIM-0.25. Maybe

> But maybe I did change my mind. I thought I might provide an option to > "ignore" DomainKey signatures that do not have an "h=" tag, so that they > do not "fail". > However, the DKIM/DomainKey specifications tell us that a "fail" > signature should never be considered worse than a "missing" signature, > so in that sense (in my mind) there's no harm in leaving these > signatures "fail".

I see. From what I observed in the past year, the often-signed "Content-Type" and "Content-Transfer-Encoding" headers are frequently altered by Sendmail, too. I think what you said makes sense. Thank you for your explanation.

Mon May 18 14:48:38 2009 jason [...] long.name - Status changed from 'open' to 'rejected'