On 07.09.13 09:44, Óscar Pereira 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...
No, the "logic" which you have constructed there in unconvincing, due to being erroneous. We use an editor to create the text for an email, so it needs to read and write the encrypted postponed file - mutt is not involved, beyond finding the file for the editor. On the other hand, we use mutt to read received emails - no editor is involved normally. So your postulate is false, due to there being no connection between the two processes. What you have seem to have missed is that the editor is not encrypting the email for transmission. Mutt still does that. To this end, it is necessary for the user to save the file unencrypted to the tmp file for transmission, since encryption for transmission is mutt's job. (A finger fumble here would send a doubly encrypted email, just as would happen if the (encrypted) postponed file were attached by mutt without the involvement of an editor.) It might be convenient to add a pair of mappings to .vimrc, to more fluently deal with postponing and posting, respectively. > Mutt's job is to handle emails, The file is not yet an email while it is postponed - it is just a file. It becomes an email only after it is handed over to mutt. It follows that local encryption may be handled by any desired local means. > and if those are received encrypted, Yes, that is obviously mutt's job. > or are to be stored encrypted, then dealing with that is (or ought to > be) mutt's job. No. Just because mutt encrypts for transmission does not obligate it to encrypt other files which might or might not later be transmitted. This is where you are conflating two separate tasks. Another proposal on this thread was complete disk encryption. Hopefully you do not see that as mutt's job? Nor is local encryption of selected files. > 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... Lack of understanding is resulting in a flawed perspective, I submit. (And describing an offered potential real-world fix for a posted problem as "very bad design" is hardly helpful. Perhaps you can tell us what it contributes?) What may be helpful to the OP is something which can work now, albeit with the need to whack something in the editor to choose whether we are postponing or posting. Erik -- On the basis of evidence we may be sure that we are wrong but we can never be sure that we are right. - Richard Feynman
