Yeah - good stuff…I like it… I checked out the haproxy site and am conjuring ways to put it to use…very cool...Thanks…
> On Jun 9, 2019, at 3:48 PM, cvandesa...@opendmz.com wrote: > > 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". >>>>>>>
