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] -- 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/CAJ3yz2txubQV8-Btuxje%2BFvfT5aq8aLHdxjnBRhVBRkFOLz6bw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
