Use this for personal machines behind someone else's LAN. It turns exim into a MUA instead of a MTA. That is, tt uses your remote self-hosted smtp instead of sending directly.
sudo apt install exim4 sudo nano /etc/exim4/update-exim4.conf.conf dc_eximconfig_configtype='smarthost' dc_smarthost='mail.domain.com::587' dc_local_interfaces='127.0.0.1 ; ::1' dc_other_hostnames='' dc_readhost='haacksnetworking.org' dc_relay_domains='' dc_minimaldns='false' dc_hide_mailname='true' #just in case dc_localdelivery='notifications@haacksnetworking.org' sudo nano /etc/exim4/passwd.client mail.domain.com:user:password *:user:password sudo chown root:Debian-exim /etc/exim4/passwd.client sudo chmod 640 /etc/exim4/passwd.client #setup headers sudo nano /etc/email-addresses sexa: remote@haacksnetworking.org root: remote@haacksnetworking.org *: remote@haacksnetworking.org #calm tls sudo nano /etc/exim4/exim4.conf.localmacros MAIN_TLS_ADVERTISE_HOSTS = REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS = * MAIN_HARDCODE_PRIMARY_HOSTNAME = domain.com MAIN_LOCAL_DOMAINS = #disable_ipv6=true #if needed sudo update-exim4.conf sudo systemctl restart exim4 echo "Test after permission fix" | mail -s "Exim4 test 2" oemb1905@jonathanhaack.com sudo tail -f /var/log/exim4/mainlog
Here's a copy pastable version:
sudo apt install exim4 cat << 'EOF' | sudo tee /etc/exim4/update-exim4.conf.conf dc_eximconfig_configtype='smarthost' dc_smarthost='mail.domain.com::587' dc_local_interfaces='127.0.0.1 ; ::1' dc_other_hostnames='' dc_readhost='haacksnetworking.org' dc_relay_domains='' dc_minimaldns='false' dc_hide_mailname='true' dc_localdelivery='notifications@haacksnetworking.org' EOF cat << 'EOF' | sudo tee /etc/exim4/passwd.client mail.domain.com:user:password *:user:password EOF sudo chown root:Debian-exim /etc/exim4/passwd.client sudo chmod 640 /etc/exim4/passwd.client sudo cat << EOF > /etc/email-addresses sexa: remote@haacksnetworking.org root: remote@haacksnetworking.org *: remote@haacksnetworking.org EOF cat << 'EOF' | sudo tee /etc/exim4/exim4.conf.localmacros MAIN_TLS_ADVERTISE_HOSTS = REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS = * MAIN_HARDCODE_PRIMARY_HOSTNAME = domain.com MAIN_LOCAL_DOMAINS = #disable_ipv6=true #if needed EOF sudo update-exim4.conf sudo systemctl restart exim4 echo "Exim4 configured and restarted." echo "Test with:" echo 'echo "Test from $(hostname)" | mail -s "Exim4 test from $(hostname)" test@gmail.com'
We turned off local delivery above so now all we need to do is set the hostname and mailname to domain.com:
echo "haacksnetworking.org" | sudo tee /etc/mailname echo "haacksnetworking.org" | sudo tee /etc/hostname
Then, in /etc/hosts enter something like:
127.0.1.1 domain.com domain
Send a few test emails to external domains (external to mail server) and to local users (local on the client):
echo "Satellite test $(date)" | mail -s "Normal satellite test 7" root echo "Satellite test $(date)" | mail -s "Normal satellite test 7" oemb1905@gmail.com
Alias Test
Both will work … and here's how and why. In the first case, you send from the client to root, and exim sends the email (via the above configuration) to the address root@</etc/mailname>. Since the client's mailname is domain.com, and since root@domain.com exists on the remote email server, the client sends to that address. And, in my case, the email server's root address is aliased to notifications@domain.com, and the email arrives. Moreover, since the mail server recognizes that the email it is sending is going to a local user, spf is bypassed since it is trusted. DKIM still works.
External Test
For the external tests, things are even smoother. The client authenticates against the mail server and the mail server sends the email directly. Since the envelope-from is the same as the client's actual origin, i.e., user@domain.com, Gmail will query the spf record for the tld, or domain.com. And since the client is sending through the remote email server as a MUA, not as an MTA directly, that will obviously pass spf. DKIM, again, is server side and works still.
Concluding Thoughts
And with that … that's it. The only drawback is that any such nodes/clients, must be called domain.com. However, that's hardly an issue for the target email receiving the logs and such because those will show as remote@domain.com, monitor@domain.com, and so on, thus easily distinguishable from one another by both the user and associated purpose/name of that user. And, since each machine's purpose is named after the user, you can easily disambiguate the machines by that user name, if not also by their location and function.
— oemb1905 2026/04/08 19:28
