What happens with duplicate substitute headers?

Gary Mills mills@cc.umanitoba.ca
Thu Mar 18 21:07:32 UTC 2010

On Thu, Mar 18, 2010 at 03:49:27PM +0000, Vernon Schryver wrote:
> > From: Gary Mills 
> > The second one has a newline and a tab between the two lines.  I assume
> > that DCC will rejoin these lines somehow, but what do I specify as the
> > substitute header.  As well, they've changed the format of the header,
> > breaking all the checksums.  I'd have to re-list them all.
> As required by the SMTP standards, dccm, dccifd, and dccproc ignore
> "folding whitespace" including "\n\t" in headers.
> However, dccm, dccproc, and whiteclnt and dccd whitelist files
> use single lines.  Simply delete the newlines when copying the
> header lines to whiteclnt, whitelist, or whitecommon files.

And replace the `\n\t' with a single space, I presume.

> > More importantly, what is DCC going to do with the duplicate header
> > field names?  Will it just compute two checksums?  In that case, I
> > suppose it will all work.
> The checksums for a message are not checked against the client
> whiteclnt file and not sent to the DCC server to be checked against
> its whitelist file until the end of the message.  So the checksum of
> the last header of a set of duplicate headers is usually the only one
> that matters.

That certainly could be a problem.  As I was sending the original
message, I realized the envelope recipients could be multiples too,
and that DCC handles them somehow.  I thought then that there was no
problem with multiple header fields, but I see now that that's not so.

> Other, special arrangements are made for Received: headers.
> If the header you care about is not always the second of the pair, then
> I would modify your DKIM milter to generate a different header for one
> of them, such as X-Authentication-Results-2.

In reading the documentation for dkim-milter-2.8.3, I see that
Authentication-Results is a new standard e-mail header, defined in
RFC5451.  I suppose I could modify the code to generate a different
header for Domainkeys, but I'd only do that as an interim measure.

> Or fix the milter to pick one answer instead of equivocating.  In other
> words, generate only one Authentication-Results header.

That would be another interim modification.

> (X- headers are a standardized escape from the global, practically
> static list of standardized SMTP headers.)
> By the way, has the Authentication-Results header been standardized?
> http://www.google.com/search?q=Authentication-Results+smtp+site%3Aietf.org
> as well as your experience with conflicting headers suggests not.

Yes, Authentication-Results seems to be a new standard header.  Its
format is fairly complex when all the options are included.  For
example, the last part `x-dkim-adsp=none' is new.  According to
draft-ietf-dkim-ssp-10.txt, `dkim-adsp' indicates that IANA is
supposed to register e-mail servers, and `none' indicates that it has
no signing information.  There's also a reference to an open DKIM
reputation service at:


Using this service seems to be an experimental option for the milter.

> If
> not, then I wonder if your DKIM milter ought to be adding X- headers
> in any case.
> Does your milter delete any Authentication-Results headers that
> are already in incoming mail messages to foil games of the bad guys?

Yes, according to the RFC it's supposed to.  The milter is written by
the sendmail people, using their unique build system, so I assume it
follows the RFC.

-Gary Mills-        -Unix Group-        -Computer and Network Services-

More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.