Sending system/script messages with DKIM headers added?

I have several scripts that automate stuff, some of them that send emails with the results. For messages that leave my server (sent to outside mail servers), they are starting to get bounced because they don't have DKIM headers in them.
I generally use mutt with a .muttrc config file to make sure it "looks" familiar to the person receiving the email.
for this specfiic request, i'm making them look like they came from a valid email on this server, but they are sent by a linux user account using "from = " in the muttrc. This is on an ISPConfig 3.x server, with DKIM enabled on that particular domain. It appears amavis is what adds the DKIM headers to the outgoing emails.
using mutt and curl, i can see that amavis is scanning the emails on the way out - any thoughts on how to tweak the commands/configurations to get the DKIM headers added as well?
here's an example of the curl command that does send an email, but without the DKIM header included

Code:

curl --url 'smtp://localhost:587' --mail-from '[email protected]' --mail-rcpt '[email protected]' --upload-file somefile.txt --user '[email protected]:mypass'

 

I should note that I can't actually get mutt to send out an email through a specific account - I repeatedly get SASL Authentication Failed when trying to do so, using variations on the following muttrc. I had a more complicated password at first, but I even simplified that to just a 10-digit alphanumeric string, and still no go.

Code:

set from = "[email protected]"
set realname = "Virtual User"
set smtp_url = "smtps://mail.somedomain.com:465"
set smtp_pass = 'mypass'
set ssl_starttls = yes
set ssl_force_tls = yes

I read somewhere that single quotes on the password helped , but i've tried no quotes and doublequotes as well.

 

in case someone's interested, I set mutt to debug level 5, and got this in my .muttdebug file

Code:

[2025-02-16 16:33:00] Mutt/2.0.7 (2021-05-04) debugging at level 5
[2025-02-16 16:33:00] Reading configuration file '/etc/Muttrc'.
[2025-02-16 16:33:00] parse_attach_list: ldata = 0x562f9dd1a740, *ldata = (nil)
[2025-02-16 16:33:00] parse_attach_list: added */.* [9]
[2025-02-16 16:33:00] parse_attach_list: ldata = 0x562f9dd19e90, *ldata = (nil)
[2025-02-16 16:33:00] parse_attach_list: added text/x-vcard [7]
[2025-02-16 16:33:00] parse_attach_list: added application/pgp.* [2]
[2025-02-16 16:33:00] parse_attach_list: ldata = 0x562f9dd19e90, *ldata = 0x562f9e3ffdd0
[2025-02-16 16:33:00] parse_attach_list: skipping text/x-vcard
[2025-02-16 16:33:00] parse_attach_list: skipping application/pgp.*
[2025-02-16 16:33:00] parse_attach_list: added application/x-pkcs7-.* [2]
[2025-02-16 16:33:00] parse_attach_list: ldata = 0x562f9dd1a310, *ldata = (nil)
[2025-02-16 16:33:00] parse_attach_list: added text/plain [7]
[2025-02-16 16:33:00] parse_attach_list: ldata = 0x562f9dd19e90, *ldata = 0x562f9e3ffdd0
[2025-02-16 16:33:00] parse_attach_list: skipping text/x-vcard
[2025-02-16 16:33:00] parse_attach_list: skipping application/pgp.*
[2025-02-16 16:33:00] parse_attach_list: skipping application/x-pkcs7-.*
[2025-02-16 16:33:00] parse_attach_list: added message/external-body [4]
[2025-02-16 16:33:00] parse_attach_list: ldata = 0x562f9dd1a330, *ldata = (nil)
[2025-02-16 16:33:00] parse_attach_list: added message/external-body [4]
[2025-02-16 16:33:00] Reading configuration file '/etc/Muttrc.local'.
[2025-02-16 16:33:00] Reading configuration file '/user/.muttTEST'.
[2025-02-16 16:33:00] getdnsdomainname(): anotherdomain.com
[2025-02-16 16:33:00] send.c:1939: mutt_mktemp returns "/tmp/mutt-dns2-0-1313471-1427376073477587627".
[2025-02-16 16:33:00] send.c:1175: mutt_mktemp returns "/tmp/mutt-dns2-0-1313471-12703513576184024131".
[2025-02-16 16:33:00] mwoh: buf[Subject: muttTEST] is short enough

no complaints that it couldn't authenticate, or otherwise failed, and nothing on the command line afterwards either.

 

I don't know mutt but by the looks of your log it looks like mutt acts as a mta itself, thereby bypassing postfix (and amavis for dkim signing).
Why else would mutt need to dns query the recipient domain?

 

thanks for the reply.
i thought that as well, but then why would it need any SMTP credentials? it's clearly going through the system MTA, as it's getting scanned by amavis, but it just doesn't seem to qualify for getting DKIM added to it, like it's not ACTUALLY being sent through that account, or recognized as such.

 

Only condition for dkim signing in postfix/amavis should be the sender's domain.
It should not matter where the mail originated from (mutt in this case).

Why would you try to let mutt send mail using specific account credentials when both mutt and postfix run on the same system?
Smtp authentication is somewhat reduntant for localhost as localhost may already send mail without authentication.

 

as stated, i'm trying to use shell scripts that run under system accounts (not ISPconfig accounts) to send out emails. in order for outside mail servers to accept them they need to have DKIM signatures. currently, using mutt under a system account, they going out via postfix (I can see them in the maillog), but aren't getting any DKIM signatures added to them. I thought if i could find a way to send out through an ISPconfig email account, they would get treated different, and maybe get the DKIM signatures added to them.
that does not appear to be the case. curl does the same thing.

 

thanks - but it's already set to that in /etc/amavisd/amavisd.conf

Code:

$policy_bank{'MYNETS'} = {   # mail originating from @mynetworks
  originating => 1,  # is true in MYNETS by default, but let's make it explicit
  os_fingerprint_method => undef,  # don't query p0f for internal clients
};

 

that's the only reference to it in the conf file for MYNETS
i did a little searching for DKIM in the conf file, found these, which look set correctly:

Code:

$enable_dkim_verification = 1;  # enable DKIM signatures verification
$enable_dkim_signing = 1;    # load DKIM signing code, keys defined by dkim_key

and here's the entire POLICY_BANK setup for the "originating" side of things:

Code:

$policy_bank{'MYNETS'} = {   # mail originating from @mynetworks
  originating => 1,  # is true in MYNETS by default, but let's make it explicit
  os_fingerprint_method => undef,  # don't query p0f for internal clients
};

# it is up to MTA to re-route mail from authenticated roaming users or
# from internal hosts to a dedicated TCP port (such as 10022) for filtering
$interface_policy{'10022'} = 'ORIGINATING';

$policy_bank{'ORIGINATING'} = {  # mail supposedly originating from our users
  originating => 1,  # declare that mail was submitted by our smtp client
  allow_disclaimers => 1,  # enables disclaimer insertion if available
  # notify administrator of locally originating malware
  virus_admin_maps => ["virusalert\@$mydomain"],
  spam_admin_maps  => ["virusalert\@$mydomain"],
  warnbadhsender   => 1,
  # forward to a smtpd service providing DKIM signing service
  forward_method => 'smtp:[127.0.0.1]:10025',
  # force MTA conversion to 7-bit (e.g. before DKIM signing)
  smtpd_discard_ehlo_keywords => ['8BITMIME'],
  bypass_banned_checks_maps => [1],  # allow sending any file names and types
  terminate_dsn_on_notify_success => 0,  # don't remove NOTIFY=SUCCESS option
  bypass_header_checks => 1,
};

 

Yes that was clear

Like I said, it should not matter where mail originated when it's picked up by postfix/amavis.
So it doesn't matter if the mail was sent through an ISPC mailaccount or a system account (on the same server).
Only condition for amavis to dkim sign the mail should be the sender's domain.
So for whatever reason the sender's domain isn't read correctly from the mail by amavis as it doesn't get signed.