spamassassin-dev December 2011 archive
Main Archive Page > Month Archives  > spamassassin-dev archives
spamassassin-dev: [Bug 6462] T_DKIM_INVALID is triggered on inco

[Bug 6462] T_DKIM_INVALID is triggered on incoming mail even though DKIM is authenticated

From: <bugzilla-daemon_at_nospam>
Date: Sat Dec 17 2011 - 01:58:19 GMT
To: dev@spamassassin.apache.org

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6462

--- Comment #10 from Mark Martinec <Mark.Martinec@ijs.si> 2011-12-17 01:58:19 UTC ---
> 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).

-- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.