|
||
|
||
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?
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:
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”
Sponsored byIPv4.Global
Sponsored byRadix
Sponsored byWhoisXML API
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byVerisign
Sponsored byCSC
A World-Renowned Source for Internet Developments. Serving Since 2002.
This doesn’t mean that the essential concept of DomainKeys is broken, rather that more work is needed to account for problems like the one described here.
I agree. I originally wrote this piece for an IBM/Lotus Notes/Domino user audience and, clearly, there are issues that need to be addressed to make DomainKeys viable for such users.
I suspect the issue is more widespread however (incorporating many other sites relying on other popular proprietary email software which implements an SMTP MTA) and this, while not defeating the DomainKeys concept, may make widespread adoption problematic.
Ultimately it boils down to RFC compliance issues and these are often matters of some debate if not controversy.
If simple things like using EHLO, not HELO and offering a valid primary domain name as the EHLO phrase are so often flouted, how much more difficult will it be to encourage even a significant minority of email administrators to implement software that does not rewrite or reorder headers?
1. DomainKeys does not rely on headers being in a particular order.
2. DomainKeys lets the sender specify which headers to include in the calculation. So ones that are a problem can be left out.
3. DKeys also does a canonicalization of the data, to eliminate variances from transit. Alas, defining the right algorithm for this turns out to be very difficult.
I concur with Yakov. If there is an issue with Domino, there is an issue with Domino.
Anything responsible that can be done to reduce unsolicited email at the server level is going to have some hiccups due to the variety of SMTP handlers that are out there.
It is a feature, not a bug ;).
One issue is - when is Domino actually changing the headers? A normal domainkeys scenerio would be that cryptographic authentication would occur at receipt by the mailserver, before any headers were altered.
Also, there are plenty of good reasons why IBM might want to change Domino’s behavior. Just because a mail server (MTA) is RFC compliant doesn’t mean that it will support all of the functionality that its user’s desire. I have no doubt that if DomainKeys were to become popular, all the major MTAs would support it, regardless of 2821 and 2822.
The biggest barrier to adoption of useful anti-spam technology has been the efforts of a few diehards in the IETF to demand compliance with every previous mail standard, regardless of sense or utility. Standards need to evolve to face unforseen challenges. RFCs are not some sort of revealed truth.
Perhaps my mistake was in the title of this piece.
DomainKeys is not broken - indeed the theoretical concept is well founded. However there exist many practical obstacles to widespread adoption, one of which I have illustrated.
The issue here is not that of “demanding compliance with every previous mail standard, regardless of sense or utility”. It may be that such compliance, while widely ignored by user organisations and software suppliers, is actually needed. Specifically, if all MTA software really did what the standards appear to suggest (prepending all new headers and not rewriting old ones), the problem would be less severe.
As to the issue of canonicalization - DomainKeys does indeed implement this and mandates two algorithms, “simple” and “nofws”. Both of these would be broken by the sample headers in this article because neither anticipates reordering of headers or semantic changes to existing headers such as changing charset=US-ASCII to charset=“US-ASCII”.
Other changes are routinely made to messages in transit by all sorts of different software, for example automatic conversion between MIME types (8 bit MIME to quoted printable and so on).
While the issue may be easily addressed in open source MTA software, the widespread use particularly by corporate users of proprietary software cannot be ignored and modifying the behaviour of these systems will only happen when their suppliers (Microsoft, IBM and so on) sign up to DomainKeys. It seems that at least Microsoft is unlikely to do so because it is still pursuing Sender ID as its preferred sender verification solution.
Hmm. Re-arranging of the headers is taken care of by the “h=received:message-id:...” part of line -2. The whitespace changes are taken care of by the ‘nofws’ canonicalization. Thus, the only legitimate complaint in the article is that
Content-Type: text/plain; charset=US-ASCII
is changed to
Content-Type: text/plain; charset=“US-ASCII”
Does Lotus Domino enable forwarding? If not, this change affects exactly 0 people. If so, the change only affects those that use Lotus Domino as the border MTA and forward the mail to a DomainKey aware MTA. Sounds pretty unlikely to me.
As for Microsoft, CERN (the creators of the WWW), has released a DomainKey library for MS Exchange 2003. http://mmmservices.web.cern.ch/mmmservices/Antispam/DomainKeysLibrary.aspx