opendkim(8)       (The Trusted Domain Project)        opendkim(8)

          opendkim - DKIM signing and verifying filter for MTAs

          opendkim [-A] [-b modes] [-c canon] [-d domain[,...]]  [-D]
          [-e name] [-f] [-F time] [-k keyfile] [-l] [-L min] [-n] [-o
          hdrlist] [-p socketspec] [-P pidfile] [-Q] [-r] [-s selec-
          tor] [-S signalg] [-t testfiles] [-T secs] [-u
          userid[:group]] [-v] [-V] [-W] [-x configfile] [-X]

          opendkim implements the DKIM standard for signing and veri-
          fying e-mail messages on a per-domain basis.

          opendkim uses the milter interface, originally distributed
          as part of version 8.11 of sendmail(8), to provide DKIM
          signing and/or verifying service for mail transiting a
          milter-aware MTA.

          Most, if not all, of the command line options listed below
          can also be set using a configuration file.  See the -x
          option for details.

          Many of the command line and configuration file parameters
          will refer to a "dataset" as their values.  This refers to a
          string that either contains the list of desirable values, or
          to a file that contains them, or (if enabled at compile
          time) a database containing the data.

          Some data sets require that the value contain more than one
          entry.  How this is done depends on which data set type is

          Which type is used depends on the format of the specifica-
          tion string.  Note that not all of these are necessarily
          supported for all installations; most of them depend on the
          availability of a particular third-party library at compile

          In particular:

          a)   If the string begins with "file:", then the remainder
               of the string is presumed to refer to a flat file that
               contains elements of the data set, one per line.  If a
               line contains whitespace-separated values, then the
               line is presumed to define a key and its corresponding
               value.  Blank lines are ignored, and the hash ("#")
               character denotes the start of a comment.  If a value
               contains multiple entries, the entries should be

     Page 1                       Plan 9             (printed 5/23/22)

     opendkim(8)       (The Trusted Domain Project)        opendkim(8)

               separated by colons.

          b)   If the string begins with "refile:", then the remainder
               of the string is presumed to specify a file that con-
               tains a set of patterns, one per line, and their asso-
               ciated values.  The pattern is taken as the start of
               the line to the first whitespace, and the portion after
               that whitespace is taken as the value to be used when
               that pattern is matched.  Patterns are simple wildcard
               patterns, matching all text except that the asterisk
               ("*") character is considered a wildcard.  If a value
               contains multiple entries, the entries should be sepa-
               rated by colons.

          c)   If the string begins with "db:" and the program was
               compiled with Sleepycat DB support, then the remainder
               of the string is presumed to identify a Sleepycat data-
               base containing keys and corresponding values.  These
               may be used only to test for membership in the data
               set, or for storing keys and corresponding values.  If
               a value contains multiple entries, the entries should
               be separated by colons.

          d)   If the string begins with "dsn:" and the OpenDKIM
               library was compiled to support that database type,
               then the remainder of the string is a Data Store Name
               describing the type, location parameters and access
               credentials for an ODBC or SQL database.  The DSN is of
               the form:


               where backend is the name of a supported backend data-
               base mechanism (e.g. "mysql"), user and password are
               optional login credentials for the database, port and
               host describe the destination of a TCP connection to
               connect to that database, dbase is the name of the
               database to be accessed, and the key=value pairs must
               specify at least "table", "keycol" and "datacol" values
               specifying the name of the table, the name of the col-
               umn to consider as the key, and the name(s) of the
               column(s) to be considered as the values (separated by
               commas).  For example (all in one line):


               defines a MySQL database listening at port 3306 on host
               "dbhost"; the userid "dbuser" and password "dbpass"
               should be used to access the database; the database
               name is "odkim", and the data are in columns "host"
               (the keys) and "v1" and "v2" (the values) inside table

     Page 2                       Plan 9             (printed 5/23/22)

     opendkim(8)       (The Trusted Domain Project)        opendkim(8)

               "macros".  This example would thus return two values
               when a match is found.

               The key may also include a "filter" value which will be
               included in all generated SQL as an AND clause after
               the WHERE clause that declares the search criteria.
               For example, given the above DSN specification with an
               additional "filter" value of "ID > 1000", the generated
               SQL for a query for "foo" would look like so:

               SELECT v1,v2 FROM macros WHERE host = 'foo' AND ID >

               No value within the DSN may contain any of the six
               punctuation characters (":", "/", "@", "+", "?" and
               "=") used to delimit portions of the DSN.  To include
               such characters within a value, encode them in quoted-
               printable style (e.g., "=20" will be translated into a
               single space character).  Encoding of spaces is also

          e)   If the string begins with "ldap:", "ldaps:" or
               "ldapi:", it is presumed to be a space-separated set of
               one or more LDAP URLs that identify a set of servers to
               be queried.  The first one should be a full RFC4516
               LDAP URL indicating a base DN template and optional
               scope, filter and attribute names to use in queries.
               When constructing a DN template or filter, the special
               tokens "$d" and "$D" are replaced with the key being
               queried and the key broken into components, separated
               at "." characters, each component preceded by "dc=" and
               followed by "," (so "" would become
               "dc=example,dc=com").  If a data set requires multiple
               values to be returned, the appropriate attribute names
               should be given in the correct order to satisfy such

          f)   If the string begins with "lua:", it is presumed to
               refer to a file that contains a Lua script to be exe-
               cuted whenever a query is performed.  The key for the
               query is placed in a global variable called "query",
               which the called script can then access.  The script
               may return any number of values as required for the
               type of query being performed.

          g)   If the string begins with "memcache:", it is presumed
               to refer to a memory cache database provided by
               memcached. The remainder of the string is a comma-
               separated list of hosts to which query attempts should
               be made, each optionally followed by ":" and a port
               number; that list must be followed by a slash ("/")
               character and a string that will be used to prefix

     Page 3                       Plan 9             (printed 5/23/22)

     opendkim(8)       (The Trusted Domain Project)        opendkim(8)

               queries send to the cache.  For example:


               This would use either "localhost" or "otherhost" to
               conduct queries, and all strings sent to the dataset
               will be prefixed with "keyname:".

          h)   If the string contains none of these prefixes but ends
               with ".db", it is presumed to be a Sleepycat DB as
               described above (if support for same is compiled in).

          i)   If the string contains none of these prefixes but
               starts with a slash ("/") character, it is presumed to
               be a flat file as described above.

          j)   If the string begins with "csl:", the string is treated
               as a comma-separated list as described in m) below.

          k)   If the string begins with "erlang:", it is presumed to
               refer to a function called to be made to the specified
               distributed Erlang node(s). The specification is of the


               where node[,...] is a list of comma-separated erlang
               nodes, cookie is the cookie for the known nodes of the
               distributed Erlang setup, module is the name of the
               Erlang module where the function to be called resides,
               function is the name of the Erlang function to be
               called. For example, (all in one line):


               will join the distributed Erlang setup connecting to
               either "mynode@myhost" or "myothernode@myotherhost"
               (connections to nodes are tried in order) using "choco-
               late" as the cookie, and use the function
               "dkim:lookup/1" for lookups.

          l)   If the string begins with "mdb:", it refers to a direc-
               tory that contains a memory database, as provided by
               libmdb from OpenLDAP.

          m)   In any other case, the string is presumed to be a
               comma-separated list.  Elements in the list are either
               simple data elements that are part of the set or, in
               the case of an entry of the form "x=y", are stored as
               key-value pairs as described above.

     Page 4                       Plan 9             (printed 5/23/22)

     opendkim(8)       (The Trusted Domain Project)        opendkim(8)

          -A   Automatically re-start on failures.  Use with caution;
               if the filter fails instantly after it starts, this can
               cause a tight fork(2) loop.  This can be mitigated
               using some values in the configuration file to limit
               restarting.  See opendkim.conf(5).

          -b modes
               Selects operating modes.  modes is a concatenation of
               characters that indicate which mode(s) of operation are
               desired.  Valid modes are s (signer) and v (verifier).
               The default is sv except in test mode (see -t below) in
               which case the default is v.

          -c canon
               Selects the canonicalization method(s) to be used when
               signing messages.  When verifying, the message's DKIM-
               Signature: header specifies the canonicalization
               method.  The recognized values are relaxed and simple
               as defined by the DKIM specification.  The default is
               simple. The value may include two different canonical-
               izations separated by a slash ("/") character, in which
               case the first will be applied to the headers and the
               second to the body.

          -d dataset
               A set of domains whose mail should be signed by this
               filter.  Mail from other domains will be verified
               rather than being signed.

          -D   Sign subdomains of those listed by the -d option as
               well as the actual domains.

          -e name
               Extracts the value of name from the configuration file
               (if any).

          -f   Normally opendkim forks and exits immediately, leaving
               the service running in the background.  This flag sup-
               presses that behaviour so that it runs in the fore-

          -F time
               Specifies a fixed time to use when generating signa-
               tures.  Ignored unless also used in conjunction with -t
               (see below).  The time must be expressed in the usual
               UNIX time_t (seconds since epoch) format.

          -k keyfile
               Gives the location of a PEM-formatted private key to be
               used for signing all messages.  Ignored if a configura-
               tion file is referenced that defines a KeyTable.

     Page 5                       Plan 9             (printed 5/23/22)

     opendkim(8)       (The Trusted Domain Project)        opendkim(8)

          -l   Log via calls to syslog(3) any interesting activity.

          -L min[%+]
               Instructs the verification code to fail messages for
               which a partial signature was received.  There are
               three possible formats: min indicating at least min
               bytes of the message must be signed (or if the message
               is smaller than min then all of it must be signed);
               min% requiring that at least min percent of the
               received message must be signed; and min+ meaning there
               may be no more than min bytes of unsigned data appended
               to the message for it to be considered valid.

          -n   Parse the configuration file and command line argu-
               ments, reporting any errors found, and then exit.  The
               exit value will be 0 if the filter would start up with-
               out complaint, or non-zero otherwise.

          -o dataset
               Specifies a list of headers that should be omitted when
               generating signatures.  If an entry in the list names
               any header which is mandated by the DKIM specification,
               the entry is ignored.  A set of headers is listed in
               the DKIM specification as "SHOULD NOT" be signed; the
               default list for this parameter contains those headers
               (Return-Path, Received, Comments, Keywords, Bcc,
               Resent-Bcc and DKIM-Signature).  To omit no headers,
               simply use the string "-" (or any string that will
               match no headers).

          -p socketspec
               Specifies the socket that should be established by the
               filter to receive connections from sendmail(8) in order
               to provide service.  socketspec is in one of two forms:
               local:path which creates a UNIX domain socket at the
               specified path, or inet:port[@host] or
               inet6:port[@host] which creates a TCP socket on the
               specified port using the requested protocol family.  If
               the host is not given as either a hostname or an IP
               address, the socket will be listening on all inter-
               faces.  A literal IP address must be enclosed in square
               brackets.  If neither socket type is specified, local
               is assumed, meaning the parameter is interpreted as a
               path at which the socket should be created.  This
               parameter is mandatory either here or in the configura-
               tion file.

          -P pidfile
               Specifies a file into which the filter should write its
               process ID at startup.

          -Q   Query test mode.  The filter will read two lines from

     Page 6                       Plan 9             (printed 5/23/22)

     opendkim(8)       (The Trusted Domain Project)        opendkim(8)

               standard input, one containing a database description
               to be opened and one containing a string of the form
               "q/n" where "q" is the query to be performed and "n" is
               the number of fields to be retrieved.

          -r   Checks all messages for compliance with RFC5322 header
               count requirements.  Non-compliant messages are

          -s selector
               Defines the name of the selector to be used when sign-
               ing messages.  See the DKIM specification for details.

          -S signalg
               Selects the signing algorithm to use when generating
               signatures.  Use 'opendkim -V' to see the list of sup-
               ported algorithms.  The default is rsa-sha256 if it is
               available, otherwise it will be rsa-sha1.

          -t testfiles
               Evaluates (verifies) one or more RFC5322-formatted mes-
               sage found in testfiles and exits.  The value of
               testfiles should be a comma-separated list of one or
               more filenames, one of which may be "-" if the message
               should be read from standard input.

          -T secs
               Sets the DNS timeout in seconds.  A value of 0 causes
               an infinite wait.  The default is 5.  Ignored if not
               using an asynchronous resolver package.  See also the
               NOTES section below.

          -u userid[:group]
               Attempts to be come the specified userid before start-
               ing operations.  The process will be assigned all of
               the groups and primary group ID of the named userid
               unless an alternate group is specified.  See the FILE
               PERMISSIONS section for more information.

          -v   Increase verbose output during test mode (see -t
               above).  May be specified more than once to request
               increasing amounts of output.

          -V   Print the version number and supported canonicalization
               and signature algorithms, and then exit without doing
               anything else.

          -W   If logging is enabled (see -l above), issues very
               detailed logging about the logic behind the filter's
               decision to either sign a message or verify it.  The
               "W" stands for "Why?!"  since the logic behind the

     Page 7                       Plan 9             (printed 5/23/22)

     opendkim(8)       (The Trusted Domain Project)        opendkim(8)

               decision is non-trivial and can be confusing to admin-
               istrators not familiar with its operation.  A descrip-
               tion of how the decision is made can be found in the
               OPERATION section of this document.  This causes a
               large increase in the amount of log data generated for
               each message, so it should be limited to debugging use
               and not enabled for general operation.

          -x configfile
               Read the named configuration file.  See the
               opendkim.conf(5) man page for details.  Values in the
               configuration file are overridden when their equiva-
               lents are provided on the command line until a configu-
               ration reload occurs.  The OPERATION section describes
               how reloads are triggered.  The default is to read a
               configuration file from /etc/opendkim.conf if one
               exists, or otherwise to apply defaults to all values.

          -X   Tolerates configuration file items that have been
               internally marked as "deprecated".  Normally when a
               configuration file item is removed from the package, it
               is flagged in this way for at least one full release
               cycle.  The presence of a deprecated configuration file
               item typically causes the filter to return an error and
               refuse to start.  Setting this flag will allow the fil-
               ter to start and a warning is logged.  In some future
               release when the item is removed completely, a differ-
               ent error results, and it will not be possible to start
               the filter.  Use of this flag is NOT RECOMMENDED; it
               could effectively hide a major configuration change
               with serious security implications.

          A message will be verified unless it conforms to the signing
          criteria, which are: (1) the domain on the From: address (if
          present) must be listed by the -d command line switch or the
          Domain configuration file setting, and (2) (a) the client
          connecting to the MTA must have authenticated, or (b) the
          client connecting to the MTA must be listed in the file ref-
          erenced by the InternalHosts configuration file setting (or
          be in the default list for that option), or (c) the client
          must be connected to a daemon port named by the MTAs config-
          uration file setting, or (d) the MTA must have set one or
          more macros matching the criteria set by the MacroList con-
          figuration file setting.

          For (a) above, the test is whether or not the MTA macro
          "{auth_type}" is set and contains any non-empty value.  This
          means the MTA must pass the value of that macro to the fil-
          ter before or during the end-of-header (EOH) phase in order
          for its value to be tested.  Check your MTA's configuration
          documentation for details.

     Page 8                       Plan 9             (printed 5/23/22)

     opendkim(8)       (The Trusted Domain Project)        opendkim(8)

          For (1) above, other header fields may be selected using the
          SenderHeaders configuration file setting.  See
          opendkim.conf(5) for more information.

          When signing a message, a DKIM-Signature: header will be
          prepended to the message.  The signature is computed using
          the private key provided.  You must be running a version of
          sendmail(8) recent enough to be able to do header prepend
          operations (8.13.0 or later).

          When verifying a message, an Authentication-Results: header
          will be prepended to indicate the presence of a signature
          and whether or not it could be validated against the body of
          the message using the public key advertised by the sender's
          nameserver.  The value of this header can be used by mail
          user agents to sort or discard messages that were not signed
          or could not be verified.

          Upon receiving SIGUSR1, if the filter was started with a
          configuration file, it will be re-read and the new values
          used.  Note that any command line overrides provided at
          startup time will be lost when this is done.  Also, the fol-
          lowing configuration file values (and their corresponding
          command line items, if any) are not reloaded through this
          process: AutoRestart (-A), AutoRestartCount, AutoRestar-
          tRate, Background, MilterDebug, PidFile (-P), POPDBFile,
          Quarantine (-q), QueryCache, Socket (-p), StrictTestMode,
          TestPublicKeys, UMask, UserID (-u).  The filter does not
          automatically check the configuration file for changes and

          opendkim makes use of three MTA-provided macros, plus any
          demanded by configuration.  The basic three are: "i" (the
          envelope ID, also known as the job ID or the queue ID),
          which is used for logging; "daemon_name" (the symbolic name
          given to the MTA instance that accepted the connection),
          which is used when performing tests against any "MTAs" set-
          ting used; and "auth_type", which is used to determine
          whether or not the SMTP client authenticated to the MTA.  If
          the MTA does not provide them to opendkim then it is not
          able to apply their corresponding tests or do useful log-
          ging.  Consult your MTA documentation to determine how to
          adjust your its configuration if some or all of these are
          not available.

          When the filter is started as the superuser and the UserID
          (-u) setting is used, the filter gives up its root privi-
          leges by changing to the specified user after the following
          steps are taken: (1) the configuration file (if any) is
          loaded; (2) if the KeyFile (-k) setting is used, that key is

     Page 9                       Plan 9             (printed 5/23/22)

     opendkim(8)       (The Trusted Domain Project)        opendkim(8)

          loaded into memory; (3) all data sets in the configuration
          file are opened, and those that are based on flat files are
          also read into memory; and (4) if ChangeRootDirectory is
          set, the process root is changed to that directory.  This
          means on configuration reload, the filter will not be
          accessing these files or the configuration file as the supe-
          ruser (and possibly from a different root), and any key
          files referenced by the KeyTable will also be accessed by
          the new user.

          Thus, keys referenced by the KeyTable must always be acces-
          sible for read by the unprivileged user.  Also, run-time
          reloads are not possible if any of the other files will not
          be readable by the unprivileged user.

          The following environment variable(s) can be used to adjust
          the behaviour of this filter:

               The directory to use when creating temporary files.
               The default is /tmp.

          When using DNS timeouts (see the -T option above), be sure
          not to use a timeout that is larger than the timeout being
          used for interaction between sendmail and the filter.  Oth-
          erwise, the MTA could abort a message while waiting for a
          reply from the filter, which in turn is still waiting for a
          DNS reply.

          The POP authentication database is expected to be a Sleepy-
          cat DB file (formerly known as a Berkeley DB) in hash format
          with keys containing the IP address in text form without a
          terminating NULL.  The values of these records are not
          checked; only the existence of such records is of interest.
          The filter will attempt to establish a shared lock on the
          database before reading from it, so any programs which write
          to the database should keep their lock use to a minimum or
          else this filter will appear to hang while waiting for the
          lock operation to complete.

          Features that involve specification of IPv4 addresses or
          CIDR blocks will use the inet_addr(3) function to parse that
          information.  Users should be familiar with the way that
          function handles the non-trivial cases (for example,
          "192.0.2/24" and "" are not the same thing).

          Filter exit status codes are selected according to

     Page 10                      Plan 9             (printed 5/23/22)

     opendkim(8)       (The Trusted Domain Project)        opendkim(8)

          DKIM is an amalgam of Yahoo!'s DomainKeys proposal, and
          Cisco's Internet Identified Mail (IIM) proposal.

          This man page covers version 2.11.0 of opendkim.

          Copyright (c) 2005-2008, Sendmail, Inc. and its suppliers.
          All rights reserved.

          Copyright (c) 2009-2013, 2015, The Trusted Domain Project.
          All rights reserved.

          opendkim.conf(5), sendmail(8)

          Sendmail Operations Guide

          RFC5321 - Simple Mail Transfer Protocol

          RFC5322 - Internet Messages

          RFC5451 - Message Header Field for Indicating Message
          Authentication Status

          RFC6008 - Authentication-Results Registration for Differen-
          tiating among Cryptographic Results

          RFC6376 - DomainKeys Identified Mail

     Page 11                      Plan 9             (printed 5/23/22)