On Thursday, March 8, 2018 at 2:55:18 AM UTC+1, [ 799 ] wrote: > Hello, > > > > Am 06.03.2018 10:04 nachm. schrieb "Steve Coleman" > Because the SMTP infrastructure was not designed with compartmentalization in > mind, and I only get my one email account to work with, this single "email" > VM is highly isolated. It gets its own software locked down configuration and > is firewalled with a default-deny network policy. The only services that this > VM can get to on the network is the required SMTP services, network > authentication, and the necessary signing key management. No internal > websites, no external sites, only the email App runs here. Well, Ok, the > calendar too. Anyway, there should be no "phoning home" from here, other than > through per use 2fa outbound email. Should any rouge malware be received, all > attachments are first scanned and "tested" in a DVM instance before being > separated and pushed across to the appropriate project VM for storage > management. All project related historical emails are then migrated to an > off-line but searchable storage by project. This specialized email VM > essentially sorts, filters, prioritizes, and bins any incoming data/mail for > easy processing. > > > > Do you mind writing some more details as I am interested how other people > solve the email problem. > Are you really separating email in different AppVMs? > Even when you said, that the VM can only connect per SMTP I assume that you > are not separating IMAP (incoming) and SMTP (outgoing) into two two VMs and > then moving emails from the incoming mail VM to the offline mail VM? > You have one VM which makes both IMAP and SMTP correct? > Which email/calendar client are you using and how do you move mails to your > offline email VM? > > > My setup: > Dedicated Email VM with Davmail installed. Davmail connects per OWA to our > corporate Microsoft Exchange Server and acts as some kind of gateway to > provide local SMTP/IMAP/CardDAV/CalDAV connections. > For emails I am running offlineimap which connects locally to Davmail and > downloads all emails and creates a local maildir-repository. > Contacts and calendar entries are downloaded via vdirsyncer. > All content is now locally available in this Email-AppVM and can now also be > used offline. > Within this VM I have setup: > For plaintext work: > - neomutt - email client > - khal - calendar > - khard - adressbook > - notmuch - fast search > > > And as GUI email clients (connecting to the Davmail gateway / not using the > maildir-repository) > - Evolution > - Thunderbird > > > Unfortunately not everything works with the Davmail Gateway: > I can see the exchange Calendar in Thunderbird, but not the calendars of my > colleques. If I open a calendar entry I get an error. > On Evolution calendar is working much better as I can open and view the > details of an calendar entry, I can create and edit calendar entries - > everything is synced per Davmail to our corporate Exchange. > Strangely I can not delete calendar entries in Evolution. > > > With khal I can also view/edit my calendar entries in the terminal. > Same for khard with my contacts. > > > Todo: > 1) Check why I can add/edit calendar entries but not delete them > > > 2) optimize handling of attachments that PDFs / Office documents / Weblinks > are always opened in a DVM. > I have been able to do this for Thunderbird but not yet for neomutt and > Evolution. > > > 3) I'd like to integrate email and calendar into emacs org-mode, which I am > more and more using for PIM. > > > 4) lock down EmailAppVM so that it can only access the Microsoft Exchange > Mailserver nothing more. > I would do so by running IPtables within the VM with a default > incoming/outgoing DROP policy only adding what is absolutely necessary to get > mail/contacts/calendar working with the Exchange server > > > I have also thought about separating email into more AppVMs but the usability > trade-off seems to high without gaining that much security. > As the Email AppVM only is used for email/calendar it should have the same > security level like our Exchange Server. If it gets compromise it doesn't > make a difference what I have setup in Qubes. > > > [799]
I do something similar yeah, although I haven't taken it was far as I'd like to yet, and you guys also bring up some interesting fresh ideas as well that I will follow up on and read later. I currently have 5 different AppVM's for different mail accounts. But 3 of them are only checked when I'm actively spending time work related to them, which is nice because I don't need to receive those emails when not in that work-mode anyway, so I don't get disturbed. I've been thinking about the one direction firewall systems too, i.e. only allow in on one AppVM, and only allow out on another AppVM. But man.... it's a lot of AppVM's to do something like that, especially when I already got 5 e-mail AppVM's, it'd essentially double it to 10 AppVM's. But then again, it doesn't cause me issues to have many AppVM's as long as I have drive space, I use XFCE4 launchers to start my AppVM's, and I don't use the Qube Manager anymore anyhow, so a long list of AppVM's won't feel cluttered to me. The only remaining problem then, would be to have a CPU fast enough to make start of e-mail VM's feel almost like no time wasted, and then enough RAM (for example 8GB is a bit on the low side, too many new laptops are still 8GB as well). To smooth something like that out though, it'd probably be nice to have a Qubes tools of sorts, to make two AppVM's act similar to how split bitcoin and split GPG works in Qubes; https://www.qubes-os.org/doc/split-bitcoin/ and https://www.qubes-os.org/doc/split-gpg/ But it could work without, albeit a bit on the wacky side of things with extra management without a hypothetical Qubes mail tools to make two AppVM's work together here :/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9356449d-9e4a-4122-a487-f35964257720%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
