Re: OpenDKIM: no MTA name match (,

From: Murray S. Kucherawy <>
Date: Thu, 13 Feb 2014 21:57:22 -0800 (PST)

On Thu, 13 Feb 2014, Pau Peris wrote:
> Looking at the man page it looks liek here i should place a list of FQDN
> whose mail is meant to be signed, right? But it also states that this
> setting is not taken into account on the signing decision, so i'm completely
> lost here. What makes more sense here, typing the local host FQDN, placing
> list of trusted hosts unique FQND or leaving it as is?
>        MTA (dataset)
>               A  set  of MTA names (a la the sendmail(8) DaemonPortOptions
> Name parameter) whose mail should be signed by this filter.  There is no
> default, meaning MTA name is not considered when making the sign-verify
> decision.
> Although OpenDKIM seems to be working fine i would liek to clear this up.

milter-aware MTAs provide to filters a set of "macros", which are
essentially entries in a key-value table. OpenDKIM is interested in a few
of these for its operation. One of them is "i", which is the queue ID for
the message being processed; OpenDKIM uses this for logging and some
temporary file names. Another is "j", which is the hostname by which the
MTA is known and, for example, appears in Received fields and
auto-generate header fields and the like (for example, a "To:" field that
contains only a userid and no domain name might have this value added as
the domain name). Auto-generated failure reports use this.

A third is "daemon_name", which is included as a way of identifying
multiple MTAs on the same machine. For sendmail, this is controlled via
the DaemonPortOptions setting. If, for example, you have sendmail
configured to listen on port 587 and on port 25, you might give these
different names ("submission" and "smtp", for example) so that the filter
can tell over which of these two ports a message arrived.

So to put that all together: If you wanted to sign only that mail which
arrived over port 587, then setting OpenDKIM's "MTA" setting to
"submission" will achieve that for you.

Received on Fri Feb 14 2014 - 05:57:41 PST

This archive was generated by hypermail 2.3.0 : Fri Feb 14 2014 - 06:00:01 PST