On Fri, Dec 23, 2022 at 06:20:08PM +0100, Gerben Wierda <gerben.wie...@rna.nl> wrote:
> I ran Mac OS X Server for years, then, when Apple dropped mail > service, I switched to MacPorts so I could still do all my server > stuff (macOS-specific and standard unix) on a single server. So, I > am still running my postfix on macOS now (with DKIM, using LE certs, > reverse DNS for my mail fqdn, etc.). > > I'm forced to move away as macOS has become too untrustworthy and > too different to be a good platform for stuff like postfix, dovecot, > etc. Especially because everything Apple does with its security > model (e.g. signing, pf, alf) makes macOS unreliable for these more > Linux-permissions based approaches. > > So, I am planning to move postfix, dovecot, rspamd, etc. to a Linux > setup. I've already setup a VM host (PVE) and a Ubuntu LTS server and > some services are already running (mostly in docker containers, some > behind traefik v2). Learning Linux etc. is a learning curve, a lot is > (subtly) different from macOS. > > I am still using permit_mynetworks in my settings because the > alternative is that some untrustworthy clients (black boxes) in my > network need to store credentials — and I don't trust them with > that. So, I'm preventing open relay with smtpd_relay_restrictions > > Here is the permissions structure (yes I know, there are some double > checks here) > > smtpd_helo_required = yes > unverified_recipient_reject_code = 550 > # reject_unknown_reverse_client_hostname rejects IP clients without a name > # but doesn't demand both to be in sync and gives a 4xx (try again) response > smtpd_client_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > check_client_access > regexp:/opt/local/etc/postfix/rna_rbl_whitelist_clients, > reject_unknown_reverse_client_hostname, > reject_rbl_client zen.spamhaus.org=127.0.0.[2..11], > permit > # Drop any SMTP client that talks before its turn (spam botnets in a hurry) > postscreen_greet_action = drop > # Drop any SMTP client that is in the DNSBL > postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..11] > postscreen_dnsbl_action = drop > smtpd_delay_reject = yes > smtpd_helo_restrictions = > permit_mynetworks, > reject_non_fqdn_helo_hostname, > reject_invalid_helo_hostname, > permit > smtpd_sender_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > reject_unknown_sender_domain > smtpd_relay_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > reject_unauth_destination > smtpd_recipient_restrictions = > reject_non_fqdn_recipient, > reject_unlisted_recipient > # with greylisting: > #smtpd_recipient_restrictions = > # reject_non_fqdn_recipient, > # reject_unlisted_recipient, > # check_client_access > regexp:/opt/local/etc/postfix/rna_policy_whitelist_clients, > # check_sender_access > regexp:/opt/local/etc//postfix/rna_policy_whitelist_senders, > # check_policy_service unix:private/policy permit > smtpd_data_restrictions = > reject_unauth_pipelining, > permit_mynetworks, > permit_sasl_authenticated, > reject_multi_recipient_bounce > > I wonder how to do this if I am running postfix in a docker container, > as docker will translate everything to its internal docker network and > permit_mynetworks would be a problem. The best thing would be if I can > tell postfix on the inside of docker what the original client IP was > on the outside of docker, but I have no idea how to do that. I can try > to setup multiple smtpd entries, one without permit_mynetworks and one > with and NAT the outside world to the one without permit_mynetworks. I'm not sure that that's correct. Client connections from remote servers sending email would still be whatever they are, wouldn't they? It's only the addresses inside the container that are in the container's own network. If you have a non-transparent proxy in the same container (like HAproxy, then you have a problem not knowing what the client addresses are). > What is the best way to do this? Or is it too troublesome and should > I just use postfix outside of docker, installing it with apt? I would > rather like to have a single (docker) deployment model which would > make it easier later to migrate once more. It's probably heretical, but I don't think Docker is well-suited to Postfix. You would need to configure Docker to map many UNIX domain sockets to allow Postfix's own processes to communicate with each other and with any milters and policy services. Docker seems to be primarily aimed at things that communicate only via TCP. But take that with a grain of salt. I am barely a Docker novice. I don't doubt that Postfix could be packaged up with Docker, and that would make migration easier, but so would Ansible. I prefer apt and automated security upgrades to immutable infrastructure. In general, that's silly, but Docker (and immutable infrastucture) makes more sense when you need many equivalent transient VMs, not a single, stable MX host. But of course, that's just my opinion. > BTW, I mentioned traefik but I will not be running postfix behind > traefik. I want postscreen to be the doorman on port 25 traffic. > > Thanks for tips and suggestions. > > Gerben Wierda (LinkedIn <https://www.linkedin.com/in/gerbenwierda>) > R&A IT Strategy <https://ea.rna.nl/> (main site) > Book: Chess and the Art of Enterprise Architecture > <https://ea.rna.nl/the-book/> > Book: Mastering ArchiMate <https://ea.rna.nl/the-book-edition-iii/> cheers, raf
