DKIM becomes more official

Vernon Schryver
Sun Oct 14 15:20:38 UTC 2007

> From: Gary Mills 

> We have thousands of users.  The most common e-mail from Ebay/Paypal
> is for new passwords or password changes.  These get rejected as bulk
> mail, which is confusing to our users.

If the DCC FUZ2 checksums of those messages are the same,
then you could add a line like 
    ok hex fuz2 xxxxxxxx yyyyyyyy zzzzzzzz wwwwwwww
to /var/dcc/whiteclnt to whitelist them.

Or talk John L into adding the lines to his list at
Then use the cron job /var/dcc/libexec/fetch-testmsg-whitelist to
regularly fetch his list, and add
    include testmsg-whitelist
to /var/dcc/whiteclnt to whitelist everything in the list.

> The only available source appears to be for dkim-milter.  I'm about to
> build this for sendmail-8.14.1.  I don't mind running another milter,
> in addition to dccm.  In fact, dkim-milter should be fairly
> lightweight.  It would have to run before dccm so that it could set
> macros, create headers, or something, that could be noticed by dccm.

If you
  - use a fairly recent version of sendmail so that the order you
     specify milters affects the order in which they are applied,
  - dkim-milter runs before dccm,
  - dkim-milter sets the sendmail macro ${dcc_isspam} to something
     useful as described in the dccm man page, and doesn't tell sendmail
     to do anything about mail,
  - you add the line following line descrived in the dcc man page to 
option -first
then you would have partial per-user control of dkim-milter.  It would
be only partial because users could only whitelist senders that might
otherwise be blocked by dkim-milter.

I do not know whether macros set by one milter are seen by others.  

> > DCC client code of several versions ago had hooks for third party
> > mechanisms.

> Are these necessary if the external code is another milter?  The part
> that I really need is the user control of rejection.  I don't want two
> different mechanisms, one for DCC-determined bulk mail, and another
> for DKIM verification.

That code included understanding lines in whiteclnt files like
    option xfilter-on
    option xfilter-off
so that individual users could choose to apply the third party mechanism
or not.

I guess it would not be too much work to add support for another 
sendmail macro and a whiteclnt switch for paying attention to it.
However, none of this would do anything for dccifd or dccproc.

Another tactic might work better.  If headers added by a sendmail milter
are seen by later milters, and if dkim-milter always deleted, replaced,
or added a X-dkim-milter:good, X-dkim-milter:bad, etc header, then dccm
could be controlled by individual whiteclnt file lines that white- or
blacklist based on X-dkim-milter headers.  A simple SMTP proxy that could
be used as a Postfix before-queue filter could be used with postfix+dccifd
and perhaps other MTAs.

The big question for me is whether later sendmail milters see earlier
milters' added or changed headers.  I think not, but I don't know,
and I'm too lazy try to read the code or write a test milter.

Vernon Schryver

More information about the DCC mailing list

Contact by mail or use the form.