OpenDKIM / Postfix sign console-sent mail, but not from a mail client / SMTP

Question

I have Postfix running on a Debian 9 machine, and installed opendkim (both from the Debian repositories). The milter socket/connection is inet:localhost:8892, and the iptables firewall allows that connection (a telnet localhost 8892 succeeds).

However, I only get signed messages if I send e-mail from the console (with mail -s "testing DKIM" my-address@not-the-same-domain), but not if I send it from Thunderbird. Notice, with Thunderbird, I use ssh tunneling, so that the mail server sees the connection as originating from localhost. (that is, on my desktop, I run ssh -Llocalhost:2525:my-server:25 tunnel@my-server, and I tell Thunderbird that the outgoing mail server is localhost, port 2525.

This is an example of the signature I get when sending from the console:

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=[omitted -- but it shows the correct domain];
    s=mail; t=1557228588;
    bh=slJTHzrIw+6TkIIPpFmGER34xtLwMLZ2md99gvHoFTE=;
    h=To:Subject:Date:From:From;
    b=jtOM5OOM83l [ ··· several lines of "gibberish" ··· ] 4qdpSt4l86DEA==

Any ideas on what could be causing this issue?

[[EDIT]] The problem gets more puzzling. While inspecting the logs, I noticed a warning external host XXXX.my-service-provider.com attempted to send as my-domain.com

I adjusted /etc/hosts, /etc/hostname ... Finally I realized that I had to adjust the reverse DNS lookup, and I did that. Now, the command hostname responds with the FQDN (the correct domain for which I'm configuring DKIM).

Now, in /var/log/syslog when I send an e-mail, I'm getting the message external host *the-correct-FQDN* attempted to send as *the-correct-FQDN*. And the transmitted message does not contain a DKIM signature.

If I do telnet localhost 25, greet the SMTP server with helo the-correct-FQDN, the message is DKIM-signed; the logs show that a connection from localhost (127.0.0.1) was responsible for the transmission.

Any ideas?
[[ END EDIT ]]

Answer 1

Turns out the issue was caused by a lack of a InternalHosts parameter. For the current version of opendkim on Debian 9 (2.11), I solved it as follows:

Edited file /etc/opendkim.conf and added the following line:

InternalHosts file:/etc/opendkim-trustedhosts.conf

Then, the file /etc/opendkim-trustedhosts.conf contains:

127.0.0.1
x.x.x.x (the actual public IP of the server)

And voilà --- restart and that fixed the problem!

Some differences I noticed w.r.t. other info I found out there --- from what I could see, on CentOS (not sure whether older versions or still like this), the default configuration is: there is a directory etc/opendkim, and inside that directory there is, among others, a file TrustedHosts.conf; the file /etc/opendkim.conf already has the InternalHosts directive pointing to the TrustedHosts file. On Debian 9, one has to create it manually.

Answer 2

Similar problem and context: using openDKIM with Postfix as MTA that is then a relay only for authenticated Mail User Agents (MUA's), the later counting notably MS-Outlook clients configured with SMTP+POP or SMTP+IMAP connexions to the Postfix MTA over TLS/SSL + SASL (authentication with login and password) through port 587 in my case.

When local console 'mailx' or 'sendmail' is used, the openDKIM integration is controlled through the non_smtpd_milters option in postfix/main.cf, whereas smtpd_milters option do control the case of incoming SMTPD e-mails from authenticated MUA's. So first you may need to check that both options are aligned, e.g. like

smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = $smtpd_milters

Then, when a valid DKIM signature is generated for local e-mails (via 'mailx' or 'sendmail') but not on e-mails from authenticated MUA's, it is most likely an issue with determining who is the message sender and thus preventing openDKIM to crawl to the 'From:' domain for which the signature is setup. You may likely found traces like:

opendkim[9530]: E3B6A13CBED: can't determine message sender;

which in my case was due to an interference with the header_checks option in Postfix. Look for it in either main.cf or master.cf (which can override options in main.cf), e.g.

-o header_checks=regexp:/etc/postfix/submission_header_cleanup

and ensure the associateed header cleanup rules will NOT contain a regex like:

/^Received:/            IGNORE

which you must then comment-OUT or remove.

Last, ensure postfix/main.cf will tell Postfix to pass sufficient data to opendkim through the milter protocol with an option like:

milter_mail_macros =  i {mail_addr} {client_addr} {client_name} {auth_type} {auth_authen}