https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6462
--- Comment #10 from Mark Martinec <[email protected]> 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: [email protected] 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, [email protected]); 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: [email protected]", while the verifier saw a reconstructed header field with address in angle brackets like "Return-Path: <[email protected]>" 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 [email protected], [email protected] (still true at least for [email protected]) - 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: [email protected] 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: [email protected] 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.
