Re: Encrypting postponed messages
Hello, On Sun, Sep 08, 2013 at 08:14:47PM -0400, Tim Gray wrote: > encrypting a mutt draft in Vim. You encrypt it, > then save the file, and once you are back in > mutt, postpone the message. It worked fine, as > long as you are ok with all the mail headers > being encrypted and thus inaccessible to mutt > when you recall the draft. Just my 2c worth: I use encrypted physical volumes or cryptoloop devices for storing sensitive files (almost all of my files BTW except for initrd, vmlinuz, bootloader conf and stages). If you want to encrypt =postponed separately, maybe it's possible to do via encrypt/decrypt (mount/umount) hooks rather than GPG? -- With best regards, xrgtn signature.asc Description: Digital signature
Re: Encrypting postponed messages
On Sep 09, 2013 at 02:31 AM +1000, Erik Christiansen wrote: That would remove the editor choice restriction, and so would be more universal once it exits. Added to that, draft encryption integrated into mutt uses less keystrokes and requires less user concentration than encryption provided by the editor. I don't really have a dog in this fight, but I can say this. I was playing around with encryption recently and tried out encrypting a mutt draft in Vim. You encrypt it, then save the file, and once you are back in mutt, postpone the message. It worked fine, as long as you are ok with all the mail headers being encrypted and thus inaccessible to mutt when you recall the draft. I have no idea how offlineimap or isync would have dealt with the file, since it certainly wasn't in the right format for an email message. I also concur, draft encryption in mutt would be easier to use. It would also prevent having several types of encryption being used at the same time.
Re: Encrypting postponed messages
On Sunday 08 Sep 2013 17:31:43 Erik Christiansen wrote: > On 08.09.13 14:59, Christian Brabandt wrote: > > Vim certainly could and Emacs probably can encrypt. But what about Nano, > > pico, mcedit, gedit, kate? Therefore, I think, it is still mutt's > > responsibility to encrypt the file. > > G'day Christian, > > That would remove the editor choice restriction, and so would be more > universal once it exits. Added to that, draft encryption integrated > into mutt uses less keystrokes and requires less user concentration than > encryption provided by the editor. > > It would however, be necessary for mutt to interpose encryption in the > datapath to the tmp file, not the "postponed" file, or the security risk > would remain, if intermittently. Since plaintext can only be permitted > within the editor and at the mutt-editor interface, I still think that > the issue of "responsibility to encrypt" could go either way. (I'm having > trouble imagining a gpg user editing with nano. Is there a mutt user who > does, I wonder?) Yep, I had more than once, on machine(s) with no vim. I've never managed to learn how to use emacs, but as they say it's never tool late to learn to play the piano! :p -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: Encrypting postponed messages
On 08.09.13 14:59, Christian Brabandt wrote: > Vim certainly could and Emacs probably can encrypt. But what about Nano, > pico, mcedit, gedit, kate? Therefore, I think, it is still mutt's > responsibility to encrypt the file. G'day Christian, That would remove the editor choice restriction, and so would be more universal once it exits. Added to that, draft encryption integrated into mutt uses less keystrokes and requires less user concentration than encryption provided by the editor. It would however, be necessary for mutt to interpose encryption in the datapath to the tmp file, not the "postponed" file, or the security risk would remain, if intermittently. Since plaintext can only be permitted within the editor and at the mutt-editor interface, I still think that the issue of "responsibility to encrypt" could go either way. (I'm having trouble imagining a gpg user editing with nano. Is there a mutt user who does, I wonder?) Erik -- Wizards had always known that the act of observation changed the thing that was observed, and sometimes forgot that it also changed the observer too. Terry Pratchett - Interesting times
Re: Encrypting postponed messages
Hi Erik! On So, 08 Sep 2013, Erik Christiansen wrote: > On 07.09.13 14:40, Christian Brabandt wrote: > > > 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. > > > > Yes it does, since mutt manages a mail store. Just because the mail ends > > up saved locally, doesn't mean it always will and only mutt knows, > > whether the mail will be send or postponed or moved to trash or similar. > > As described above, and in other posts on this thread, I'm only > suggesting that vim provide encryption of drafts, leaving mutt to do all > that it can, including making it entirely unnecessary for the editor to > know the location of the tmp file, no matter where it is. (I hope that > red herring is dead now.) Mutt's post/postpone dialog remains, but when > using an editor for non-integrated draft encryption, we need to _also_ > communicate that decision before leaving the editor, because mutt can't > do the job afterwards. > > OK, mutt is demonstrably not obligated to edit drafts, and it cannot > currently encrypt them, but at least one editor can. Giving mutt the > ability would be easier to drive, so must be a better long term solution. > If mutt is now deemed to be obligated to do it, then it will doubtless > happen soon. Vim certainly could and Emacs probably can encrypt. But what about Nano, pico, mcedit, gedit, kate? Therefore, I think, it is still mutt's responsibility to encrypt the file. regards, Christian -- Life is a yo-yo, and mankind ties knots in the string.
