Yeah exactly, The local instances also don't need to listen on the standard TCP ports, since they are always only getting email from the cloud VM. So the firewalls whitelist the cloud VM's IP and the email is coming in via non-standard ports so I don't have a horde of botnets trying to deliver garbage to my local Postfix/Dovecot sites. The cloud VM gets the pleasure of dealing with that.
It's a little unusual but it's worked for me for a couple of years now. Private DNS points "mail.opendmz.com" to a local IP, and public DNS points to the cloud where Haproxy is always listening and will proxy the IMAP connection back to one of the local sites (again, non-standard ports and whitelisted IP) It's nowhere perfect but I don't know what is. On 09/06/2019 23:38, Antonio Leding wrote: > Just practicing the Au-rule…treat other as… :=) > > I would definitely agree NAT buys some security via obscurity…cheap, fairly > easy, and does help to a degree. So with the haproxy, am I understanding > correctly that it will spin up (or already has running) IMAP back to your > local site for when you’re say, on the Int’l Space Station, and need to get > email? > > Kinda cool... > > > > > >> On Jun 9, 2019, at 3:31 PM, cvandesa...@opendmz.com wrote: >> >> Ha be critical if you want, I don't mind at all :P >> >> The main reason was reliability, as someone who's always >> breaking/rebuilding but also hosts their own email, I needed the email >> to spool somewhere in case I broke something for more than a few days. >> >> The local PF boxes are behind home NAT connections with whichever >> firewall I felt like trying out at the time. More secure? I don't know >> maybe/hopefully? >> >> Having the spam check done on the cloud for the same reasons. Every time >> I broke the server running the spam filter, it was like opening the >> flood gates :D >> >> For flexibility there's another element I didn't bother to mention... >> >> The same cloud VM runs haproxy which will loadbalance IMAPS connections >> back to either of the 2 local Dovecot sites. So I always have access to >> my email wherever I happen to find myself. >> >> Chris. >> >> >> On 09/06/2019 23:19, Antonio Leding wrote: >>> Hi Chris, >>> >>> Not being critical but really just want to understand why you architected >>> it the way you did… >>> >>> Are your local PF boxes behind a more secure border than your cloud based >>> PF server? I understand the SPAM part of the design — or I think I do :=) >>> — it seems like you just feel more comfortable performing SPAM analysis in >>> the cloud vs. inside your border…but curious in terms of other infosec… >>> >>> Also, did you implement pinholes on your local side so you can access mail >>> from different locations or just opt to not have that flexibility? >>> >>> >>> >>>> On Jun 9, 2019, at 3:12 PM, cvandesa...@opendmz.com wrote: >>>> >>>> Maybe something like I'm doing? >>>> >>>> I have 3 instances of postfix running (because I travel) but this can >>>> work with 2. >>>> 1 server in the cloud, 2 locally one home one office. >>>> >>>> The 2 local postfix instances only accept public email from the cloud >>>> VM, but they accept local email (ipcam's, for example on the LAN). >>>> >>>> The MX record points to the cloud VM, should it pass the spam test then >>>> the 'clean' email is relayed to 1 of the 2 local postfix servers. >>>> The local servers then deliver to a local Dovecot, where I access my >>>> email from a local private IP on the LAN. >>>> >>>> Think of the flow like this. >>>> >>>> public email > Cloud VM (postscreen/rspamd test passes) > local Postfix >>>>> local Dovecot. >>>> Whichever local Dovecot received the message with replicate to the other >>>> site. >>>> >>>> I think of it this way, the email is coming from the public internet, so >>>> scan it while it's out on the public internet. >>>> >>>> If it passes the test, then it's considered 'good enough' to be >>>> delivered to one of the local servers. >>>> >>>> Internal email like ipcam's, server emails never leave the local LAN >>>> (except to be replicated to the other local site). >>>> >>>> Hope that makes sense. >>>> >>>> Chris. >>>> >>>> >>>> On 09/06/2019 23:00, Antonio Leding wrote: >>>>> AHHH - yes, thank you Paul - I did mean “cloud” based Postfix… >>>>> >>>>> >>>>> >>>>>> On Jun 9, 2019, at 2:53 PM, Pau Amma <paua...@gundo.com> wrote: >>>>>> >>>>>> On Sun, June 9, 2019 9:29 pm, Ronald F. Guilmette wrote: >>>>>>> In message >>>>>>> <0100016b3e069855-f95cf3e2-9649-4a55-8290-24a9d44f80cc-000000@email. >>>>>>> amazonses.com>, Antonio Leding <t...@leding.net> wrote: >>>>>>> >>>>>>>> Just curious any reason to not use use the could-based Postfix >>>>>>>> server + something like Dovecot and then have your clients access that >>>>>>>> directly? I have this now for at least 20 domains and it works >>>>>>>> awesome. >>>>>>> Firstly, I have no idea what you mean by "could-based Postfix". Was >>>>>>> that >>>>>>> a typo? What did you mean, actually? >>>>>> I'm guessing "could" is a typo (or perhaps autocorrection) for "cloud". >>>>>>
