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.
That seems like an odd figuring to me: > I use vim within mutt But you can't assume anyone else does. You can choose any editor for use with Mutt, and there are many, many editors which have zero support for encryption. > and it is the editor which needs to handle encrypted files, using > whatever method(s) it offers. Why? The editor was called by Mutt, on behalf of Mutt, to enable the user to generate the content of his e-mail, explicitly for that purpose. The editor has no knowledge of the fact that the user wants to use the resulting text as the body of his e-mail, nor that he wants unfinished e-mails to be encrypted. But Mutt, as the instigator of the process, CAN know that. It makes no sense to put the burden for this on the editor. On Sat, Sep 07, 2013 at 07:51:41PM +1000, Erik Christiansen wrote: > 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. False. Mutt launches the editor as a surrogate for itself, since it provides no functionality to create the content of the e-mail message which the user wants to compose. Mutt then takes the product of the editor, perhaps doing some minor reformatting as required to conform with RFC (2)822 and slapping on some extra headers, and then calls a mail delivery agent to send the message. Mutt is a broker, and the editor, like every other program it launches, is spawned as an agent of Mutt, to provide functionality that it inherently lacks (by design--this isn't necessarily a flaw, though it can be). Mutt is VERY involved, from start to finish, as one would expect--this is its reason for being. But it makes very few assumptions about the capabilities of the programs it uses as the agents of its task, and neither should you. It assumes ONLY that your editor will produce a file it can use as the body of your message. It makes no assumptions about any encryption capabilities of your editor; it handles all aspects of encrypting your messages. Except this one. [...] > (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.) Only if the guy who implemented the function were a moron... Mutt can, should, and would detect that the postponed e-mail was encrypted, and decrypt it first... just as it already does with received encrypted e-mails. > 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. This is utter nonsense. It IS an e-mail, and what makes it an e-mail is the user's intent to send it as one, in combination with Mutt's initiation of your editor so you could create it. If it were TRULY "just a file" then Mutt wouldn't have ever been involved in the initiation of the creation of its content. It IS Mutt's job to make sure that either it, or some other program on its behalf, handles all aspects of the user's e-mail, from its initial creation to its eventual injection into the mail system, and everything in between. Postponing an e-mail message, encrypted or not, is absolutely part of that. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgp6kUggtfHI5.pgp
Description: PGP signature
