Skip to Content
Last modified by Alexandru Pentilescu on 2025/02/09 14:17
From version 6.1
edited by Alexandru Pentilescu
on 2024/05/19 13:48
Change comment: There is no comment for this version
To version 2.1
edited by Alexandru Pentilescu
on 2022/11/13 20:58
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -51,8 +51,8 @@
51 51  
52 52  {{code language="ini"}}
53 53  # TLS parameters
54 -smtpd_tls_cert_file=/etc/letsencrypt/live/transistor.one/fullchain.pem
55 -smtpd_tls_key_file=/etc/letsencrypt/live/transistor.one/privkey.pem
54 +smtpd_tls_cert_file=/etc/letsencrypt/live/pentilescu.com/fullchain.pem
55 +smtpd_tls_key_file=/etc/letsencrypt/live/pentilescu.com/privkey.pem
56 56  smtpd_use_tls=yes
57 57  smtpd_tls_security_level=may
58 58  {{/code}}
... ... @@ -68,10 +68,10 @@
68 68  {{code language="ini"}}
69 69  # TLS parameters
70 70  smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
71 -myhostname = transistor.one
71 +myhostname = pentilescu.com
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 mail.transistor.one
74 +inet_interfaces = 127.0.0.1 172.16.0.1
75 75  inet_protocols = all
76 76  {{/code}}
77 77  
... ... @@ -89,15 +89,13 @@
89 89  
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.-- 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.
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.
93 93  
94 -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.
95 -
96 96  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.
97 97  
98 98  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.
99 99  
100 -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.
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.17.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.17.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.
101 101  
102 102  
103 103  = Troubleshooting issues with Postfix reachability from docker containers=