> A test email was sent from a gmail account to a postfix/spamassasin box.
> opendkim validates the DKIM data in the inbound email and reports:
>   Authentication-Results: example.org; dkim=pass
>   (1024-bit key; insecure key) header.i=@gmail.com; dkim-adsp=pass
> spamassassin reports:
>   spamd: result: . 0 - FREEMAIL_FROM,LOCALPART_IN_SUBJECT,T_DKIM_INVALID

Please attach a complete sample message, which may help guessing how the
message was modified on its way to SpamAssassin, or what else may have
gone wrong. Also the debug output from a command line spamassassin could
shed some light, e.g.  spamassassin -t -D dkim <0.msg

Please also explain how your spamc is hooked up with the mailer, i.e.
at what stage of mail delivery it is called.

I've ditched the 32bit system for the moment and have moved to 64bit, so can't currently recreate the error. The 64 bit system i'm running has the same configuration as the previous 32bit but doesn't present the T_DKIM_INVALID error.

I have a transaction log snippet from an email that triggered the T_DKIM_INVALID error if that's helpful at all?

Jul 10 18:03:33 cobalt postfix/smtpd[3288]: connect from mail-fx0-f50.google.com[209.85.161.50]
Jul 10 18:03:34 cobalt postfix/smtpd[3288]: ABC653FC3B: client=mail-fx0-f50.google.com[209.85.161.50]
Jul 10 18:03:34 cobalt postfix/cleanup[3292]: ABC653FC3B: message-id=<AANLkTinOmOWDwCbOUCKa6-sTiKYzfYrJRkZih2X-cYgh@mail.gmail.com>
Jul 10 18:03:34 cobalt opendkim[3282]: ABC653FC3B mail-fx0-f50.google.com [209.85.161.50] not internal
Jul 10 18:03:34 cobalt opendkim[3282]: ABC653FC3B not authenticated
Jul 10 18:03:35 cobalt postfix/qmgr[1987]: ABC653FC3B: from=<imaginary.user@gmail.com>, size=1663, nrcpt=1 (queue active)
Jul 10 18:03:35 cobalt spamd[781]: spamd: connection from localhost [127.0.0.1] at port 38373
Jul 10 18:03:35 cobalt spamd[781]: spamd: setuid to spamd succeeded
Jul 10 18:03:35 cobalt spamd[781]: spamd: processing message <AANLkTinOmOWDwCbOUCKa6-sTiKYzfYrJRkZih2X-cYgh@mail.gmail.com> for spamd:1002
Jul 10 18:03:36 cobalt spamd[781]: spamd: clean message (0.7/5.0) for spamd:1002 in 1.2 seconds, 1709 bytes.
Jul 10 18:03:36 cobalt spamd[781]: spamd: result: . 0 - FREEMAIL_FROM,LOCALPART_IN_SUBJECT,T_DKIM_INVALID scantime=1.2,size=1709,user=spamd,uid=1002,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=38373,mid=<AANLkTinOmOWDwCbOUCKa6-sTiKYzfYrJRkZih2X-cYgh@mail.gmail.com>,autolearn=no
Jul 10 18:03:36 cobalt postfix/pipe[3294]: ABC653FC3B: to=<test@i-systems.co.uk>, relay=spamassassin, delay=2, delays=0.74/0.02/0/1.3, dsn=2.0.0, status=sent (delivered via spamassassin service)
Jul 10 18:03:36 cobalt postfix/qmgr[1987]: ABC653FC3B: removed
Jul 10 18:03:36 cobalt postfix/pickup[3237]: 9F1AA41C4C: uid=1002 from=<imaginary.user@gmail.com>
Jul 10 18:03:36 cobalt postfix/cleanup[3292]: 9F1AA41C4C: message-id=<AANLkTinOmOWDwCbOUCKa6-sTiKYzfYrJRkZih2X-cYgh@mail.gmail.com>
Jul 10 18:03:36 cobalt opendkim[3282]: 9F1AA41C4C no signing table match for `imaginary.user@gmail.com'
Jul 10 18:03:36 cobalt postfix/qmgr[1987]: 9F1AA41C4C: from=<imaginary.user@gmail.com>, size=2113, nrcpt=1 (queue active)
Jul 10 18:03:36 cobalt clamsmtpd: 10000B: accepted connection from: 127.0.0.1
Jul 10 18:03:36 cobalt spamd[755]: prefork: child states: II
Jul 10 18:03:36 cobalt postfix/smtpd[3302]: connect from localhost[127.0.0.1]
Jul 10 18:03:36 cobalt postfix/smtpd[3302]: D18C33FC3B: client=localhost[127.0.0.1]
Jul 10 18:03:36 cobalt postfix/cleanup[3292]: D18C33FC3B: message-id=<AANLkTinOmOWDwCbOUCKa6-sTiKYzfYrJRkZih2X-cYgh@mail.gmail.com>
Jul 10 18:03:36 cobalt opendkim[3282]: D18C33FC3B no signing table match for `imaginary.user@gmail.com'
Jul 10 18:03:37 cobalt postfix/qmgr[1987]: D18C33FC3B: from=<imaginary.user@gmail.com>, size=2327, nrcpt=1 (queue active)
Jul 10 18:03:37 cobalt clamsmtpd: 10000B: from=imaginary.user@gmail.com, to=test@i-systems.co.uk, status=CLEAN
Jul 10 18:03:37 cobalt postfix/smtp[3300]: 9F1AA41C4C: to=<test@i-systems.co.uk>, relay=127.0.0.1[127.0.0.1]:10025, delay=0.42, delays=0.17/0.03/0.06/0.16, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as D18C33FC3B)
Jul 10 18:03:37 cobalt postfix/smtpd[3302]: disconnect from localhost[127.0.0.1]
Jul 10 18:03:37 cobalt postfix/qmgr[1987]: 9F1AA41C4C: removed
Jul 10 18:03:37 cobalt postfix/pipe[3304]: D18C33FC3B: to=<test@i-systems.co.uk>, relay=zarafa, delay=0.45, delays=0.15/0.02/0/0.27, dsn=2.0.0, status=sent (delivered via zarafa service)
Jul 10 18:03:37 cobalt postfix/qmgr[1987]: D18C33FC3B: removed
Jul 10 18:04:05 cobalt postfix/smtpd[3288]: disconnect from mail-fx0-f50.google.com[209.85.161.50]

spamassassin is called by a content_filter in a second postfix smtp server that's used for reinjection:

127.0.0.1:10025 inet  n -       n       -       16      smtpd
        -o content_filter=spamassassin
        -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_milters
        -o smtpd_helo_restrictions=
        -o smtpd_client_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_recipient_restrictions=permit_mynetworks,reject
        -o mynetworks_style=host
        -o smtpd_authorized_xforward_hosts=127.0.0.0/8


Every email that I sent from my gmail account to my test system triggered the T_DKIM_INVALID error irrespective of content.

I believe I am seeing the same issue on an inbound email from Yahoo!'s webmail to my server.  This email is a long email that has a number of False Positives but right now I am focus

For my particular email, the email is received by Sendmail with a milter of MD.  SA is then run from procmail.  From checking my logs, MD added two headers, a scanned by and a reverse DNS header.  However, I am checking the original email that should be unmodified in all respects.

Here is a 3.3.0 test with DKIM 0.37 on the email.  The sender email address has been removed for privacy reasons.

[root@intel1 root]# cat /tmp/1 | spamassassin -t -D 2>&1 | grep -i DKIM
Nov 28 09:29:04.007 [10620] dbg: plugin: loading Mail::SpamAssassin::Plugin::DKIM from @INC
Nov 28 09:29:04.578 [10620] dbg: config: fixed relative path: /var/lib/spamassassin/3.003000/updates_spamassassin_org/25_dkim.cf
Nov 28 09:29:04.578 [10620] dbg: config: using "/var/lib/spamassassin/3.003000/updates_spamassassin_org/25_dkim.cf" for included file
Nov 28 09:29:04.579 [10620] dbg: config: read file /var/lib/spamassassin/3.003000/updates_spamassassin_org/25_dkim.cf
Nov 28 09:29:04.815 [10620] dbg: config: fixed relative path: /var/lib/spamassassin/3.003000/updates_spamassassin_org/60_adsp_override_dkim.cf
Nov 28 09:29:04.815 [10620] dbg: config: using "/var/lib/spamassassin/3.003000/updates_spamassassin_org/60_adsp_override_dkim.cf" for included file
Nov 28 09:29:04.816 [10620] dbg: config: read file /var/lib/spamassassin/3.003000/updates_spamassassin_org/60_adsp_override_dkim.cf
Nov 28 09:29:04.869 [10620] dbg: config: fixed relative path: /var/lib/spamassassin/3.003000/updates_spamassassin_org/60_whitelist_dkim.cf
Nov 28 09:29:04.872 [10620] dbg: config: using "/var/lib/spamassassin/3.003000/updates_spamassassin_org/60_whitelist_dkim.cf" for included file
Nov 28 09:29:04.873 [10620] dbg: config: read file /var/lib/spamassassin/3.003000/updates_spamassassin_org/60_whitelist_dkim.cf
Nov 28 09:29:08.745 [10620] dbg: rules: [...] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1290880365; bh=9h1T6FIV5OYVdD8Wm4EgTkwUSN+CFi0OkkgtnnoyqbM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=vd23PESxJHuD7GB4vDs/HkEDO/4RO1IzYDtSBg+mNPABtGsRfaJLO0MfJpA1BP1HhV3Hbs7qvRfRmtlBFg0+z0eMYSnZVQTwKIr5VO6qdLxyWwzQ++yh6hbL50qY+Vt2+pyuIyEk8gJypxRtrpdyxJKj2QiuEGzKvPL66UbCc0k=
Nov 28 09:29:08.749 [10620] dbg: rules: ran header rule __DKIM_EXISTS ======> got hit: "<YES>"
Nov 28 09:29:08.973 [10620] dbg: dkim: using Mail::DKIM version 0.37
Nov 28 09:29:09.057 [10620] dbg: dkim: performing public key lookup and signature verification
Nov 28 09:29:09.061 [10620] dbg: dkim: i=@yahoo.com, d=yahoo.com, a=rsa-sha256, c=relaxed/relaxed, fail, matches author domain
Nov 28 09:29:09.061 [10620] dbg: dkim: i=-munged-@yahoo.com, d=yahoo.com, a=rsa-sha1, c=nofws, fail, matches author domain
Nov 28 09:29:09.061 [10620] dbg: dkim: signature verification result: FAIL (MESSAGE HAS BEEN ALTERED)
Nov 28 09:29:09.062 [10620] dbg: dkim: adsp override for domain yahoo.com
Nov 28 09:29:09.062 [10620] dbg: dkim: adsp result: 2/custom_med (override), author domain 'yahoo.com'
Nov 28 09:29:09.217 [10620] dbg: rules: ran eval rule DKIM_ADSP_CUSTOM_MED ======> got hit (1)
Nov 28 09:29:09.221 [10620] dbg: dkim: FAILED signature by yahoo.com, author -munged-@yahoo.com, no valid matches
Nov 28 09:29:09.222 [10620] dbg: dkim: FAILED signature by yahoo.com, author -munged-@yahoo.com, no valid matches
Nov 28 09:29:09.222 [10620] dbg: dkim: author -munged-@yahoo.com, not in any dkim whitelist
Nov 28 09:29:30.310 [10620] dbg: rules: ran eval rule DKIM_SIGNED ======> got hit (1)
Nov 28 09:29:30.313 [10620] dbg: rules: ran eval rule __DKIM_DEPENDABLE ======> got hit (1)
Nov 28 09:29:30.648 [10620] dbg: check: tests=AWL,BAD_CREDIT,DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,KAM_RPTR_PASSED,LOTS_OF_MONEY,MONEY_FRAUD_3,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_NONE,RCVD_IN_RPBLSPAMMER,RFC_ABUSE_POST,T_DKIM_INVALID,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL
Nov 28 09:29:30.649 [10620] dbg: check: subtests=__ANY_TEXT_ATTACH,__ANY_TEXT_ATTACH_DOC,__BIGDOLLARSFVGT,__CT,__CTYPE_HAS_BOUNDARY,__CTYPE_MULTIPART_ALT,__CTYPE_MULTIPART_ANY,__DIPLOMA,__DKIM_DEPENDABLE,__DKIM_EXISTS,__DNS_FROM_RFC_ABUSE,__DNS_FROM_RFC_POST,__DOS_BODY_TUE,__DOS_HAS_ANY_URI,__DOS_RCVD_SAT,__DOS_REF_2_WK_DAYS,__DOS_RELAYED_EXT,__ENV_AND_HDR_FROM_MATCH,__EWG_BAD35,__EWG_BAD36,__EWG_BAD39,__EWG_BAD42,__EWG_BAD43,__EWG_BAD45,__EWG_BAD49,__EWG_BAD51,__EXCLAIM_SUBJ,__FB_GAME,__FB_PICK,__FEES,__FILL_THIS_FORM_LOAN,__FM_LARGE_MONEY,__FM_STOCK_WORDS,__FRAUD_DBI,__FRAUD_FBI,__FROM_FREEMAIL,__FROM_YAHOO_COM,__F_LARGE_MONEY,__HAS_ANY_URI,__HAS_DATE,__HAS_MESSAGE_ID,__HAS_MSGID,__HAS_RCVD,__HAS_SUBJECT,__HAS_X_MAILER,__HAVE_BOUNCE_RELAYS,__HIGHBITS,__HUSH_HUSH,__KAM_CEP6,__KAM_DEBT1,__KAM_LIST4,__KAM_LOTTO3,__KAM_NIGERIAN2_7,__KAM_PIC5,__KAM_REFI4,__KAM_REFI7,__KAM_RPTR_PASSED,__KAM_TIME4,__KAM_UNIV1B,__KAM_UPS2,__KAM_URUNIT3,__KAM_URUNIT4,__LAST_EXTERNAL_RELAY_NO_AUTH,__LAST_UNTRUSTED_RELAY_NO_AUTH,__LOTSA_MONEY_00,__LOTSA_MONEY_01,__LUCRATIVE,__MANY_RECIPS,__MBA,__MIME_HTML,__MIME_QP,__MIME_VERSION,__MISSING_REF,__MISSING_REPLY,__MSGID_BEFORE_OKAY,__MSGID_BEFORE_RECEIVED,__NONEMPTY_BODY,__RCD_RDNS_MAIL_MESSY,__RCVD_IN_2WEEKS,__RCVD_IN_DNSWL,__RCVD_IN_RPBL,__RCVD_IN_SORBS,__RCVD_IN_ZEN,__RECOGNITION,__RFC_IGNORANT_ENVFROM,__S25R_1,__SANE_MSGID,__SEX_WRDS,__SPAN_END_TEXT,__SPAN_END_TEXT,__SPAN_END_TEXT,__SPAN_END_TEXT,__TAG_EXISTS_BODY,__TAG_EXISTS_HEAD,__TAG_EXISTS_HTML,__TOCC_EXISTS,__TO_NO_ARROWS_R,__TVD_MIME_ATT_TP,__WORD_SEX,__YOU_WON,__YOU_WON_01,__YOU_WON_02
Nov 28 09:29:30.651 [10620] dbg: timing: total 27125 ms - init: 4105 (15.1%), parse: 23 (0.1%), extract_message_metadata: 541 (2.0%), poll_dns_idle: 7 (0.0%), get_uri_detail_list: 119 (0.4%), tests_pri_-1000: 136 (0.5%), compile_gen: 509 (1.9%), compile_eval: 66 (0.2%), tests_pri_-950: 17 (0.1%), tests_pri_-900: 18 (0.1%), tests_pri_-400: 15 (0.1%), tests_pri_0: 21823 (80.5%), dkim_load_modules: 81 (0.3%), check_dkim_signature: 87 (0.3%), check_spf: 161 (0.6%), check_razor2: 376 (1.4%), check_pyzor: 1.35 (0.0%), tests_pri_500: 248 (0.9%), tests_pri_1000: 82 (0.3%), total_awl: 57 (0.2%), check_awl: 3 (0.0%), update_awl: 3 (0.0%)
        DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
        RCVD_IN_DNSWL_NONE,RCVD_IN_RPBLSPAMMER,RFC_ABUSE_POST,T_DKIM_INVALID,
Filter Tests: AWL,BAD_CREDIT,DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,KAM_RPTR_PASSED,LOTS_OF_MONEY,MONEY_FRAUD_3,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_NONE,RCVD_IN_RPBLSPAMMER,RFC_ABUSE_POST,T_DKIM_INVALID,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL
 0.0 DKIM_ADSP_CUSTOM_MED   No valid author signature, adsp_override is
 0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily valid
 0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1290880365; bh=9h1T6FIV5OYVdD8Wm4EgTkwUSN+CFi0OkkgtnnoyqbM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=vd23PESxJHuD7GB4vDs/HkEDO/4RO1IzYDtSBg+mNPABtGsRfaJLO0MfJpA1BP1HhV3Hbs7qvRfRmtlBFg0+z0eMYSnZVQTwKIr5VO6qdLxyWwzQ++yh6hbL50qY+Vt2+pyuIyEk8gJypxRtrpdyxJKj2QiuEGzKvPL66UbCc0k=
Filter Tests: AWL,BAD_CREDIT,DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,KAM_RPTR_PASSED,LOTS_OF_MONEY,MONEY_FRAUD_3,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_NONE,RCVD_IN_RPBLSPAMMER,RFC_ABUSE_POST,T_DKIM_INVALID,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL
 0.0 DKIM_ADSP_CUSTOM_MED   No valid author signature, adsp_override is
 0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily valid
 0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid

Regards,
KAM

> I believe I am seeing the same issue on an inbound email from Yahoo!'s webmail
> to my server.  This email is a long email that has a number of False Positives
> but right now I am focus
> 
> For my particular email, the email is received by Sendmail with a milter
> of MD.  SA is then run from procmail.

Since you already have a milter-capable environment, perhaps the least
guesswork approach to troubleshooting would be to install a recent
OpenDKIM milter ( http://www.opendkim.org/ ). So the next time you hit
a non-valid DKIM signature from Yahoo!, you could compare the Mail::DKIM 
results with what the OpenDKIM reported in its inserted header field.

> From checking my logs, MD added two headers, a scanned by and a reverse
> DNS header.

Prepended header fields should not be a problem.

> However, I am checking the original email
> that should be unmodified in all respects.
> SA is then run from procmail.

The procmail interface might be a problem, or something else.

Manually checking the original captured mail can sometimes point out
the offending modification.

> Here is a 3.3.0 test with DKIM 0.37 on the email.  The sender email
> address has been removed for privacy reasons.

The SpamAssassin log is not of much use for troubleshooting changes
to a message causing DKIM signature to fail. Collecting a pristine
message is usually the first required step.

I recently encountered this same problem, also from a gmail test message. As suggested in comment 1, I ran this:

spamassassin -t -D dkim <0.msg

Debug output then began with:

Dec 22 11:31:37.346 [24116] dbg: dkim: cannot load Mail::DKIM module, DKIM checks disabled: Can't locate Mail/DKIM/Verifier.pm in @INC (@INC contains: /usr/share/perl5 /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl) at /usr/share/perl5/Mail/SpamAssassin/Plugin/DKIM.pm line 584

...but the content analysis says:

 0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid

It looks like the T_DKIM_INVALID rule should silently fail if it can't load Mail::DKIM, rather than claiming that the signature is not valid.

I can verify that by installing Mail::DKIM from CPAN, I get these results:

-0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from author's
                            domain
 0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily valid
-0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature

T_DKIM_INVALID shouldn't trip if Mail::DKIM isn't installed, but at least we know the reporter's problem is from a missing CPAN module.

I was able to work on this by using opendkim and thanks to their mailing list, "chopping the leading "From " line off of it and then pipe it to "opendkim -t -".  If you want verbose output, add a "-v" or two."

With this, I have not yet found a spample that is NOT modified midstream that fails one but passes the other.

I am adding some ability to try and gather some samples.

Not sure if this is the original poster's issue but it's definitely an interesting bug and it's the reason for my issue.  I'm going to post on the opendkim users list as well to see if anyone can give guidance.

I've been working with AXB and others for a few weeks on a DKIM issue.  Now, for my particular install, I know I have some DKIM failures because I purposefully modify the email body.  But I've also been testing in a pure sendmail installation.

The bug is a modified To: Header but I'm unsure why/what is changing the To: Header.  The first emails are being tested with spamassassin called from procmail after using MD is called. 

I found that if AXB uses the Gmail web interface, all is good.  However, he normally uses Thunderbird.  I think that's a red-herring or just part of the problem though so keep reading.

Now I have a trapped version of the email pre delivery / going through mimedefang, virus scanners, etc. etc.

Testing it with opendkim on the command line shows the pre works and the post sendmail/md/procmail fails:

[root@devel tmp]# opendkim -t - < gmailviatbird-predelivery.txt
opendkim: (stdin): verification (s=gamma, d=gmail.com, 1024-bit key) succeeded


[root@devel tmp]# opendkim -t - < gmailviatbird-postdelivery.txt
opendkim: (stdin): verification (s=gamma d=gmail.com, 1024-bit key) failed: signature verification failed

A diff and lots of trial and error testing showed that the failure was because of this:

-To: "Kevin A. McGrail" <KMcGrail@PCCC.com>
+To: "Kevin A. McGrail" <KMcGrail@pccc.com>

Specifically, the case change on the To: header.

So what rewrote the To: header and why?

The one thing I've been able to pin down is that if I use the gmail web-based interface and play around with case, the for part of the received header has the correct case and my DKIM tests work fine.

However, when AXB uses thunderbird to send via gmail, the case sensitivity between the for in the received and the To header appears different.


Now on a pure sendmail environment on a stock CentOS Installation, attached is an email AXB wrote via Thunderbird sent via gmail.  Note that it will fail opendkim UNLESS you modify the to header to the correct email address he used to root@TALON1.PCCC.com.  Somewhere along the way the To: header gets rewritten to all lower case.

However, I couldn't reproduce this scenario with all my tests but I don't use anything but Gmail's web interface.

So my conclusion is that Thunderbird or Gmail are somehow ending up with one case version of the to address as the for in the received header and a different case version in the to header.  Then during delivery, either procmail or sendmail are "fixing" the To: header which is breaking DKIM. 

Anyone have any recommendations?  Is this known behavior in sendmail or procmail?  Something specific to Gmail and using an external client?  Specific to Thunderbird?

Regards,
KAM

Discussion on the OpenDkim users list have pretty definitively pinned the culprit on Sendmail for changing the To: header based on the Rcpt to: data.

If the To: header and the Rcpt to: data differ in case, then DKIM could fail.

IMO, This is likely to be a much bigger issue than SpamAssassin...

I've been discussing this issue a lot on the OpenDKIM mailing list.

Are you using sendmail?

Can you add this to your submit.mc and sendmail.mc prior to any MAILER definitions?

dnl testing nocanonify for DKIM wonkiness with rcpt to: and To: header variance
FEATURE(`nocanonify',`canonify_hosts')dnl 

I found cases where the envelope rcpt to: information was being used to rewrite the To: header which changed the case of the header.  This case change broke the ability to validate the DKIM signature.

Implementing the above FEATURE nocanonify resolved the issue for me with sendmail 

HOWEVER,I do not know the pros and cons of that FEATURE beyond this specific problem.

Based on more feedback, I have a feeling everyone using Sendmail should consider this feature.

> Discussion on the OpenDkim users list have pretty definitively pinned the
> culprit on Sendmail for changing the To: header based on the Rcpt to: data.
> If the To: header and the Rcpt to: data differ in case, then DKIM could fail.
> IMO, This is likely to be a much bigger issue than SpamAssassin...

Yes, it's a (of of the) known issue(s) of sendmail mangling mail
header fields. Signing a To and Cc header fields is particularly
problematic and of little value. Some of my postings on this topic:


==========
Subject: Re: [ietf-dkim] DKIM/ADSP edge case writeup at CircleID
From: Mark Martinec
To: ietf-dkim@mipassoc.org
Date: 2009-03-24

MH Michael Hammer wrote:
> I posted a write up on an issue with DKIM/ADSP and missing message-ids
> at CircleID that might be of interest to people:
> http://www.circleid.com/posts/20090323_exploring_dkim_adsp_edge_cases_mi
> ssing_message_id/
> I'm going to try to spend a little more time focusing on some of the
> implementation "gotchyas" related to DKIM/ADSP for a while.

I promised the following list to Michael, but it is probably of a
wider interest, so I'm posting it here.

For more than a year I've been interested in cases where apparently
a genuine DKIM signature is broken as received at our mailer (with
about 1000 active users), so I started collecting such cases.

It's a bit tricky to find out what could be a reason for a failure,
but with practice some of these blunders can be guessed, typically
by trying to reconstruct the original message until a signature
becomes valid. Sometimes a combination of DKIM and a DomainKeys
signatures helps to see what went wrong, sometimes a 'z' tag helps,
sometimes I've been asking the sending site for joined troubleshooting
or I could reproduce it by using the same type of a suspect MTA,
and sometimes just plain guessing did the job.

So here is my list. Each entry reflect an actual case of received mail.
Some of these may have been fixed meanwhile by the sending domain,
so I'm not claiming that all of them still apply for the named domain.

- signing Bcc header field (which gets stripped away by MTA);

- signing a Return-Path header field (e.g.: yahoo-inc.com, avaaz@avaaz.org);
  Apart from the fact that a verifier at MTA may not see the Return-Path
  at all, and that signing envelope info is not something DKIM was supposed
  to do, the actual failure reason in this case was that a signer signed
  a Return-Path header field like: "Return-Path: user@example.com", while
  the verifier saw a reconstructed header field with address in angle
  brackets like "Return-Path: <user@example.com>" as required by RFC 2822;

- adding a local Sender header field and signing it, then posting to a
  mailing list, which may be DKIM friendly, but still is required to
  strip the original Sender header field and replace it with its own;
  My pointing the blame in this case goes to RFC 2822, which does not
  allow more than one occurrence of a Sender header field. Allowing
  multiple Sender header field (new ones appended at the top) would
  avoid the issue. This is a reason why our site is not signing
  the Sender header field (except for mailing list fanout);

- forwarding (by MailServer or Microsoft SMTPSVC?) replaces Message-ID,
  adds "FW:" to a Subject, replaces Date, but keeps original signature
  and Received header fields

- some mailing lists strip Received header fields (lighttpd, bugtraq)
  (although I should add that a breakage due to a stripped but signed
  Received header field is much less common that other breakages, like
  a mangled To header field)

- with DomainKeys: no h tag, but does not provide a Message-ID,
  which is inserted by a receiving MX prior to validation,
  e.g. from y-alerts@reply.yahoo.com, reminders@reply.yahoo.com
  (still true at least for y-alerts@reply.yahoo.com)

- signature includes Message-ID in h tag, but there was no Message-ID in
  the original message at the time of signing. When a receiving MX inserts
  a missing header field, it breaks the signature.

- missing or misplaced public key, e.g. signs as
  s=mail, d=members.stockhouse.com, but key at d=stockhouse.com;
  or: jpl.nasa.gov key, lungusa.org, christopherreeve.org found
    under kintera.com;
  or: forgets a selector in DNS name: _domainkey.travian.com;
  or: ci._domainkey.ci.freewebs.com with d=freewebs.com;

- syntax errors in public key:
    * missing ';' between tags (stardock.com),..
    * a '+' in a published base64-encoded p tag is converted to a space:
      default._domainkey.biofeedbackinternational.com,
      k1._domainkey.mcsv22.net
      (looks like a web GUI blunder)

- signed 'To', but fetchmail(?) rewrites 'To' into a (Recipient list suppressed)

- sendmail reformats long lists of addresses in a To header field,
  which is why our site is not signing a To header field;

- some mailers add a space after a colon, e.g. rewriting a
  "Subject:foo" into a "Subject: foo"

- Mailman rewrites 'Reply-To: <addr>' into 'Reply-To: addr'
  and 'Reply-To: "Display Name" <addr>' into 'Reply-To: Display Name <addr>'

- Postfix strips bare CR at end-of-line which invalidates a signature in a
  message with embedded bare CRs at eol (e.g. with altermime html disclaimers)
  (this is just one case of a garbage-in / garbage-out principle, the lesson
  to be learned is that a mail to be signed should be syntactically correct)

- mail provider is mangling a Date header field:
    original: Date: Mon, 4 Aug 2008 17:43:42 -0400 (EDT)
    mangled:  Date: Mon, 04 Aug 2008 17:43:42 -0400 (EDT)

- system time on the signing host is few minutes into the future,
  dkim-milter considers it an invalid signature

- resend munge (at Cern)

- PerlMX munge

- eSafe munge: eSafe SMTP Relay / Microsoft SMTPSVC at gen-energija.si

- PMDF munger (rcum.uni-mb.si)

- eBay and PayPal: signs non-existent Resent-From, preventing resending

- the new yahoo.com DKIM signatures with c=relaxed/relaxed appears
  to get a body canonicalization wrong (signature h is ok, bh wrong)
  If someone is interested I have a truly small enough example,
  suitable for troubleshooting (several empty lines, followed by
  the last line with several spaces)

Mark


==========
From: Mark Martinec
To: opendkim-users@lists.opendkim.org
Date: 2011-02-18
> http://www.opendkim.org/stats/report.html
> Most frequent header field changes resulting in signature failures:
>   to     2989
>   subject 233
>   cc      178
>   from    134
>   date    131
>   reply-to 84
>   message-id 45
>
This table pretty much proves my claim (expressed on
various occasions) that signing the "To" is asking
for trouble (and brings no benefit).
>
> Signed header field frequency (top 20 shown):
> from       2440351
> subject    2335598
> date       2329541
> to         2327365
> mime-version 2256624
> content-type 2072952
> message-id   1836235
> reply-to     1071669
> received      978484
> list-unsubscribe 763708
> content-transfer-encoding 518180
> sender 409641
>
This illustrates my other claim: signing the Received
header field is common and mostly harmless, despite
the dkim rfc trying to shy us away from doing so.


==========
From: Mark Martinec
To: opendkim-users@lists.opendkim.org
Date: 2011-02-18
[...]
That may well be. Regardless, the To and Cc header fields
are quite commonly munged by mailers, let alone by MUAs.
For example, sendmail has a nasty habit of 'prettifying'
the list of addresses if it doesn't fit its idea of a nice form.
Also, some mailers would append a local domain to a
non-FQDN recipient address in a To and Cc header field.

With anything beyond a simple one- or two-recipient lists
in a To header, a likelihood of breakage is substantial.

As for the perceived benefit of a signed To, I don't see any.
Addresses in this header field are purely informational,
they don't affect mail routing or delivery, and they don't reflect
the final recipient address (e.g. with mailing lists or with Bcc).

(In reply to comment #10)
> > Discussion on the OpenDkim users list have pretty definitively pinned the
> > culprit on Sendmail for changing the To: header based on the Rcpt to: data.
> > If the To: header and the Rcpt to: data differ in case, then DKIM could fail.
> > IMO, This is likely to be a much bigger issue than SpamAssassin...
> 
> Yes, it's a (of of the) known issue(s) of sendmail mangling mail
> header fields. Signing a To and Cc header fields is particularly
> problematic and of little value. Some of my postings on this topic:

Based on conversations and continued testing from input on the DKIM mailing list, this may be a bug in Sendmail.

More information to be added.

The attached patch changed behavior in Sendmail that can modify the To header that is received from the sender AFTER the message has been DKIM signed.

This behavior can cause issues in situations such as using Gmail to send to a recipient using gmail where the To: address uses mixed case letters causing DKIM after receipt to fail.

This patch from Claus Aßmann will be included in the next sendmail release and was tested on Sendmail 8.14.5.

I believe this resolves the issue unless more samples are produced that show it isn't a To: Case issue.

For those who don't want to patch/install their own sendmail, the nocanonify feature has helped eliminate the issue in real-world environments as well but is likely doing other things that may cause issues.

i.e. submit.mc and sendmail.mc including:

FEATURE(`nocanonify',`canonify_hosts')

Closing as invalid as likely a configuration/bug in MTA.

regards,
KAM

Created attachment 5035 [details]
Patch for Sendmail 8.14.5 re: canonification of To: Header

NOTE: this is not a patch for SpamAssassin.