Changes for page How to setup a postfix SMTP server

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -71,7 +71,7 @@
71	71	myhostname = transistor.one
72	72	mydestination = localhost
73	73	mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 172.16.0.0/12
74		-inet_interfaces = 127.0.0.1 172.16.0.1
	74	+inet_interfaces = 127.0.0.1 172.16.0.1 mail.transistor.one
75	75	inet_protocols = all
76	76	{{/code}}
77	77
...	...	@@ -81,6 +81,8 @@
81	81	Next is the "smtpd_relay_restrictions" which has a bunch of values assigned to it. The only one relevant to talk about is "permit_mynetworks", which informs Postfix that it's fine to relay any outgoing email from the IP addresses and hosts defined in the "mynetworks" variable, without having to authenticate them with user passwords.
82	82	Basically, this means that, as long as a service connects to port 25 of the current machine from an originating IP that's listed under "mynetworks" this means that Postfix will accept whatever email that service is trying to send and relay it over to its destination.
83	83
	84	+Please note though that the above configuration **still allows emails from external entities to be relayed through this server, as has happened recently to me when Gmail was sending spam through to my Postfix instance because it was trying to send an email to "pentilescu.com", a previous domain that I still own, the email wouldn't reach its destination because the SSL certificates were not configured for that specific domain anymore, the sending would get rejected, Google would automatically send a bounce email to the originator (i.e. my VPS) again, and this would cause the VPS to flood my inbox with these unwanted emails**, which can be abused by those with ill intents.
	85	+
84	84	"mydestination = localhost" not sure about this one?
85	85
86	86	"mynetworks" tells Postfix which machines are trusted. SMTP needs to trust sources of email before it can relay them. If you specify "permit_mynetworks" to "smtpd_relay_restrictions" then any machine whose IP is listed in this parameter can relay its email through this Postfix instance.
...	...	@@ -87,17 +87,99 @@
87	87
88	88	Basically, what this means is that, all your docker services need to have their IPs listed in this parameter for Postfix to relay their emails further. This is mandatory. If you omit any docker service's IP from this list, that service will not be able to use Postfix as its SMTP server to relay email even if the Postfix server is technically reachable by it via ICMP echo packets.
89	89
	92	+== Getting the right IP list ==
90	90	To find the IP address for a specific docker container, please run "docker inspect <container_id>" and then look up the "IPAddress" field from the resulting output, under the "Networks" JSON property. Note: it's not the "Gateway" field, that's something else!
91	91
92		-Please be aware, though, that docker allocates IPs dynamically. So even if a container has a specific IP at one point, it doesn't mean that it will have the same IP next time a new container is spawned from the same image (i.e. after a system reboot). As such, this can, in theory, mean that your configuration will work at one point but, after a system reboot, it won't work anymore. This would mean that you either have to specify manual static IP addresses for your docker images so that they will always take the exact same IP all the time (not recommended and it goes against the entire philosophy of docker) or, you can just do what I did and simply whitelist all the possible private IPs under "172.16.0.0/12". This basically resolves to all the 16 continous class B private IP addresses in the IPv4 address space, as seen [[here>>https://en.wikipedia.org/wiki/Private_network#Private_IPv4_addresses]]. Docker will, by default, use IPs in a subrange in this address space, when allocating IPs to newly spawned containers.
	95	+Please be aware, though, that docker allocates IPs dynamically. So even if a container has a specific IP at one point, it doesn't mean that it will have the same IP next time a new container is spawned from the same image (i.e. after a system reboot). As such, this can, in theory, mean that your configuration will work at one point but, after a system reboot, it won't work anymore. This would mean that you either have to specify manual static IP addresses for your docker images so that they will always take the exact same IP all the time (not recommended and it goes against the entire philosophy of docker) or, you can just do what I did and simply whitelist all the possible private IPs under "172.16.0.0/12". This basically resolves to all the 16 continous class B private IP addresses in the IPv4 address space, as seen [[here>>https://en.wikipedia.org/wiki/Private_network#Private_IPv4_addresses]]. --Docker will, by default, use IPs in a subrange in this address space, when allocating IPs to newly spawned containers.-- As I have found out recently, this may not be the case. Docker can use any private IP address that it wishes to use and, as such, it's best to not rely on this.
93	93
	97	+Instead, a better means of configuring docker to respect a specific IP address range is by restricting it from its own configuration, as the administrator.
	98	+
	99	+To do so, please open the docker config file (in my case, this was under "/etc/docker/daemon.json") and edit it with your favorite text editor:
	100	+
	101	+{{code language="JSON"}}
	102	+{
	103	+ "storage-driver": "fuse-overlayfs",
	104	+ "default-address-pools":
	105	+ [
	106	+ {"base":"172.16.0.0/16", "size":24}
	107	+ ]
	108	+}
	109	+{{/code}}
	110	+
	111	+You can safely omit the "storage-driver" property, as this is unnecessary for our needs.
	112	+
	113	+I really can't even remember why I needed to specify it to "fuse-overlayfs". I remember doing so fixed a particular bug that I had encountered in the past, but not what the bug was.
	114	+
	115	+Alas, the only relevant configuration above is the "default-address-pools". This configuration basically tells the docker daemon that, whenever it needs to spawn a container, this container's network will have an address from that addres range specified to it (in our case, the 172.16.0.0/16 network).
	116	+
	117	+Very handy
	118	+
94	94	This approach has the advantage that whichever IP docker will assign to a newly created container, that IP will always fall somewhere in this range, so it will already be whitelisted. Moreover, since this is a private address range, not a public one, nobody outside the current LAN of the server can impersonate it, nor can they breach the local network from the outside if proper firewall and NAT rules are set in place by the network administrator, which means there's never a risk that someone might try misusing our Postfix server from outside our network.
95	95
96	96	Finally, there's the "inet_interfaces" configuration parameter. This one specifies under which identities the current installation of Postfix will be assumed by the server. Postfix will accept all requests destined to any of these addresses as its own and will handle them.
97	97
98		-In a docker configuration, assuming the services are using a "bridge" network driver, they will all have their own IP addresses in the aforementioned address space, and these addresses will be distinct from the proper address of the machine where Postfix is installed. As such, they need a target to resolve to reach the machine running Postfix. This target will be IP 172.16.0.1. When configuring each individual docker service, enter that IP as the IP of the SMTP server to use, as well as port 25, as its connection port. These should be the only parameters you should need to configure everything to work properly. 172.16.0.1 was a random address that I decided on. Really, it has no real relevance and can be changed to any private IPv4 address, whether in class B, C or A. The only point is that it should be reachable through this network driver.
	123	+In a docker configuration, assuming the services are using a "bridge" network driver, they will all have their own IP addresses in the aforementioned address space, and these addresses will be distinct from the proper address of the machine where Postfix is installed. As such, they need a target to resolve to reach the machine running Postfix. This target will be IP 172.16.0.1. **IMPORTANT note: if you'll use TLS enabled in Postfix, please avoid using the raw IP address as mentioned here, as certain services like Nextcloud check the domain of the SMTP server against the TLS certificates being provided and, if they mismatch, it will reject the connection. This is why I added the "mail.transistor.one" hostname in there, as my TLS certificate is against all subdomains under *.transistor.one and, as such, can be verified successfully by it**. When configuring each individual docker service, enter that IP as the IP of the SMTP server to use, as well as port 25, as its connection port. These should be the only parameters you should need to configure everything to work properly. 172.16.0.1 was a random address that I decided on. Really, it has no real relevance and can be changed to any private IPv4 address, whether in class B, C or A. The only point is that it should be reachable through this network driver.
99	99
	125	+= Instructing Postfix to relay emails through Google's servers, instead =
	126	+Assuming that running your own postfix server is a pain in the ass (especially since it's quite difficult to get DMARC or other authenticity mechanisms configured by yourself), a proper workaround for that is to simply rely on a third party emailing service to relay your emails for you.
100	100
	128	+This has the benefit of being somewhat easier to use and configure, but with the obvious downside that you will need to have an already existing email address on that service to send the emails through.
	129	+
	130	+To the recipients receiving those emails, it will look like the sender of those emails is that existing email address that you'll be using.
	131	+
	132	+So, how do we achieve this?
	133	+
	134	+I'm personally using my Gmail account for this. The way I configured it is as follows:
	135	+
	136	+{{code language="ini"}}
	137	+relayhost = [smtp.gmail.com]:587
	138	+smtp_use_tls = yes
	139	+smtp_sasl_auth_enable = yes
	140	+smtp_sasl_security_options =
	141	+smtp_sasl_password_maps = hash:/etc/postfix/config
	142	+smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
	143	+{{/code}}
	144	+
	145	+The above code was appended to the "/etc/postfix/main.cf" configuration file, at the end. It specifies a bunch of necessary configurations, but the most relevant for them is:
	146	+
	147	+* The relayhost: this specifies the SMTP server itself that needs to relay the email. including the port. This is Google's own SMTP address
	148	+* smtp_sasl_password_maps: this specifies the local filesystem file that contains the login credentials that need to be used to authenticate with
	149	+Google only allows authenticated services to relay email through their own servers, so the authentication part cannot be skipped. Also, Google requires app passwords to be used when authenticating, not the actual Gmail password of your Google account. App passwords must be manually generated by the end user and, as I've recently found out, are meant to be used only once per app. The system is designed in such a way that the password gets generated once, is meant to be copy-pasted into wherever the configuration requires it, and then be left alone. As such, you will **be unable to later inspect the app password that you've previously generated, even though this password may still be valid and in use**.
	150	+
	151	+The contents of my "/etc/postfix/config" file looks like this:
	152	+[smtp.gmail.com]:587 <username@gmail.com>:<app_password>
	153	+I think I might have needed to generate this file using a postfix utility or something, although I'll assume that writing it by hand can also work.
	154	+
	155	+Once this is configured and ready to go, you can safely restart the postfix service and rely on Google to relay your emails for you.
	156	+
	157	+= Configuring the Postfix service such that it always restarts when the system is running low on RAM =
	158	+This has been a major pain in the butt for me.
	159	+
	160	+Every so often, I would visit one of my services after a long period of being away and then would request for a password to be delivered to me from them, only to then find out that no email is being received.
	161	+
	162	+I would then SSH into my VPS, only to discover that Postfix had been killed at some point in the past due to low RAM.
	163	+
	164	+Granted, this is by no means ideal, and it can be very annoying, having to manually restart the Postfix service every single time.
	165	+
	166	+To solve this, I've rewritten my Postfix service file to account for this. Its location (for me at least) was under /etc/systemd/system/multi-user.target.wants/postfix.service
	167	+
	168	+{{code language="Systemd"}}
	169	+[Unit]
	170	+Description=Postfix Mail Transport Agent
	171	+Conflicts=sendmail.service exim4.service
	172	+ConditionPathExists=/etc/postfix/main.cf
	173	+
	174	+[Service]
	175	+Type=oneshot
	176	+RemainAfterExit=yes
	177	+ExecStart=/bin/true
	178	+ExecReload=/bin/true
	179	+Restart=on-failure
	180	+RestartSec=1s
	181	+{{/code}}
	182	+
	183	+From that, the only genuinely relevant changes that need to be highlighted are the last two lines (i.e. the "Restart" and "RestartSec" assignments). These tell systemd that that, in the event that the service gets killed due to an abnormality (i.e. it receives a SIGKILL system because it is running low on RAM), to automatically restart it. The second rule (i.e. "RestartSec"), tells it to wait an entire second before performing the restart, so that it gives the system the chance to finish whatever it was doing.
	184	+
101	101	= Troubleshooting issues with Postfix reachability from docker containers=
102	102	If whichever docker container you're currently running doesn't seem to connect to 172.17.0.1 and its image contains the ping utility pre-installed in it, you can attach your current terminal session into that container and access it via "docker exec -it <docker_container_id> /bin/bash" and then simply issuing a "ping 172.17.0.1" to send ICMP echo packets to your SMTP server from inside the container itself. If there are replies, this means the container can reach your local Postfix server so the problem is most likely from Postfix dropping the requests intentionally. Alternatively, this could be a firewall misconfiguration problem but this has never happened to me before, although I recognize that it may be theoretically possible.
103	103