Skip to Content
Last modified by Alexandru Pentilescu on 2025/02/09 14:17
From version 9.1
edited by Alexandru Pentilescu
on 2024/05/19 14:30
Change comment: There is no comment for this version
To version 12.1
edited by Alexandru Pentilescu
on 2024/05/19 14:48
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -184,8 +184,37 @@
184 184  
185 185  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.
186 186  
187 += Opening up port 587 for SMTP traffic =
188 +Certain services refuse to accept STARTTLS traffic on port 25, as is open, by default, on Postfix (looking at you, Gitea). To account for them, we must open port 587 to attain this. To do so, we must open the master.cf configuration file (mine was under "/etc/postfix/master.cf") and add the following line:
189 +
190 +{{code}}
191 +smtp inet n - y - - smtpd
192 +587 inet n - n - - smtpd
193 +{{/code}}
194 +
195 +The smtp line was already there. I only added the 587 line. This instructs Postfix to bind itself to the 587 port, such that, any services wanting to reach that port in order to start a STARTTLS connection, wil be able to do so.
196 +
197 +Once this is done, restart the Postfix daemon with a systemctl restart command and everything should almost be done. Almost.
198 +
199 +Ubuntu server also comes preinstalled with a firewall utility that will deny traffic towards its own port 587. This can be an impediment. As such, please allow traffic from your docker containers to be able to reach this port:
200 +
201 +{{code language="bash"}}
202 +sudo ufw allow from 172.16.0.0/16 to any port 587
203 +{{/code}}
204 +
205 +If you recall from above, 172.16.0.0/16 was the IP range we configured for our docker engine to use when assigning IPs to its container networks. So that command will effectively allow all traffic originating from docker containers to be explicitly allowed to reach the host's own 587 port, to be able to initiate a STARTTLS encrypted channel.
206 +
207 +While you're on it, you may also do
208 +
209 +{{code language="bash"}}
210 +sudo ufw status numbered
211 +sudo ufw delete <rule number for opening port 25>
212 +{{/code}}
213 +
214 +to delete the firewall rules that allow full access to port 25. This solved an issue where Google would spam my Gmail inbox with unnecessary garbage because it was trying to relay bounced email notifications to me, which was highly annoying to say the least.
215 +
187 187  = Troubleshooting issues with Postfix reachability from docker containers=
188 -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.
217 +If whichever docker container you're currently running doesn't seem to connect to 172.17.0.1 or to mail.transistor.one 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.
189 189  
190 190  To further validate this, issue the following command to see the last log error reports from Postfix, including the notifications of rejected requests:
191 191  
... ... @@ -195,7 +195,14 @@
195 195  
196 196  Note, you need sudo privileges to read the mail.log file, as it is owned by the syslog user and it has restricted reading privileges.
197 197  
227 +Finally, to get further in depth into this matter, you can run:
198 198  
229 +{{code language="bash"}}
230 +docker run --rm busybox telnet mail.transistor.one:587
231 +{{/code}}
232 +
233 +To see if port 587 on localhost is reachable from within a docker container. If it is, this utility should be able to confirm it. Otherwise it will print an error message.
234 +
199 199  = Wrapping it up=
200 200  That's it! As soon as you finish editing the main configuration file, please remember to restart the Postfix service afterwards so that the changes can take effect immediately (or reboot the machine).
201 201