<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body><div>While this is true, it can be useful to encrypt messages in-rest at 3rd party storage.</div><div><br></div><div>For end user, only PGP or similar provides sufficient security against admin.</div><div><br></div><div id="composer_signature"><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">---<div>Aki Tuomi</div><div>Dovecot oy</div></div><div><br></div><div style="font-size:100%;color:#000000"><!-- originalMessage --><div>-------- Original message --------</div><div>From: "M. Balridge" <dovecot@r.paypc.com> </div><div>Date: 11/08/2018 13:56 (GMT+02:00) </div><div>To: Dovecot Mailing List <dovecot@dovecot.org> </div><div>Subject: Re: [trees-plugin] - Dovecot index gets corrupted,
when using maildir and recievend and accessing mail at the same time </div><div><br></div></div>Quoting Joseph Tam <jtam.home@gmail.com>:<br><br>> Another privacy plugin that assumes the server operator is unmotivated or<br>> respects your privacy anyways, and won't just skim your password right off<br>> the top to look at your mail. A vault with steel walls and a dirt floor.<br><br>*SIGH* As usual, you're right on the money, Joseph.<br><br>I used to let things like this "slide", but somewhat recently I've had some<br>clients badgering me to implement something like this. It takes longer than it<br>should to explain how pointless the exercise is.<br><br>Given that:<br><br>1) Email transactions, from submission, to delivery, to final reception by a<br>MUA, are done with plaintext contents. Those who want security, will undergo<br>the additional steps and hassles with using PGP to encrypt the contents,<br>providing the only demonstrably secure (against "Evil SysAdmins") means of<br>cloaking your content. The submission, delivery, and final reception is still<br>performed as "plaintext", albeit with an attachment that is encrypted, a<br>process done (and undone) by the ultimate endpoint clients.<br><br>2) Even if the "Evil SysAdmin" doesn't scribble all of the users' passphrases<br>into a log, it's trivial for various tools, many of which were hastily cobbled<br>together during the fad of implementing Sarbanes-Oxley Act (SOX) compliance on<br>mail servers. Tools like "milter-bcc" and friends which automatically clone<br>all email submitted to or arriving through SMTP, etc. It doesn't matter if<br>your SMTP software implements 65,536 Jiggabyte Key Quantum-Computing-Resistant<br>crypto, when it has the decrypted contents in its spool.<br><br>I imagine this is an exercise in buzzword collection, and to be seen to be<br>"doing something" to improve security and/or privacy.<br><br>If privacy is desired, there are only end-to-end encryption/signature schemes<br>to ensure anything at all, and even there we're at the mercy of mathematical<br>gods greater than we.<br><br>Looking to a "magical" oracle on your server to do it for you, whilst keeping<br>all of the leaky, plaintext, and promiscuous protocols (DSN, bounces,<br>intermediate MXer hosts that eruct contents to various envelope addresses,<br>etc) that will betray you behind your back without a moment's notice is a<br>Fool's Errand.<br><br>Think it over.<br><br>=M=<br><br></body></html>