exim4 is using the [hostname] rather than the [domain name] when sending resulting in the Mailjet smarthost rejecting the sender’s address. The messages are emanating from the system and being sent to a user on gmail and/or to the webmaster@[domain].
Has anyone any advice on fixing this? You will see I have done some investigaion of a standard exim4 configuration but do not want to screw up an otherwise working multidomain server.
I also found in Server Fault references to setting “local_from_check” and “sender_unqualified_hosts” in the configuration to fix similar problems but these do not appear in the sympl.d configuration.
Any Error Messages
Mailjet emailed me:
‘’‘We are contacting you as you (or one of your team members) tried to send an email with sender address: root@[hostname]’‘’
Environment
Sympl Version: 12
Sympl Testing Version:
Debian Version:12
Hardware Type:Gcloud instance
Hosted With: Google
Looking at the exim conf.d directory for inspiration I found these snippets.
nano ./conf.d/main/01_exim4-config_listmacrosdefs
Decide which domain to use to add to all unqualified addresses.
If MAIN_PRIMARY_HOSTNAME_AS_QUALIFY_DOMAIN is defined, the primary
hostname is used. If not, but MAIN_QUALIFY_DOMAIN is set, the value
of MAIN_QUALIFY_DOMAIN is used. If both macros are not defined,
If you’re running sympl, exim is not using the configuration in conf.d but that in sympl.d.
I think the single file exim4.conf is built from the directory tree under sympl.d so you could look there too, but don’t modify anything in that file unless it’s only meant to be a temporary change.
Not that it helps with your specific problem, but you might be looking “for inspiration” in the wrong place!
Thanks,
I have already modified the sympl.d files to successfully speak to the Mailget smart host . See my previous post. So I do realise that I need to further modify the sympl.d conf files. I was hoping somebody could help prior to me creating a test system for any mods I might conceive.
What’s actually generating the root@ emails? Are these system mails like Cron emails which are just being sent to “root”, and the chnages are causing then to be sent to Mailjet?
As that’s Mailjet policy could you add the hostname as an approved sender address/domain?
Unless I am missing something, that does not translate a hostname into a domain name it only allows you to add a sender with a FQDN, not one without. so exim4 must send a proper email address to Mailjet.
Or, still avoiding exim4.conf ;), change the server hostname to one of your (approved) domains
All my certificates for all the domains seem to be working correctly.
Also all the domains are web serving and sending mail perfectly.
It is only the local mail from root which is not being sent externally as it does not have a vaild domain in the sender.
Anyhow thanks for your attention. I will try on my home test server to change the hostname to the domain name.
So in doing this I think the erroneous mail is coming from the test server (not the live server) as this says the hostname is the same as the Mailjet error message.
Its /etc/hosts is …
127.0.0.1 localhost
127.0.1.1 jowett.club mail.jowett.club jowett
The following lines are desirable for IPv6 capable hosts
I have now added the current external IP address to this file with the jowett.club domain name. I will see what happens.
What’s actually generating the root@ emails? Are these system mails like Cron emails which are just being sent to “root”, and the chnages are causing then to be sent to Mailjet?
Yes I think it is a cron process but ‘exim -bp’ shows nothing in the queue and a look at a few days of /var/log/exim4/mainlog and reject.log shows nothing obvious. I will attempt to trap the offending message.
Ah, sorry, I wrongly assumed that the ‘hostname’ was a FQDN which might need registering at Mailjet. (Here, the hostname command returns alphacabbage1.vs.mythic-beasts.com and the ‘system’ message sender is set with it as ‘root’ as the local part).
So, I expect that option 2, changing the hostname to a FQDN, will keep Mailjet happy as far as the sender is concerned.
The docs suggest another route is to explicitly set qualify_domain in the config file:
By default, Exim automatically qualifies unqualified addresses (those without domains) that appear in messages that are submitted locally (that is, not over TCP/IP). This qualification applies both to addresses in envelopes, and addresses in header lines. Sender addresses are qualified using qualify_domain, and recipient addresses using qualify_recipient (which defaults to the value of qualify_domain).
The messages are coming from anacron every day only around 7:30 in the test server. It is this type of message which Mailjet rejects as not a valid sender.
From: Anacron root@jowett
To: root@jowett
From root@jowett Wed Oct 15 07:35:53 2025
Return-path: root@jowett
Envelope-to: root@jowett
(envelope-from root@jowett)
for root@jowett;
Looking at the same /var/mail/mail file on the live server there are lots more messages coming every hour as well as the daily message, but this server does not try to forward via Mailjet.
I am trying to find out why there are these two differences.
From root@jowettnet Fri Sep 26 06:38:42 2025
Return-path: root@jowettnet
Envelope-to: root@jowettnet
(envelope-from root@jowettnet)
for root@jowettnet;
From: root@jowettnet (Cron Daemon)
To: root@jowettnet
Subject: Cron root@jowettnet test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.daily; }
From root@jowettnet Fri Sep 26 07:17:27 2025
Return-path: root@jowettnet
Envelope-to: root@jowettnet
(envelope-from root@jowettnet)
for root@jowettnet;
From: root@jowettnet (Cron Daemon)
To: root@jowettnet
Subject: Cron root@jowettnet cd / && run-parts --report /etc/cron.hourly
This showed up differences between the two server’s cron.d files with anacron not being present on the live server.
e2scrub_all geoipupdate nftfw php roundcube-core sympl-core sympl-cron sympl-dns
but it was on the test server
anacron e2scrub_all geoipupdate nftfw php roundcube-core sympl-core sympl-cron sympl-dns
How anacron was installed I will need to figure out, maybe the docker system installed it.
(UPDATE: Does the sympl or the Debian install know that the home server is on a PC and so install anacron rther than cron?)
There seem to be various ways to prevent emails being sent from cron. Ideally I would like to be alerted about errors but not have these regular messages.
I have found the culprit which is /etc/cron.daily/zz-backup2l This file was running automatic backups and running out of disk space so was trying to send an error message.
But stopping the message would not solve the problem of how to send it if I wanted to.