Still running your self-hosted on your residential IP? 
Hey! this is actually a business-grade connection, and one of the other IPs on the /28 is used for an Exchange server…so I know e-mail can be sent from the IP block =). But yes, pedantry aside, this is a truly-self-hosted instance, rather than a VPS.
so you’ll have to open the hood and get your hands dirty.
That’s how we learn! =)
BTW PostfixAdmin purpose is for managing users & mailboxes, it won’t be of help here.
I was pretty sure that was the case. The reason I said it was more so to avoid being told “there’s a button for it in PFA, did you check in there before editing config files directly?” in the event the control happened to be there.
This is untested by me,
I thought you knew everything! 
however I’d try the following…
2: find a way to pass our configuration to the container
I find option 2 far way better, as it won’t interfere with future updates and keep initial configuration. It is also easier to rollback.
Same, for the same reasons.
Okay, but here comes the “How?” …
I’d try to add all the needed configuration in /mnt/repo-base/volumes/mail/postfix/custom.conf file, then restart the container (docker-compose restart mailserver)
So, I am writing here because my very first attempt was a swing-and-a-miss. Here’s my config file:
biff = no
append_dot_mydomain = no
readme_directory = no
compatibility_level = 3.6
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_security_level=may
smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = localhost
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = $myhostname, localhost, localhost.localdomain, , localhost
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
relayhost = 192.168.1.1:25
relay_destination_concurrency_limit = 10
To which, the entire free world says “ehm…voyager…you had ONE JOB!” I know…bear with me.
First, I tried the config file both ways - one variant with just the relayhost and concurrency parameters set, and one full config file that was a copy/paste of everything already in the main.cf, since the documentation was a bit ambiguous as to whether the custom.conf file appended the main.cf contents, or replaced it. The behavior was the same either way.
Part of my plan to test it, is the fact that the router in front of the server is a Sophos UTM appliance, which does perform SMTP relaying as well as spam filtering. I was curious if I could just use the UTM instead of SMTP2Go, not because I had an issue with the service, but because it seemed like a good first step because there were only two steps involved - enable the relay, and add the server IP to the allow list.
Well, interestingly enough, the Sophos firewall doesn’t seem to show any attempts, passed or failed, at relaying mail through it.
This obviously calls for some more testing. Will SMTP2Go do a better job? Do I need to look at more granular Sophos logs? Can we get more information from the Postfix logs about its attempts?
Stay tuned to find out!!
Thank you so much for the pointers thus far. I’m looking forward to providing de facto documentation for future /e/Cloud users, especially those of us who believe ‘my data is MY data’ applies best when we own the servers 