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

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

> -----Original Message-----
> From: Kevin A. McGrail []
> Sent: Thursday, December 15, 2011 5:05 PM
> To: Murray S. Kucherawy
> Cc: Axb;
> Subject: Re: SA DKIM related bug 6462 - Possibly Gmail, Sendmail and/or Thunderbird related?
> Perhaps you think I work for Gmail where the email is being DKIM
> signed.

No, I'd have run into you by now if that were the case.

> So right now, based on testing, if I receive an email that is DKIM
> signed sent to a server running sendmail with envelope rcpt to: vs To:
> header case discrepancies, I can expect DKIM to fail unless the signer
> used relaxed canonicalized mode? What techniques and tools do I as a
> recipient have to work around this issue for SpamAssasin which is
> testing in a post sendmail delivery environment?

The client has no options that are considered valid here. If you're presented a blob of signed data and a signature, and the verification fails, that's all you know; you aren't told why. Did something change? If so, what? Perhaps I don't have the right key? You really don't know.

The only thing you could do is engage in some heuristics (e.g., shenanigans) about how to reconstruct what the original blob of text was. In DKIM's case, you have a few things you can try, but in the grand scheme of things they're just guesses and we discourage them.

The first is to take the "z=" field, if there is one, and reconstruct the original header field set that got signed. This is actually a useful way to figure out what changed, but use of it to conduct a second verification has always been discouraged. It's meant strictly as a diagnostic tool.

The second is to take a run at unraveling the damage by guessing at what may have changed. Knowing what you know now, you could try folding the To: domain to uppercase and repeating the test. You could build up a library of common changes that break "simple" canonicalization signatures. (That might actually be valuable for future DKIM development efforts, but let me be the first to say "NOT IT!".)

For "simple", even spacing matters. So this:

        To: foo <>, baz <>

...changing to this:

        To: foo <>, baz <>

...will invalidate a "simple" signature. And you'd have no idea why, because the space could've been removed anywhere, so you're guessing at where you need to try putting it back in, recomputing the hashes, re-testing the RSA verification, etc.

> It seems to me, that we should be recommending that large ISPs, such as
> Google, in light of this behavior with sendmail (including my tests
> spanning from 8.13.1 to 8.14.5, the latest version) should use relaxed
> canonicalized mode so that case-discrepancies on the To: header do not
> cause signature validation errors.

Gmail itself does use relaxed mode already, unless something recently changed, at least through the web interface. So I'm not sure why you're having this problem. Your submissions must be coming through some different path that uses "simple".

> Do the RFCs for email allow for case-sensitive emails? I didn't think
> they did but it could have changed and I never noticed. I would have
> thought that DKIM would have forced lc or uc on the signing and
> validating of the To: header, for example, to get around just these
> type of issues but I'm guessing things like non-english character set
> email addresses and the like made that not the case?

The only place I can think of where the RFCs care about case is to say that domain names are typically treated in a case-insensitive manner, but the local-part (the userid part of an email address) may or may not be, depending on the receiving system. As such, case in the local-part has to be treated as case-sensitive for comparisons, but not the rest.

> That's my thought as well. Sorry. I'm playing a lot of devil's
> advocate and greatly appreciate your feedback. This issue has taken me
> weeks to pin down.

No problem, happy to help.

Received on Fri Dec 16 2011 - 01:17:23 PST

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