Mail-crypt plugin clarification

[Aki Tuomi]

> On December 15, 2017 at 2:29 AM Joseph Tam <jtam.home at gmail.com> wrote:
> 
> 
> Aki Tuomi writes:
> 
> > Dovecot does support making it difficult to prevent access to the stored
> > mail.
> 
> Those who have had problems understanding the documentation might find
> this unintended double-negative ironically funny.
> 

Indeed. Although we are open to improvements for the documentation, or even pointing out where it's wrong.

> > You can, with suitable workflows, ensure that the user's emails are not
> > readable by anyone but the user.  Of course the only way to be fully
> > sure is to use end-to-end encryption, ...
> 
> "Ensure" (or OP: "impossible") are very high standards of privacy.
> If the OP really means it, then since a third party has control over
> the (virtual or real) hardware, the server should never have access to
> private keys or decrypted data.  (We're in agreement I think.)
> 

You are quite right. The mail-crypt plugin cannot provide absolute guarantees that the data won't be accessible by sufficiently determined adversary, due to the fact that the keys are indeed on the server, or accessible by the server.

> If the OP lowers their standards to "inconvenient" to gain access,
> then the plugin is enough.  It will keep the honest admin honest.
> 
> > ... like PGP or S/MIME, but this does go a long way to prevent admin access
> > to user's email.
> 
> Don't ignore metadata; who/when/where (and headers?) could reveal much
> information.
> 
> Joseph Tam <jtam.home at gmail.com>

It's always all about who you are guarding against. I'd say that against your hosting provide, mail crypt can provide reasonable safeguards, especially if the storage is not on the same device.

The weak point is, as you point out, key management and handling, and special attention should be paid to this and I suggest clearly outlining the threats you are planning on mitigating and how the solution(s) you use achieve this.

Aki