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

From: Kevin A. McGrail <KMcGrail_at_PCCC.com>
Date: Thu, 15 Dec 2011 20:04:51 -0500

>> This is a big issue and major barrier to DKIM validation because if the
>> rcpt to: data is in a different case than the To: Header than I believe
>> DKIM is going to fail when sendmail uses to rcpt to: data to rewrite the
>> To: header.
> I haven't found this to be a major issue so far, having worked with DKIM and sendmail for many years now. The tools and techniques exist to work around it.
Perhaps you think I work for Gmail where the email is being DKIM
signed. I do not. I am working on the recipient end and largely
working to fix SpamAssassin so that the DKIM implementation works.

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?

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.
>> Is DKIM supposed to be using case sensitive information from the To:
>> Header?
> That's your choice as the signer. As I suggested in my last message, you could sign with "relaxed" canonicalized mode for the header, which would process it all after mapping to lowercase. That would render this rewrite harmless.
>
> You could also configure your DKIM signing agent not to sign the To: field at all, also making the rewrite harmless.
I'm not the signer, I'm the recipient...
>> Is Sendmail allowed to rewrite the To header?
> I think it depends on the context. If it's accepting the submission from you, it has a role that includes preparing your message for transport (RFC4409, RFC5321, RFC5598). One could argue that doing so includes normalizing the content in some ways, and maybe they feel that means wrapping To: field domains to lowercase for whatever reason. I would say at least that its fixing of improper quoting of header fields is perfectly valid in this context.
>
> On the other hand, if it's acting as a relay, it's not supposed to make any changes to the message whatsoever other than adding trace information.
>
> The unfortunate thing is that this rewriting happens after the point at which DKIM is performed in sendmail's case, automatically invalidating a signature that includes To: modifications if that signature covered the To: field. This isn't really sendmail's fault, but is an artifact of the way it and milter evolved.
I think my gut is telling me that Sendmail is at fault BUT I won't be
surprised if they are following an RFC that predates DKIM by a decade or
more and the DKIM standards failed to accommodate by allowing To: to be
case-sensitive.

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?

>> Are mail clients supposed to use a different case for To: headers than
>> for rcpt to: data?
> There's actually no relationship at all. One is the envelope, one is the content. They don't even need to contain overlapping sets of addresses. Moreover, DKIM never sees the envelope, so it doesn't matter what envelope changes occurred.
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.

Regards,
KAM
Received on Fri Dec 16 2011 - 01:05:02 PST