| Both sides previous revisionPrevious revision | |
| computing:mailclient [2026/04/19 18:41] – oemb1905 | computing:mailclient [2026/04/19 19:31] (current) – oemb1905 |
|---|
| 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: | 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: |
| |
| * [[https://manpages.debian.org/jessie/exim4-config/update-exim4.conf.8.en.html |Man Pages Examples]] - | * [[https://manpages.debian.org/jessie/exim4-config/update-exim4.conf.8.en.html |Man Pages Examples]] |
| |
| 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. | 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. |
| EOF | EOF |
| </code> | </code> |
| | |
| | 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. |
| |
| # 3. Password file | # 3. Password file |
| EOF | EOF |
| </code> | </code> |
| | |
| | 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 | # 4. Email address rewriting |
| </code> | </code> |
| |
| # 5. Set mailname | 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. |
| | |
| | # 5. Set mailname and hostname |
| <code> | <code> |
| echo "net.outsidebox.vip" | sudo tee /etc/mailname | echo "net.outsidebox.vip" | sudo tee /etc/mailname |
| </code> | </code> |
| |
| Make sure alias and fqdn are also specified properly in /etc/hosts. | 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 | # 6. Fix permissions and apply |
| </code> | </code> |
| |
| # 7. Configure the remote mailserver to accept email from the subdomain and/or other IP of the client: | Set permissions on the credentials and restart the services. |
| | |
| | # 7. Configure the **remote mailserver** to accept email from the subdomain and/or other IP of the client: |
| <code> | <code> |
| nano /etc/postfix/main.cf | nano /etc/postfix/main.cf |
| </code> | </code> |
| |
| System emails default to root@sub.domain.org or root@net.outsidebox.vip for example. Unless you approve that envelope, the message will be rejected. If you approve it like in my example above, then mail.haacksnetworking.org accepts the email for the corresponding "user" or in this case "net". If you also want to send and respond and use this subdomain in webmail, you can set up A/MX and do so (I'm not). The point of this last part is just that it ensures system email from root@whatevernode.whateverdomain.com arrives to the corresponding user on mail.haacksnetworking.org. In my case, that's typically "root" and then root is aliased to notifications@haacksnetworking.org. In this way, every node feeds into a common monitoring email/system. | 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. |
| |
| --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/04/19 02:38// | --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/04/19 19:06// |
