Re: SA DKIM related bug 6462 - Possibly Gmail, Sendmail and/or Thunderbird related?

From: Kevin A. McGrail <>
Date: Thu, 15 Dec 2011 20:18:59 -0500

>> From my tests which are not completely exhaustive, sendmail appears to
>> overwrite the rcpt to: data to the To: header. I'm not sure if it does
>> this in all cases, only when the To: matches the rcpt to: data non-
>> case-sensitively, etc.
> I suspect the more likely case is that it wraps both to match the case of the string that came back from the DNS after MX and/or A queries.
I can't concur. Note this test with crazy mixed case:

Manual Injection

[root_at_talon1 ~]# telnet localhost 25
Connected to localhost.localdomain (
Escape character is '^]'.
220 ESMTP Sendmail 8.13.1/8.13.1; Thu, 15 Dec 2011
20:09:39 -0500
250 Hello localhost.localdomain [], pleased to
meet you
mail from:
250 2.1.0 Sender ok
rcpt to: rOoT_at_TaLoN1.PcCc.CoM
250 2.1.5 rOoT_at_TaLoN1.PcCc.CoM... Recipient ok
354 Enter mail, end with "." on a line by itself
Subject: Test from Manual SMTP with crazy rcpt to envelope

the To: header should be all lower case as entered.
250 2.0.0 pBG19dRB006091 Message accepted for delivery

Resulting email:

 From Thu Dec 15 20:11:01 2011
Return-Path: <>
Received: from (localhost.localdomain [])
         by (8.13.1/8.13.1) with SMTP id pBG19dRB006091
         for rOoT_at_TaLoN1.PcCc.CoM; Thu, 15 Dec 2011 20:10:09 -0500
Date: Thu, 15 Dec 2011 20:09:39 -0500
Message-Id: <>
Subject: Test from Manual SMTP with crazy rcpt to envelope
To: root_at_TaLoN1.PcCc.CoM

the To: header should be all lower case as entered.

>> I'm looking at this issue from SpamAssassin's DKIM implementation which
>> is not always used in a milter environment and is only concerned on
>> received messages.
> Since SpamAssassin verifies and doesn't sign, it has no choice but to use the data presented to it. The signer has apparently signed the To: with PCCC.COM, but received a To: with If that signature was generated with "simple" header canonicalization mode, it is guaranteed to fail.
And since Sendmail is shown to have this behavior, it sounds to me like
there needs to be a world-wide change in DKIM signature behavior to
allow time for Sendmail's behavior to be changed, etc.
>> So in the real-world case I started with, AXB is using Thunderbird to
>> send via Gmail to my servers. When received on my servers, the rcpt to:
>> data is all lower case which may or may not match the To: Header.
>> Sendmail then rewrites the To header and delivers it to procmail.
>> Procmail fires off SpamAssassin and since the To: header is possibly
>> changed, we then fail the DKIM validation.
> That's speculation without more evidence. It could well be that the case I described is happening at the client end where signing happens; the signer applies a "simple" mode signature and then the To: is folded to lowercase before it's handed off to the first relay; your end does no rewriting at all, but the signature is already dead-on-arrival because what went out over the wire isn't what got signed.
It's not speculation. I included the pre and post sendmail processed
copies of emails from Gmail in my original posting. The copy I receive
has a correct to: header and it is changed to the envelope data.
Attached is another copy of those examples.

>> I'm guessing that DKIM on the recipient side can't be configured to say
>> "ignore case changes on To:", can it?
> It would have to know the original case, and be able to tell the DKIM verifying engine to use that alternate form rather than what it actually received.
> If the signer (whatever it may be) can be configured to use "z=" tags, you can get to the bottom of this a little quicker because it will show you what got signed before any rewriting happened.
I have reverse engineered what was signed by editing the files and
checking with opendkim -t to see what case passes the validation.

> Sendmail evolved long before a time where case-folding mattered to anyone. I think that was part of the impetus for DKIM's development of "relaxed" mode. You should consider using it. Gmail uses "relaxed" mode for all mail, quite possibly because of this kind of thing.
The attached email IS from gmail and shows that it fails from the
rewrite of the To: Header with the Envelope Rcpt To: data. If this is
relaxed mode, either it isn't working or gmail isn't using it.


Received on Fri Dec 16 2011 - 01:19:11 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:20:22 PST