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

From: Murray S. Kucherawy <>
Date: Thu, 15 Dec 2011 17:06:03 -0800

> -----Original Message-----
> From: Kevin A. McGrail []
> Sent: Thursday, December 15, 2011 4:48 PM
> To: Murray S. Kucherawy
> Cc: SM; Axb;
> Subject: Re: SA DKIM related bug 6462 - Possibly Gmail, Sendmail and/or Thunderbird related?
> 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'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.

> 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.

Note that my test of sendmail was done in submission mode. I didn't test it as a relay, e.g., from an outside SMTP source. You could make a case that sendmail is incorrect to do this rewrite if it's being done in all cases rather than limiting itself to the submission case, but you'd have to show that first.

> 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.

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.

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

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