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

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

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.


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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to