The recent testing by Gmail of DomainKeys affords an opportunity to look again at what the impact of it may be in any attempt to introduce a Domino addin to verify DomainKeys signatures.

I have here a sample of an email sent from Gmail and that same email after being delivered to the in-box of a Notes/Domino user who prefers MIME. There are differences which make DomainKeys a real problem at Domino shops (and, I suspect, others).

DomainKeys works by signing a message at the time it passes through a DomainKeys signing MTA using a private key. The public key required to verify the signature is published in DNS. Theoretically, all a receiving MTA has to do is parse the DomainKeys header, extract the signature and verify that the public key and signature match the signed part of the message. And there, in a nutshell, is your problem.

In order for this to work, the signed part of the message which includes all headers added to that message prior to being signed may not be altered in any way. It is very clear in my sample that the signed part of the message has been altered and this inevitably breaks the signature.

So, what changes are there?

• Extra headers have been added within the signed part of the message. These are X-MIMETrack (Domino), X-TM-AS-Product-Ver and X-TM-AS-Result (Trend ScanMail for Domino) and Expiry-Date (Domino).
• The order of existing headers has been altered. Content-Type preceded Content-Transfer-Encoding when the message was sent but follows it in the received message.
• One header (Content-Transfer-Encoding) has been rewritten as a multiline header where it was sent as a single line header. It contains white space that was not there originally.
• That rewritten header now has quotes around the charset value where there were no quotes when the message was sent.

Before the DomainKeys people cry “foul”, what do RFC2821 and RFC2822 say about headers? Specifically, what do they say about the prepending of headers and the rewriting of same?

RFC2821 - 3.8.2 Received Lines in Gatewaying

When forwarding a message into or out of the Internet environment, a gateway MUST prepend a Received: line, but it MUST NOT alter in any way a Received: line that is already in the header.

RFC2822 - 3.6. Field definitions

... It is important to note that the header fields are not guaranteed to be in a particular order. They may appear in any order, and they have been known to be reordered occasionally when transported over the Internet. However, for the purposes of this standard, header fields SHOULD NOT be reordered when a message is transported or transformed. More importantly, the trace header fields and resent header fields MUST NOT be reordered, and SHOULD be kept in blocks prepended to the message.

Pretty assertive stuff. So far, so good. But:

RFC2821 - 3.8.1 Header Fields in Gatewaying

Header fields MAY be rewritten when necessary as messages are gatewayed across mail environment boundaries.

At best this is ambiguous. The only MUST is in relation to Received headers and Domino observes this requirement faithfully. If the Domino server is a gateway (and for the purposes of RFC2821 it is), then reordering of headers is permitted. Even if it is not a gateway, the ban on rewriting or reordering headers is not absolute - it says SHOULD NOT, not MUST NOT.

Bottom line. Unless IBM/Lotus makes some fundamental changes to Domino’s behaviour, DomainKeys is a non-starter for Domino shops. And there is no reason why IBM/Lotus should do this as it is arguable that Domino is RFC correct as it stands.

Sample headers, before and after

Green

- prepended; OK.

Red

- reordered/not prepended; problem.

# As sent
0  Received: by 10.38.75.59 with HTTP; Tue, 19 Oct 2004 01:02:12 -0700 (PDT)
1  Message-ID:

< [email protected] >

2  Date: Tue, 19 Oct 2004 09:02:12 +0100
3  From: Sender

< someguy[at]gmail.com >

4  Reply-To: Sender

< someguy[at]gmail.com >

5  To: Me

< me[at]myplace >

6  Subject: Whatever
7  Mime-Version: 1.0
8  Content-Type: text/plain; charset=US-ASCII
9  Content-Transfer-Encoding: 7bit

# As received

-4

Received: from mproxy.gmail.com ([64.233.170.205]) by my.domino.host (Lotus Domino Release 6.5.2) with ESMTP id 2004101909021401-8442 ; Tue, 19 Oct 2004 09:02:14 +0100

-3

Received: by mproxy.gmail.com with SMTP id 77so279036rnk for

; Tue, 19 Oct 2004 01:02:12 -0700 (PDT)

-2

DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id📅from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=[DomainKeysHash]

-1

Received: by 10.38.14.9 with SMTP id 9mr1205201rnn; Tue, 19 Oct 2004 01:02:12 -0700 (PDT)
0 Received: by 10.38.75.59 with HTTP; Tue, 19 Oct 2004 01:02:12 -0700 (PDT)
1  Message-ID:

< 1d3c4bad0410190102844e41c[at]mail.gmail.com >

2  Date: Tue, 19 Oct 2004 09:02:12 +0100
3  From: Sender

< someguy[at]gmail.com >

4  Reply-To: Sender

< someguy[at]gmail.com >

5  To: Me

< me[at]myplace >

6  Subject: Whatever
7  Mime-Version: 1.0

10

X-MIMETrack: Itemize by SMTP Server on MyDominoServer/Mydomain (Release 6.5.2|June 01, 2004) at 19/10/2004 09:02:14, Serialize by Notes Client on Me/Mydomain(Release 6.5.2|June 01, 2004) at 19/10/2004 09:04:07, Serialize complete at 19/10/2004 09:04:07

11

X-TM-AS-Product-Ver:

-

<3.0.1.3011>

-

<1.25.1015>

-

<12893>

12

X-TM-AS-Result:

-

<0.000>

-

<7.0>

-

<99000>

13

Expiry-Date:

9

Content-Transfer-Encoding: 7bit

8

Content-Type: text/plain;
charset=“US-ASCII”