!-- On Sat 7.Sep'13 at 9:44:16 BST, Óscar Pereira (burn.till.s...@gmail.com), wrote:
> On Sat, Sep 07, 2013 at 06:13:20PM +1000, Erik Christiansen wrote: > > On 06.09.13 10:10, Derek Martin wrote: > > > If it's sensitive enough to be encrypted outgoing, it's sensitive > > > enough to be encrypted on disk... even if you haven't actually sent it > > > yet. > > > > That's entirely convincing, but it doesn't follow that this has anything > > to do with mutt, I figure. I use vim within mutt, and it is the editor > > which needs to handle encrypted files, using whatever method(s) it > > offers. Vim offers two levels of encryption - blowfish or zip. (OK, the > > latter hardly qualifies, so there's only one method of any real > > adequacy.) > > I don't think this is correct, because, by that logic, it would also > be the editor's responsibility to deal with (i.e. decrypt) received > encrypted emails... Mutt's job is to handle emails, and if those are > received encrypted, or are to be stored encrypted, then dealing with > that is (or ought to be) mutt's job. > > I speak from a user's perspective, but doing as you suggest strikes > me as a very bad design decision. But again, I speak as a user, so I > might be wrong... I completely agree here too. I use vi(1) for example; encrypting my email/text should not be done by that editor. Many users of mutt use different editors and so it wouldn't be sensible to expect the editor to encrypt the text in this scenario. After the email is written and the user is presented with the compose screen of mutt, there could be an option -- after you've chosen to postpone the sending -- to encrypt the draft using gnupg. I actually think this would be a really cool feature. The point Derek argued is really valid. I don't have my harddisk encrypted on all of my machines, and nor should I have to. But being able to encrypt the draft would be advantageous. -- James Griffin: jmz at kontrol.kode5.net A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38
