Haack's Wiki

User Tools

Site Tools

Trace:
computing:mailclient

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
computing:mailclient [2026/04/08 19:47] – oemb1905computing:mailclient [2026/04/19 19:31] (current) – oemb1905
Line 1: Line 1:
-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. +# 1. Main configuration for exim
 <code> <code>
-sudo apt install exim4 +cat << 'EOF' | sudo tee /etc/exim4/update-exim4.conf.conf 
-sudo nano /etc/exim4/update-exim4.conf.conf +dc_eximconfig_configtype='satellite' 
-dc_eximconfig_configtype='smarthost' +dc_smarthost='mail.haacksnetworking.org::587'
-dc_smarthost='mail.domain.com::587'+
 dc_local_interfaces='127.0.0.1 ; ::1' dc_local_interfaces='127.0.0.1 ; ::1'
 dc_other_hostnames='' dc_other_hostnames=''
Line 12: Line 10:
 dc_minimaldns='false' dc_minimaldns='false'
 dc_hide_mailname='true' dc_hide_mailname='true'
-#just in case +dc_localdelivery='net@haacksnetworking.org' 
-dc_localdelivery='notifications@haacksnetworking.org'+EOF 
 +</code>
  
-sudo nano /etc/exim4/passwd.client +Local delivery is there as a placeholder but/and is ignored as per the localmacros entry below. It is harmless and in some cases I enable it and remove the other entry, etc., so its retained here. The rest are self-explanatory. It should be noted that exim4 currently has a bug whereby it cannot properly interpret ipv6 entries and/or bind to the ipv6-ready interface, so I disabled it for now. For some, this is a routing issue, but my routing table is good and it still does not work:
-mail.domain.com:user:password +
-*:user:password+
  
-sudo chown root:Debian-exim /etc/exim4/passwd.client +  * [[https://manpages.debian.org/jessie/exim4-config/update-exim4.conf.8.en.html |Man Pages Examples]] 
-sudo chmod 640 /etc/exim4/passwd.client+
  
-#setup headers +Despite formatting it as the man pages and ncurses installer suggest, e.g., ''dc_smarthost='[2046::1bd7::f::6::::20]::587''', it nevertheless interprets the IP as a domain and tries to do a DNS check on it. I plan to remove the ipv6 block once this fixed and/or I discover a work-around.
-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+# 2. Local macros 
 +<code> 
 +cat << 'EOF' | sudo tee /etc/exim4/exim4.conf.localmacros
 MAIN_TLS_ADVERTISE_HOSTS = MAIN_TLS_ADVERTISE_HOSTS =
 REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS = * REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS = *
-MAIN_HARDCODE_PRIMARY_HOSTNAME = domain.com 
 MAIN_LOCAL_DOMAINS = MAIN_LOCAL_DOMAINS =
-#disable_ipv6=true #if needed+disable_ipv6 = true 
 +EOF 
 +</code>
  
-sudo update-exim4.conf +This block has a lot. First, it requires TLS whether the server does or not. Secondly, it stops attempts at local delivery, i.e., if I had a cronjob trying to email a report to user@haacksnetworking.org or user@net.haacksnetworking.org, it prohibits it from trying to deliver it to the client itself. This is good because the client is send-only, and does not have dovecot installed ofc. Rather, we want emails from net@haacksnetworking.org sent to, e.g., notifications@haacksnetworking.org to be delivered externally. As noted earlier, ipv6 is disabled due to the exim4 bug. Lastly, since this server is send-only, we also disable TLS advertisements. There's no need to advertise to clients for incoming connections.
-sudo systemctl restart exim4 +
- +
-echo "Test after permission fix" | mail -s "Exim4 test 2" oemb1905@jonathanhaack.com +
-sudo tail -f /var/log/exim4/mainlog+
  
 +# 3. Password file
 +<code>
 +cat << 'EOF' | sudo tee /etc/exim4/passwd.client
 +mail.haacksnetworking.org:net:pass
 +*:net:pass
 +EOF
 </code> </code>
  
-Here's a copy pastable version:+Pretty self-explanatory. Replace ''pass'' above with a secure password. I would recommend ensuring TLS is enforced on the server as well as on the client, combined with a non-dictionary 40 character password. Since these credentials are stored in plain files and we are using simple UNIX users, you need to make sure that you don't give users ''sudo'' privileges. The email accounts should be separate from user accounts used for shell access and shell access should be disabled for any user accounts being used as email. Naturally, one should not have password auth via ssh enabled; key-based login should be enforced. In short, any time you are storing credentials for simple UNIX users on a remote client, make sure they are not sudoers, have no shell access, and that ssh is key-based only and preferably with an explicitly allowed sysadmin user, e.g., ''AllowUsers sysadmn''.
  
 +# 4. Email address rewriting
 <code> <code>
-sudo apt install exim4 +cat << 'EOF' | sudo tee /etc/email-addresses 
-cat << 'EOF' | sudo tee /etc/exim4/update-exim4.conf.conf +sexa: net@haacksnetworking.org 
-dc_eximconfig_configtype='smarthost' +root: net@haacksnetworking.org 
-dc_smarthost='mail.domain.com::587' +*: net@haacksnetworking.org
-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 EOF
 +</code>
  
-cat << 'EOF' | sudo tee /etc/exim4/passwd.client +This re-writes the headers so that system and/or cronjob emails originating from the client match the remote smtp user credentials and domain. Without this, exim4 would use the system email as the envelope-from instead of the remote server's. This is essential for emails to arrive at Gmail, Microsoft, etc., without issue. 
-mail.domain.com:user:password + 
-*:user:password +# 5. Set mailname and hostname 
-EOF+<code> 
 +echo "net.outsidebox.vip" | sudo tee /etc/mailname 
 +echo "net.outsidebox.vip" | sudo tee /etc/hostname 
 +</code>
  
 +Make sure alias and fqdn are also specified properly in ''/etc/hosts''. Remember, system emails go to ''root@net.outsidebox.vip'' but they attempt this delivery via ''mail.haacksnetworking.org''. So, since this origin is allowed in ''mail.haacksnetworking.org'', those get delivered to root on ''haacksnetworking.org'' and/or whatever alias is specified there. In short, setting the fqdn.com is essential to figuring out which system-generated emails are which if/when problems happen. In short, if/when these values are set, the email will be sent to the alias specified for root on ''mail.haacksnetworking.org'', which is ''notifications@haacksnetworking.org'', and the from address will be ''root@net.outsidebox.vip''. The fqdn.com being set ensures clear disambiguation when issues come up.
 +
 +# 6. Fix permissions and apply
 +<code>
 sudo chown root:Debian-exim /etc/exim4/passwd.client sudo chown root:Debian-exim /etc/exim4/passwd.client
 sudo chmod 640 /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 update-exim4.conf
 sudo systemctl restart exim4 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' 
 </code> </code>
  
-We turned off local delivery above so now all we need to do is set the hostname and mailname to domain.com: +Set permissions on the credentials and restart the services. 
  
-  echo "haacksnetworking.org" | sudo tee /etc/mailname +# 7. Configure the **remote mailserver** to accept email from the subdomain and/or other IP of the client: 
-  echo "haacksnetworking.org" | sudo tee /etc/hostname +<code> 
- +nano /etc/postfix/main.cf 
-Then, in ''/etc/hosts'' enter something like: +mydestination = mail.haacksnetworking.org, 
- +        haacksnetworking.org, 
-  127.0.1.1       domain.com    domain +        mail.haacksnetworking.org,  
-   +        node0.otherdomain.org, #accept system email sent to your node's "local" address 
-Send a few test emails to external domains (external to mail server) and to local users (local on the client): +        node1.otherdomain.com, #accept system email sent to your node's "local" address 
- +        localhost.haacksnetworking.org, 
-  echo "Satellite test $(date)" | mail -s "Normal satellite test 7" root +        localhost 
-  echo "Satellite test $(date)" | mail -s "Normal satellite test 7" oemb1905@gmail.com +sudo systemctl restart postfix 
- +</code>
-=== 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 === +We need to adjust the remote email server. This is because, as mentioned above, system emails default to ''root@sub.domain.org'' or ''root@net.outsidebox.vip'', for example. Unless you approve that from envelope, the message will be rejected by ''mail.haacksnetworking.org''. If you configure the remote server to accept email for that domain, however, then it will attempt local delivery first and send that email to the corresponding "user" (in this case root) on ''mail.haacksnetworking.org''. If you also want to send and respond and use this subdomain in webmail, you can point that subdomain to your remote mail server's A/AAAA and MX records. I don't need that, but I did test and ensure it worked. In short, by adding this origin, system-generated emails from each client will arrive at root or root's alias on the remote server, ensuring oversight and proper monitoring takes place.
-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.+
  
- --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/04/08 19:28//+ --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/04/19 19:06//
computing/mailclient.1775677641.txt.gz · Last modified: by oemb1905

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: GNU Free Documentation License 1.3
GNU Free Documentation License 1.3 Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki