Authentication-Results headers from the DKIM milter

Vernon Schryver
Tue Apr 13 17:09:10 UTC 2010

> From: Chris Aseltine <>

> > We have an opportunity here to determine the form of the 
> > `Authentication-Results' header so that it can be most useful to DCC. 
> > I'd like to do this right.
> I wonder if, because Vernon considers DKIM and its ilk to be "homeopathy", 
> that indeed, he just does not care...

That is not my view.  Whitelisting by DKIM is much the same as whitelisting
by SMTP client (mail sender) IP address.  You wouldn't whitelist all
IP addresses just as you wouldn't whitelist all X-Authentication-Results
headers.  In practice, IP client IP addresses are harder to forge than
DKIM.  (which are easier today, TCP sequence number or DNS games?)
It is reasonable to prefer DKIM to IP address when one or a few DKIM
signatures cover an organization that with SMTP clients at many IP
addresses or with IP addresses that change more frequently than its
DKIM signatures.

Consider the currently common reasonable (as opposed to original FUSSP
nonsense) use of SPF in which a mail receiver maintains its own white
(or somewhat white) list of domain names whose SPF records are used to
verify that mail from comes from the right IP addresses.
It's a lot easier to maintain a list of domain names whose SPF records
specify IP addresses to maintain the same list of IP addresses.

Gary Mills also wrote:

> >It's because the checksums need to be stable once I determine that a
> >message with a DKIM signature has an e-mail domain that I trust not to
> >send spam.  I can't just copy them indiscriminately because those
> >so-called e-mail marketing sites use signed messages too.  I want to
> >add them once to a file included in `whiteclnt' and not have to touch
> >them again.  If the header value changes in some minor way, the
> >checksums will no longer match.  

I strongly disagree with the idea of "add them once to a file ... and
not have to touch them again."  The idea of writing any authenticator
in stone raises red flags.  You *must* plan for key expirations and

Because X-Authentication-Results* headers are local and so not standardized,
I don't understand the idea of getting them right or just stable except
for a little while at some installations.  There wouldn't be much more
hope if they were standardized instead of locally defined and subject
local changes.  Because DCC doesn't decode DKIM headers except trivially
such as ignoring whitespace, any X-Authentication-Results header format
is as good as any other for DCC white- or blacklisting.  Any format is
as good for DCC as any other provided the header is constant for a given

So I recommend treating X-Authentication-Results like any other header
or envelope value.  Use the ones that tag mail you want to white- or
blacklist, but be prepared for changes in IP addresses, domain names,
DKIM keys, and the formats of X- headers added by your other milters.

As a matter of general sane design, I'd omit irrelevant details from
X-Authentication-Results headers.  Nothing outside the DKIM module cares
how many bits of key were used or which flavor of DKIM worked.  Outsiders
care only whether the DKIM module says the message is authentic.  The
question of what to do when DKIM, SPF, and other authenticators conflict
should be decided inside the mail authenticating module, along with how
many bits, which headers are covered by the signature, and the rest.
The DKIM module should report on its summer vacation in a log and not
an SMTP header.  However, nothing in DCC needs more than a header that
doesn't change on every message.

Vernon Schryver

More information about the DCC mailing list

Contact by mail or use the form.