Mailing List Archive

On fredagen den 28 september 2007, Tom Kistner wrote:
> I have added preliminary DKIM support to Exim in CVS. If anyone feels
> adventurous, please try these 2 tarballs:
>
> http://duncanthrax.net/exim-experimental/exim-4.69-cvssnap-2007-09-28.tar.g
>z http://duncanthrax.net/exim-experimental/libdkim-1.0.15-tk.tar.gz
>
> The former is a current CVS snapshot of Exim. The latter is a forked
> version of ALT-N's libdkim that you will need to install.
>
> I've put docs in exim-experimental.spec and also here:
>
> http://wiki.exim.org/DKIM

Debian users can install libdkim0 and specify just

EXPERIMENTAL_DKIM=yes
LDFLAGS += -ldkim

... I hope. How much did you fork it?

--
Magnus Holmgren holmgren@lysator.liu.se
(No Cc of list mail needed, thanks)

Magnus Holmgren wrote:

> Debian users can install libdkim0 and specify just
>
> EXPERIMENTAL_DKIM=yes
> LDFLAGS += -ldkim
>
> ... I hope. How much did you fork it?

I added two items to the struct it returns for verification details, so
I'm afraid this will not work. Yet. I'll see if I can work with Alt-N to
get these (and more) changes incorporated into mainline libdkim.

/tom



--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

On fredagen den 28 september 2007, Tom Kistner wrote:
> I have added preliminary DKIM support to Exim in CVS. If anyone feels
> adventurous, please try these 2 tarballs:
>
> http://duncanthrax.net/exim-experimental/exim-4.69-cvssnap-2007-09-28.tar.g
>z http://duncanthrax.net/exim-experimental/libdkim-1.0.15-tk.tar.gz
>
> The former is a current CVS snapshot of Exim. The latter is a forked
> version of ALT-N's libdkim that you will need to install.
>
> I've put docs in exim-experimental.spec and also here:
>
> http://wiki.exim.org/DKIM

Interesting solution with ${lookup dkim{domain.example}}. I'm not sure I like
it though. No other lookup depends on a current message as context. Couldn't
it be done with verify = dkim/domain.example, and the result is an expansion
variable? It should be possible to specify a full email address, with the
default value being ${address:$rh_From:}.

Also, I'd like a simple way to get a list of signatures, so you know what you
can check. And have you thought about what I wrote about Third-party
Signatures? The idea is that you provide Exim with a list of trusted signers,
who can certify that an earlier signature was valid when they checked it. For
Exim to play its part in this, it must delete all invalid signatures before
adding its own. Does your code do this?

--
Magnus Holmgren holmgren@lysator.liu.se
(No Cc of list mail needed, thanks)

On fredagen den 28 september 2007, Tom Kistner wrote:
> Magnus Holmgren wrote:
> > Debian users can install libdkim0 and specify just
> >
> > EXPERIMENTAL_DKIM=yes
> > LDFLAGS += -ldkim
> >
> > ... I hope. How much did you fork it?
>
> I added two items to the struct it returns for verification details, so
> I'm afraid this will not work. Yet. I'll see if I can work with Alt-N to
> get these (and more) changes incorporated into mainline libdkim.

So if I'm not mistaken, ignoring the issue of building on Linux (I solved
that in a more minimal way, so to speak) and the nowsp compatibility
canonicalization code, it all boils down to the following?

diff -w -xdebian -ur libdkim-1.0.14/src/dkim.h libdkim-1.0.15-tk/src/dkim.h
--- libdkim-1.0.14/src/dkim.h 2007-05-03 17:53:09.000000000 +0200
+++ libdkim-1.0.15-tk/src/dkim.h 2007-09-28 13:08:04.000000000 +0200
@@ -137,6 +137,8 @@
{
char *szSignature;
char *DNS;
+ char *Domain;
+ char *IdentityDomain;
int nResult;
} DKIMVerifyDetails;

diff -w -xdebian -ur libdkim-1.0.14/src/dkimverify.cpp libdkim-1.0.15-tk/src/dkimverify.cpp
--- libdkim-1.0.14/src/dkimverify.cpp 2007-04-24 11:01:58.000000000 +0200
+++ libdkim-1.0.15-tk/src/dkimverify.cpp 2007-09-28 08:05:01.000000000 +0200
@@ -1428,6 +1386,11 @@
DKIMVerifyDetails d;
d.szSignature = (char*)i->Header.c_str();
d.nResult = i->Status;
+
+ d.Domain = (char*)i->Domain.c_str();
+ d.IdentityDomain = i->IdentityDomain.empty()?(char*)i->IdentityDomain.c_str():(char*)i->Domain.c_str();
+
Details.push_back(d);
}

--
Magnus Holmgren holmgren@lysator.liu.se
(No Cc of list mail needed, thanks)

On fredagen den 28 september 2007, Tom Kistner wrote:
> Magnus Holmgren wrote:
> > Debian users can install libdkim0 and specify just
> >
> > EXPERIMENTAL_DKIM=yes
> > LDFLAGS += -ldkim
> >
> > ... I hope. How much did you fork it?
>
> I added two items to the struct it returns for verification details, so
> I'm afraid this will not work. Yet. I'll see if I can work with Alt-N to
> get these (and more) changes incorporated into mainline libdkim.

Good luck, by the way. I complained about the windowsisms and the broken
Makefile in February, and still haven't got any response.

This is the patch I use:

--- libdkim-1.0.14.orig/src/dkim.h
+++ libdkim-1.0.14/src/dkim.h
@@ -18,7 +18,12 @@
#ifdef WIN32
#define DKIM_CALL WINAPI
#else
+#include <inttypes.h>
#define DKIM_CALL
+#define MAKELONG(low,high) \
+ ((uint32_t)(((uint16_t)(low))|((uint32_t)(((uint16_t)(high))<<16))))
+#define HIWORD(l) ((uint16_t) (((uint32_t) (l) >> 16) & 0xFFFF))
+#define LOWORD(l) ((uint16_t) (l))
#endif


-------------EOF--------------

(It's probably broken due to the CRs in their files.)

--
Magnus Holmgren holmgren@lysator.liu.se

Magnus Holmgren wrote:

> So if I'm not mistaken, ignoring the issue of building on Linux (I solved
> that in a more minimal way, so to speak) and the nowsp compatibility
> canonicalization code, it all boils down to the following?

Yeah thats it. Just the bare minimum we need to look up a result by
domain (or identity, and even that is conflated right now). The problem
is that the lib already tries to make a decision. We just want all the
relevant info (results, policies) handed back to Exim and roll our own
decision-making logic in Exim ACL "language".

The lib itself is OK - nice small footprint. Just the verification
result API needs to be further extended. Signing looks OK as it is now.

/tom



> diff -w -xdebian -ur libdkim-1.0.14/src/dkim.h libdkim-1.0.15-tk/src/dkim.h
> --- libdkim-1.0.14/src/dkim.h 2007-05-03 17:53:09.000000000 +0200
> +++ libdkim-1.0.15-tk/src/dkim.h 2007-09-28 13:08:04.000000000 +0200
> @@ -137,6 +137,8 @@
> {
> char *szSignature;
> char *DNS;
> + char *Domain;
> + char *IdentityDomain;
> int nResult;
> } DKIMVerifyDetails;
>
> diff -w -xdebian -ur libdkim-1.0.14/src/dkimverify.cpp libdkim-1.0.15-tk/src/dkimverify.cpp
> --- libdkim-1.0.14/src/dkimverify.cpp 2007-04-24 11:01:58.000000000 +0200
> +++ libdkim-1.0.15-tk/src/dkimverify.cpp 2007-09-28 08:05:01.000000000 +0200
> @@ -1428,6 +1386,11 @@
> DKIMVerifyDetails d;
> d.szSignature = (char*)i->Header.c_str();
> d.nResult = i->Status;
> +
> + d.Domain = (char*)i->Domain.c_str();
> + d.IdentityDomain = i->IdentityDomain.empty()?(char*)i->IdentityDomain.c_str():(char*)i->Domain.c_str();
> +
> Details.push_back(d);
> }
>
>


--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

On 2007-09-28 at 16:22 +0200, Magnus Holmgren wrote:
> On fredagen den 28 september 2007, Tom Kistner wrote:
> > I have added preliminary DKIM support to Exim in CVS. If anyone feels
> > adventurous, please try these 2 tarballs:
> >
> > http://duncanthrax.net/exim-experimental/exim-4.69-cvssnap-2007-09-28.tar.g
> >z http://duncanthrax.net/exim-experimental/libdkim-1.0.15-tk.tar.gz
> >
> > The former is a current CVS snapshot of Exim. The latter is a forked
> > version of ALT-N's libdkim that you will need to install.
> >
> > I've put docs in exim-experimental.spec and also here:
> >
> > http://wiki.exim.org/DKIM
>
> Interesting solution with ${lookup dkim{domain.example}}. I'm not sure I like
> it though. No other lookup depends on a current message as context. Couldn't
> it be done with verify = dkim/domain.example, and the result is an expansion
> variable? It should be possible to specify a full email address, with the
> default value being ${address:$rh_From:}.

Having just looked at how to configure this sensibly, I support Magnus's
suggestion wholeheartedly.

Separately, I've just tried deploying DKIM with Exim 4.69; I settled for
signing outbound first before looking at verifying inbound. I opted to
DKIM sign in addition to DomainKey sign, to get the maximum
verifiability -- the union of the two groups of verifiers. This is what
Gmail does on outbound email.

Alas, Exim does not support signing with both DomainKeys and DKIM.
Three different transport methods, so it's DomainKeys, else DKIM, else
plain.

Is this a deliberate design decision, a temporary result of an early
experimental convenience (not having to rework logic) or a bug?

Thanks,
-Phil

On 2007-12-30 at 00:56 -0800, Phil Pennock wrote:
> Separately, I've just tried deploying DKIM with Exim 4.69; I settled for
> signing outbound first before looking at verifying inbound. I opted to
> DKIM sign in addition to DomainKey sign, to get the maximum
> verifiability -- the union of the two groups of verifiers.

I should have mentioned the other part of my reasoning: I have published
DNS records saying that I sign all outbound mail with DomainKeys
(testing); some sites may be filtering on that, with exceptions for
mailing-list headers, despite the testing flag. A weighted score input.

So switching from DomainKeys to DKIM as an either/or involves removing
the _domainkey DNS record, waiting >> TTL for all the caches to flush
(ie, at least a day anyway given some of the "interesting" caching
policies out there), then withdrawing DomainKeys signing from Exim,
adding in DKIM and only then publishing DKIM records.

This is in the optimistic case that the recipient domain doesn't have a
reputation system keeping track of "this domain is known to use DK/DKIM
so if they stop advertising in DNS, suspect a DNS attack and do X" where
X is either flag it as a security error or keep using the last
remembered DNS value -- a approach with arguments for and against how
reasonable it is. In other words: once you start signing, you need to
keep signing.

So the safest approach to transition from DomainKeys to DKIM is to
dual-sign for the interim. After DKIM is stable, update DNS records and
later still stop signing with DomainKeys. The interim period needs to
be long enough for the DomainKeys MTAs to "mostly" move to supporting
DKIM; anyone working with a caching sender reputation system that
remembers "does sign" and who doesn't migrate to DKIM within a period T
will have a hard time arguing that the fault is that of the sender. I
suspect that T is probably until about a year after stable
DKIM-supporting releases of the MTAs making up most of the Internet's MX
MTAs, sooner if they all have security issues to act as a forcing
function on upgrading. ;-) Longer if OS packagers can't be persuaded
to upgrade the version of the MTA in their stable packages.

> Is this a deliberate design decision, a temporary result of an early
> experimental convenience (not having to rework logic) or a bug?

I'll argue that whichever it is, it is also a mis-feature.

Besides presenting a use-case and rationale, as I've just done, what can
I do to help?

-Phil

Phil Pennock schrieb:

> I'll argue that whichever it is, it is also a mis-feature.

Right. The "problem" is in the way how signing is implemented in the
transport (redirecting the SMTP DATA output stream to an extra fd).
While it would be possible to chain both functions, performance would
really suffer. I'd need to merge both functions and calculate both
hashes at the same time. I can't promise any progress before end of
next week though.

> Besides presenting a use-case and rationale, as I've just done, what can
> I do to help?

Play the guinea pig with a tarball that I'll send over. :)

/tom

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

>> I'll argue that whichever it is, it is also a mis-feature.
>
> Right. The "problem" is in the way how signing is implemented in the
> transport (redirecting the SMTP DATA output stream to an extra fd).
> While it would be possible to chain both functions, performance would
> really suffer. I'd need to merge both functions and calculate both
> hashes at the same time. I can't promise any progress before end of
> next week though.
>
>> Besides presenting a use-case and rationale, as I've just done, what can
>> I do to help?
>
> Play the guinea pig with a tarball that I'll send over. :)

OK, it took me a bit longer. I've put code in CVS that enables
concurrent Domainkeys and DKIM signing. Here's a snapshot tarball:

http://duncanthrax.net/exim-experimental/exim-cvssnap-2008-03-05.tar.gz

/tom


--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##