DKIM, Sendmail and Feature(`nocanonify') - Was Re: SA DKIM related bug 6462 - Possibly Gmail, Sendmail and/or Thunderbird related?

From: Kevin A. McGrail <>
Date: Fri, 16 Dec 2011 13:15:12 -0500

>> In this case, I do know the key is correct because I've pinpointed
>> and had corroboration that Sendmail is the culprit changing the To:
>> header. I then reverse engineered the changes by having the
>> pre-sendmail processing file and figuring out what Sendmail was doing
>> by behavior. I could then edit the text and see that the signature
>> was indeed valid.
> In this case, yes. But I was speaking generally. You're trying to
> resolve what you claim is a systemic problem, so I'm responding in the
> general case.
Well, the plot is thinking a bit. In practical terms, David F Skoll
with Roaring Penguin knows more about e-mail related RFCs and the
innards of sendmail than anyone else I know.

I asked him about Sendmail possibly rewriting the To: header based on
the rcpt to: envelope data. His reply was VERY enlightening:

"Yes. It drives me crazy. Sendmail seems to think it's a good idea to
canonicalize addresses in headers. So to turn it off, you need to put
this in both and


> I did that, and I agree that sendmail is probably making the change at
> least in some cases. The question is why, and what to do about it.

I've played around with this setting from David on a live and a test
server. The real-world ramifications of using this feature are untested
and I haven't research more about what the feature actually does but I
can report it does resolve the issue and the Gmail emails I was
discussing are now passing as valid.

dnl testing nocanonify for DKIM wonkiness with rcpt to: and To: header

Based on some discussion on pros/cons of this feature, I have a feeling
it might be something that needs to be widely documented as a good
setting to add to your sendmail configuration.

>> I wouldn't even try that in a live implementation... All my research
>> to date tells me that this is a systemic issue with sendmail that
>> DKIM signers need to be aware of. In my opinion, it sounds like if
>> this information is validated, DKIM should consider changing the
>> default signature to relaxed coupled with a major recommendation to
>> use relaxed. Sendmail is a very big player and this is a very
>> real-world issue not just an edge case.
> Most signers use relaxed for the header mode already.
As noted, the gmail samples I provided used relaxed mode and the problem
still occurred.

>> The particular case I have pinned down is a user with an external MUA
>> using Gmail. I have not been able to reproduce the issue with
>> Gmail's web-based interface. I also spot checked my logs and had at
>> least 200 cases in 12 hours on a small server showing the issue to be
>> larger rather than smaller.
> I'll ask my contacts inside Gmail and see if they'll confirm this.
> Signing with relaxed header mode forces everything to lowercase, so
> merely changing "PCCC" to "pccc" is not enough to invalidate this
> signature. If what you say is true then something else is also
> changing to cause what you're seeing.
Well, while you can attack the validity of my analysis, conclusion, etc.
the samples I provided are verbatim copies from live conversations with
Google's Gmail and were reproduced ad nausea. And I hope the veracity
of their content and my work is not truly what you meant to question as
I worked on this issue for several weeks to try and pinpoint the issue.

I have also been able to reduplicate the problem by doing the following:

- Go into a gmail account
- Turn on Imap Access
- Configure Thunderbird (I'm using 8.0) using the Automatic Settings
- Send an email to something like
- Review the email when received and the Received header will likely
- If your sendmail has nocanonify feature, the To: Header will be intact
and DKIM will pass
- If your sendmail does not have the nocanonify feature, the To: Header
will be changed to matching the Received header. DKIM
will fail even though the signature appears to be marked c=relaxed/relaxed

There are likely going to be other ways to duplicate this issue. This
is just the first that I've definitively been able to reproduce. Thanks
to AXB, though, because he's sent me a lot of test messages trying to
allow me to duplicate the issue.

Received on Fri Dec 16 2011 - 18:15:25 PST

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