Re: [exim-dev] DKIM support

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