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". >>>>
