On 07.09.13 14:40, Christian Brabandt wrote: > Hi Erik! G'day Christian. A thoughtful response is most welcome.
> On Sa, 07 Sep 2013, Erik Christiansen wrote: > > 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. > > You are being serious here? Yes. The two paragraphs exist in the same context. Further detail (below) should clarify. > mutt spawns the editor with some template file that is lying around in > some tmp/ folder. Yes, that is what I (perhaps too briefly) alluded to in the paragraph quoted above. Writing to that tmp file is entirely under editor control, with mutt providing only a temporary filename and a transparent pipe. E.g. while editing this draft with vim within mutt, we see that it was started at: -rw------- 1 erik erik 3697 2013-09-08 00:19 Desktop/mutt-ratatosk-1000-1969-8668182371718234968 And after hitting :w in vim: -rw------- 1 erik erik 4256 2013-09-08 00:49 Desktop/mutt-ratatosk-1000-1969-8668182371718234968 Clearly, if we are to use vim to provide encryption of drafts (because mutt lacks the facility), then both encrypted and unencrypted writes must be conveniently available in vim, for postponing and posting, respectively. The mappings ought also exit vim, for greater convenience. On returning to mutt, we have to remain consistent with that decision, otherwise we will hand over a blowfish encryption for further encryption prior to sending, or postpone an unencrypted file. Clearly, an integrated mutt solution is distinctly to be preferred, if it materialises. I assumed, apparently incorrectly, that something which might provide immediate draft file security would be welcome enough to be worth examining. > After you have finished writing the file and quit the editor, mutt > reads that temporary file (probably also unlinks it already) and asks > you what to do with it (e.g. postpone, send, etc.) At that dialog, you > can also chose whether to encrypt the mail or not > (sign/encrypt+sign,etc). And if you decide to encrypt the mail, it is > mutt's responsibility to do so (which it should possibly also do, when > the mail will be postponed). Fully understood and taken into consideration. There is nothing there contrary to my postings. > I don't see, how your editor comes to mind here, especially, since > your editor doesn't even know where to save postponed mails. Firstly, it knows all that it needs to, since mutt provides the pipe. It has to "fluently deal with postponing and posting", because we must tell it to encrypt or not, before we exit. A pair of mappings could reduce the keystrokes, which are already in excess of what would be needed if mutt could do the job. (Is that making it easier to synchronise brainwaves? The phase difference is miniscule, actually.) > > > Mutt's job is to handle emails, > > Exactly > > > 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. > > > 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. > > It seems to me, you lack some understanding here ;) Where? Please substantiate. ;-) Perhaps something other than what I have written has been inferred. Additional descriptive detail might have avoided that, but I thought the audience sufficiently expert for that to be unnecessary. Sorry. Erik -- A computer is like an air conditioner, it works poorly when you open Windows.
