Re: Encrypting postponed messages
Kevin J. McCarthy wrote: Sorry to resurrect an old (and somewhat heated) thread, but I'd like some feedback on the interface for a patch I'd like to push (attached, or see ticket #3665). The patch was based off the one submitted by Christian Brabandt, so thank you Christian! I've just pushed this patch upstream, with a binary postpone_encrypt option. Thanks everyone for your feedback! -Kevin signature.asc Description: PGP signature
Re: Encrypting postponed messages
++ 07/01/15 14:57 -0800 - Kevin J. McCarthy: I'm wondering if that is sufficient for people interested in the patch, or whether a quadoption for postpone_encrypt would be more useful. For a quadoption, I would keep the behaviour the same: the quadoption would only be consulted if the message encryption flag was set. Thanks for the patch, I will apply it one of these days. Seems to be a usefull addition for me. I don't need the quadoption solution, but that may be different for other people. However, a quadoption would somewhat make it more consistent with the other options. Would it be useful to be able to encrypt, even if the message encryption flag is not set? If so, I could use some opinions, because defining the interface for that starts to get complicated. To me, that is of no particular use. Against what version is the patch you have provided? -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF pgpqj5KBWf9GJ.pgp Description: PGP signature
Re: Encrypting postponed messages
Am 2015-01-07 23:57, schrieb Kevin J. McCarthy: Óscar Pereira wrote: The subject seems pretty self-explanatory. Use case, you're writing an email, which is already marked as to be sent encrypted, but you have to postpone it. In the meantime offlineimap runs and syncs you mailboxes, and thus your mail which is to be sent encrypted ends up in (say) Gmail's remote folder -- UNencrypted. Googling yielded only a question with no answer [1]. The only work-around I have to this is to disabled sync'ing the drafts folder altogether. Is there another way? Sorry to resurrect an old (and somewhat heated) thread, but I'd like some feedback on the interface for a patch I'd like to push (attached, or see ticket #3665). The patch was based off the one submitted by Christian Brabandt, so thank you Christian! Your welcome. I was interested in that functionality and thought I contribute. The patch adds two options: postpone_encrypt (boolean) and postpone_encrypt_as (string). If postpone_encrypt is set, and the message has the encryption flag set, mutt will encrypt the message using the key specified in postpone_encrypt_as. Currently, the interface is as simple as that. Personally, I think that is enough and I wouldn't make it more complicated. I'm wondering if that is sufficient for people interested in the patch, or whether a quadoption for postpone_encrypt would be more useful. For a quadoption, I would keep the behaviour the same: the quadoption would only be consulted if the message encryption flag was set. Would it be useful to be able to encrypt, even if the message encryption flag is not set? If so, I could use some opinions, because defining the interface for that starts to get complicated. I think, if you are going the quadoption way, it should be consulted every time and not only when the message encryption flag is set. Best, Christian
Re: Encrypting postponed messages
Rejo Zenger wrote: To me, that is of no particular use. Against what version is the patch you have provided? Thanks for the feedback. The patch should apply against the tip of the default branch. It may take a little bit of wiggling to get it to apply to something older because of changes in options. But as as long as you get the changes to globals.h, init.h, and mutt.h _somewhere_ in those files it should still work. :-) -Kevin signature.asc Description: PGP signature
Re: Encrypting postponed messages
Óscar Pereira wrote:
The subject seems pretty self-explanatory. Use case, you're writing
an email, which is already marked as to be sent encrypted, but you
have to postpone it. In the meantime offlineimap runs and syncs you
mailboxes, and thus your mail which is to be sent encrypted ends up
in (say) Gmail's remote folder -- UNencrypted.
Googling yielded only a question with no answer [1]. The only
work-around I have to this is to disabled sync'ing the drafts folder
altogether. Is there another way?
Sorry to resurrect an old (and somewhat heated) thread, but I'd like
some feedback on the interface for a patch I'd like to push (attached,
or see ticket #3665). The patch was based off the one submitted by
Christian Brabandt, so thank you Christian!
The patch adds two options: postpone_encrypt (boolean) and
postpone_encrypt_as (string).
If postpone_encrypt is set, and the message has the encryption
flag set, mutt will encrypt the message using the key specified in
postpone_encrypt_as. Currently, the interface is as simple as that.
I'm wondering if that is sufficient for people interested in the patch,
or whether a quadoption for postpone_encrypt would be more useful. For
a quadoption, I would keep the behaviour the same: the quadoption would
only be consulted if the message encryption flag was set.
Would it be useful to be able to encrypt, even if the message encryption
flag is not set? If so, I could use some opinions, because defining the
interface for that starts to get complicated.
Thanks,
-Kevin
# HG changeset patch
# User Kevin McCarthy ke...@8t8.us
# Date 1383772024 28800
# Wed Nov 06 13:07:04 2013 -0800
# Node ID 4d4cee6396e31f67324b23d05054b55f5c5a8ed8
# Parent cd57f8893b43a1d62e6cbf2488d399e97a66a0b2
Add option to encrypt postponed messages. (closes #3665)
This patch is based on Christian Brabandt's patch sent
to mutt-users.
Add two new configuration variables: $postpone_encrypt and
$postpone_encrypt_as. When $postpone_encrypt is set and a message is
marked for encryption, the message will be encrypted using the key
specified in $postpone_encrypt_as before saving the message.
In this patch, $postpone_encrypt_as must be specified. I experimented
with passing safe_strdup( NONULL (PostponeEncryptAs)) when unspecified,
but although gpg.conf has a default-key setting, I could not get it to
work properly. (pgpclassic gave an error message and gpgme sefaulted.)
Although not necessary, this patch turns off signing during encryption
of the postponed message (and turns it back on before saving), since
there is no need to sign the message yet.
diff --git a/globals.h b/globals.h
--- a/globals.h
+++ b/globals.h
@@ -103,16 +103,17 @@
WHERE char *PopAuthenticators INITVAL (NULL);
WHERE short PopCheckTimeout;
WHERE char *PopHost;
WHERE char *PopPass INITVAL (NULL);
WHERE char *PopUser INITVAL (NULL);
#endif
WHERE char *PostIndentString;
WHERE char *Postponed;
+WHERE char *PostponeEncryptAs;
WHERE char *Prefix;
WHERE char *PrintCmd;
WHERE char *QueryCmd;
WHERE char *QueryFormat;
WHERE char *Realname;
WHERE short SearchContext;
WHERE char *SendCharset;
WHERE char *Sendmail;
diff --git a/init.h b/init.h
--- a/init.h
+++ b/init.h
@@ -2116,16 +2116,31 @@
/*
** .pp
** Mutt allows you to indefinitely ``$postpone sending a message'' which
** you are editing. When you choose to postpone a message, Mutt saves it
** in the mailbox specified by this variable.
** .pp
** Also see the $$postpone variable.
*/
+ { postpone_encrypt,DT_BOOL, R_NONE, OPTPOSTPONEENCRYPT, 0 },
+ /*
+ ** .pp
+ ** When \fIset\fP, postponed messages that are marked for encryption will be
+ ** encrypted using the key in $$postpone_encrypt_as before saving.
+ ** (Crypto only)
+ */
+ { postpone_encrypt_as, DT_STR, R_NONE, UL PostponeEncryptAs, 0 },
+ /*
+ ** .pp
+ ** This is the key used to encrypt postponed messages. It should be in
+ ** keyid form (e.g. 0x00112233 for PGP or the hash-value that OpenSSL
+ ** generates for S/MIME).
+ ** (Crypto only)
+ */
#ifdef USE_SOCKET
{ preconnect, DT_STR, R_NONE, UL Preconnect, UL 0},
/*
** .pp
** If \fIset\fP, a shell command to be executed if mutt fails to establish
** a connection to the server. This is useful for setting up secure
** connections, e.g. with \fCssh(1)\fP. If the command returns a nonzero
** status, mutt gives up opening the server. Example:
diff --git a/mutt.h b/mutt.h
--- a/mutt.h
+++ b/mutt.h
@@ -401,16 +401,17 @@
OPTNARROWTREE,
OPTPAGERSTOP,
OPTPIPEDECODE,
OPTPIPESPLIT,
#ifdef USE_POP
OPTPOPAUTHTRYALL,
OPTPOPLAST,
#endif
+ OPTPOSTPONEENCRYPT,
OPTPRINTDECODE,
OPTPRINTSPLIT,
OPTPROMPTAFTER,
OPTREADONLY,
OPTREFLOWTEXT,
OPTREPLYSELF,
OPTRESOLVE,
OPTREVALIAS,
diff --git a/send.c b/send.c
--- a/send.c
+++ b/send.c
@@ -1550,16 +1550,38 @@
goto cleanup;
}
else if (i == 1)
{
/* postpone the message until later. */
Re: 99% OT: An attempt at debate reconciliation. [Was: Encrypting postponed messages]
(For schedule reasons I was unable to reply earlier) Erik, It was never my intention to do anyone's thinking for them. At least knowing you interpreted my words that way explains your reaction (I would have reacted the same way). Perhaps that fault lies with me -- I am not a native English speaker. But in my defence, I will say that as far as I can remember, nobody -- native EN speakers or not -- ever interpreted saying something like by that reasoning as amounting to doing your respondent's thinking for him or her. Err ... please accept that you own that. It's your scenario, and your reasoning. Nothing to do with me, because I had _in_advance_ ruled out any need for an external viewer from my reasoning: In all honesty I still have trouble understanding this. But perhaps, as Christian suggested in another email, it's time to let code take the place of words. If we can each just argue our own case, then the list can be spared a lot of noise. (Compare how quickly Christian won a quite a lot of ground by doing only that. Hint: By all means ask the question, but then let the respondent answer for himself, rather than insist on doing his thinking for him. If his case is weak, and the question relates to it, the wheels will fall off by themselves.) I agree, and that's what I normally try to do. In any case, thank you for that last email -- it was unexpected, but I found it very helpful. --Óscar On Mon, Sep 09, 2013 at 10:39:09PM +1000, Erik Christiansen wrote: On 07.09.13 18:00, Óscar Pereira wrote: So now suppose (*my* scenario, not yours) that mutt used an external program to view emails, and, we were discussing adding the feature of viewing encrypted emails to mutt. By a reasoning *similar* to yours, i.e. reasoning in a way coherent to yours, what would the conclusion be? Err ... please accept that you own that. It's your scenario, and your reasoning. Nothing to do with me, because I had _in_advance_ ruled out any need for an external viewer from my reasoning: On 07.09.13 19:51, Erik Christiansen wrote: 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. If you were to put it forward as a use case purely of your creation, then we could discuss it, but not when you leap over to my side of the tennis net, and insist on whacking the ball there too. Apropos labelling, do please read my prior post carefully - I had only labelled the action of ascribing your thinking to me. One action does not fully define a person, and I have been careful not to label any person. (It's having words rammed down my throat which gets up my nose, if you'll forgive the imagery, not any interlocutor personally. The exchange has otherwise been informative and thought provoking.) If we can each just argue our own case, then the list can be spared a lot of noise. (Compare how quickly Christian won a quite a lot of ground by doing only that. Hint: By all means ask the question, but then let the respondent answer for himself, rather than insist on doing his thinking for him. If his case is weak, and the question relates to it, the wheels will fall off by themselves.) Erik -- If you're going through hell, keep going! - Winston Churchill -- Óscar Pereira | https://erroneousthoughts.org Rules of Optimisation: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. -- M.A. Jackson pgpev78UIMxBk.pgp Description: PGP signature
Re: Encrypting postponed messages
!-- On Mon 9.Sep'13 at 20:33:43 BST, David Champion (d...@bikeshed.us), wrote: I confess I haven't dug my way through the entire debate on this, but so far I've seen argument along lines of: is it a necessary feature? if it is necessary, is it necessary to be supported in mutt per se, or can it be done externally? I haven't seen any discussion of what use models it would harm to support this in mutt. Does anyone have an argument against? Lacking that, I would say that if someone submits a good patch it should be considered. To me it's a good enhancement request. (I can take the old features are bloat, one tool for one job trope for granted, but I don't find it very compelling in general and especially not in this case, where almost all the code necessary is already there in some fashion.) -- David Champion • d...@bikeshed.us I think it would a very attractive feature for mutt users and should be considered by devs to implement this in mutt. I see no reason for it to be handled by an editor given so many people use different editors with mutt. (For what it's worth :-) ) -- James Griffin: jmz at kontrol.kode5.net A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38
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 Fri, Sep 06, 2013 at 11:05:16AM -0500, Dale Raby 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. Well, its easy enough to encrypt the whole disk with modern OS's, so if the message is on your machine it could be made pretty secure with no real extra effort beyond setting it up initially for an encrypted disk. Then they would have to deal with physical security to get the message, i.e.: disarm the operator and hold a gun to his head to get the pass phrase. As only an idiot would actually give the correct pass phrase (because such an assailant would not want any inconvenient loose ends left alive after the data theft), it would be pretty darn secure. A contempt of court charge is no laughing matter either. -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X
99% OT: An attempt at debate reconciliation. [Was: Encrypting postponed messages]
On 07.09.13 18:00, Óscar Pereira wrote: So now suppose (*my* scenario, not yours) that mutt used an external program to view emails, and, we were discussing adding the feature of viewing encrypted emails to mutt. By a reasoning *similar* to yours, i.e. reasoning in a way coherent to yours, what would the conclusion be? Err ... please accept that you own that. It's your scenario, and your reasoning. Nothing to do with me, because I had _in_advance_ ruled out any need for an external viewer from my reasoning: On 07.09.13 19:51, Erik Christiansen wrote: 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. If you were to put it forward as a use case purely of your creation, then we could discuss it, but not when you leap over to my side of the tennis net, and insist on whacking the ball there too. Apropos labelling, do please read my prior post carefully - I had only labelled the action of ascribing your thinking to me. One action does not fully define a person, and I have been careful not to label any person. (It's having words rammed down my throat which gets up my nose, if you'll forgive the imagery, not any interlocutor personally. The exchange has otherwise been informative and thought provoking.) If we can each just argue our own case, then the list can be spared a lot of noise. (Compare how quickly Christian won a quite a lot of ground by doing only that. Hint: By all means ask the question, but then let the respondent answer for himself, rather than insist on doing his thinking for him. If his case is weak, and the question relates to it, the wheels will fall off by themselves.) Erik -- If you're going through hell, keep going! - Winston Churchill
Re: Encrypting postponed messages
On Sun, Sep 08, 2013 at 06:08:04PM +0100, Mick wrote: 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 It's more like an organ, and yes you do need the whole Cathedral. -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X
Re: Encrypting postponed messages
On 08.09.13 20:14, Tim Gray wrote: 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. To have an unencrypted subject line, it's necessary to enter it in mutt, prior to postponing. However, that's probably an asset if the subject ought also be obfuscated, E.g. We go to war tomorrow might be safer as Immediate plans. If encryption were provided in mutt, the same could be done. 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. Would the postponed mail folder ever be placed remotely, when security is the primary concern? (I don't use either of those, so my understanding of them is limited.) Erik -- Life is complex: it has a real part and an imaginary part. - Martin Terma
Re: Encrypting postponed messages
On Sep 09, 2013 at 11:47 PM +1000, Erik Christiansen wrote: To have an unencrypted subject line, it's necessary to enter it in mutt, prior to postponing. However, that's probably an asset if the subject ought also be obfuscated, E.g. We go to war tomorrow might be safer as Immediate plans. If encryption were provided in mutt, the same could be done. Well, encrypted messages that are actually sent don't have encrypted headers (or subjects), so while there might be security concerns with unencrypted subject lines, I don't see the need for them, nor does it appear to me that users of GPG or encrypted email have the capability for them. I'm not sure what would happen if you added headers, subject or otherwise, prior to postponing but after writing the draft and encrypting in Vim (with Vim's builtin encryption). Vim's encryption turns the file into what looks like binary data, so tacking on a line or two at the top of that looks like a recipe for disaster. Would the postponed mail folder ever be placed remotely, when security is the primary concern? (I don't use either of those, so my understanding of them is limited.) If security was the primary concern, probably not. My larger point was that the encrypted file is no longer a valid file for the maildir structure. Note, I haven't tried doing the outlined process with mutt set to use the mbox file format; I don't know how mutt stores drafts with that setting. Honestly though, I don't see your question as overly pertinent. If security is a primary concern, why are you sending (and storing) encrypted messages on a server to begin with? I don't think that's for me to answer. The way I look at it, a message in a drafts mailbox is a first class citizen under IMAP; it's just like any other message in terms of it's format for the most part. So if you are going to store an encrypted message in your inbox, or an encrypted draft in your postponed folder, shouldn't they share the same format and shouldn't the mail client interact with them in the same way?* With GPG encryption at least, the expectation is that the body text is encrypted, either as ascii armor or as a MIME attachment. That would work perfectly fine in a drafts folder or as a sent/received message. Since mutt already has a mechanism and process for doing this with sent/received messages, it seems very convenient for the user to have the postponed draft system to work in the same way. * Of course, with the obvious exception that a postponed message can have it's editing resumed at a later date.
Re: Encrypting postponed messages
On Fri, Sep 06, 2013 at 11:05:16AM -0500, Dale Raby 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. Well, its easy enough to encrypt the whole disk with modern OS's, so if the message is on your machine it could be made pretty secure with no real extra effort beyond setting it up initially for an encrypted disk. You make it sound like there's no downside to doing this... There is: performance. So whether or not this makes sense as a solution very much depends on your workstation's (that's a hint) use case. I dunno though, why would you want to store a sensitive draft any longer than you need to? The key to that sentence is the last part... Encrypted messages should be as concise as possible Who says? What if what you're encrypting is a draft of a paper? You needed to send it to your boss/colleague/editor anyway, and your e-mail client will encrypt your postponed message (or so you might think, and so may it be, if that were implemented), so why should you care? Your entire message makes a lot of assumtions which may be just plain wrong. -- Derek D. Martinhttp://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. pgp7bR3gpwuob.pgp Description: PGP signature
Re: Encrypting postponed messages
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. Martinhttp://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
Re: Encrypting postponed messages
On Sun, Sep 08, 2013 at 01:47:39AM +1000, Erik Christiansen wrote: 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. And in so doing it exerts control over that process; moreover it does all this with one purpose in mind: creating an e-mail message. Your editor generally neither knows nor cares about that fact, but it is an important one to the overall process. I assumed, apparently incorrectly, that something which might provide immediate draft file security would be welcome enough to be worth examining. It's worth examining. But it depends on a feature in your editor which likely does not exist (unless you happen to pick one that has it--and many people detest vi/vim/emacs). Perhaps a better way to do this would be for Mutt to provide the editor a named pipe, and then read the file from that rather than an on-disk temp file. But as this temp file should normally be very short-lived (there's really no good reason to write it out manually as you did in your example), the risk of leaking the data is minimal. And if the user really is concerned about someoene stealing the disk and getting at the deleted clear text, then they probably should indeed use full disk encryption (or something like it). But that is a decision that should be left to the user. But none of this substantially affects whether Mutt should encrypt postponed messages. -- Derek D. Martinhttp://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. pgpBy_v27OY0y.pgp Description: PGP signature
Re: Encrypting postponed messages
On Mon, Sep 09, 2013 at 10:20:33AM -0400, Tim Gray wrote: Honestly though, I don't see your question as overly pertinent. If security is a primary concern, why are you sending (and storing) encrypted messages on a server to begin with? I don't think that's for me to answer. Right. There are different levels of sensitivity, and provided the messages are encrypted, it should not matter where they are stored for all but the most sensitive cases. That is the entire point of encrypting them... -- Derek D. Martinhttp://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. pgp0agOCXHHLJ.pgp Description: PGP signature
Re: 99% OT: An attempt at debate reconciliation. [Was: Encrypting postponed messages]
On Mon, Sep 09, 2013 at 10:39:09PM +1000, Erik Christiansen wrote: If we can each just argue our own case, then the list can be spared a lot of noise. That's a grand idea (seriously), but this is isn't debate club. Most people have litte or no training in formal logic, and while if you have you're probably best off using it, in practical terms criticising people's arguments for the lack thereof really doesn't make much sense on a mailing list. -- Derek D. Martinhttp://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. pgp4L1oNjhhbd.pgp Description: PGP signature
Re: Encrypting postponed messages
I confess I haven't dug my way through the entire debate on this, but so far I've seen argument along lines of: is it a necessary feature? if it is necessary, is it necessary to be supported in mutt per se, or can it be done externally? I haven't seen any discussion of what use models it would harm to support this in mutt. Does anyone have an argument against? Lacking that, I would say that if someone submits a good patch it should be considered. To me it's a good enhancement request. (I can take the old features are bloat, one tool for one job trope for granted, but I don't find it very compelling in general and especially not in this case, where almost all the code necessary is already there in some fashion.) -- David Champion • d...@bikeshed.us
Re: Encrypting postponed messages
On Mo, 09 Sep 2013, David Champion wrote:
I confess I haven't dug my way through the entire debate on this, but so
far I've seen argument along lines of: is it a necessary feature? if it
is necessary, is it necessary to be supported in mutt per se, or can it
be done externally?
I haven't seen any discussion of what use models it would harm to
support this in mutt. Does anyone have an argument against?
Lacking that, I would say that if someone submits a good patch it should
be considered. To me it's a good enhancement request.
I know almost nothing about the mutt code base, but I figured, it would
be better to start working with the code, then continue this discussion.
So here is a basic patch, that seems to work for me. I hope this will be
more valuable than to continue with this endless discussion.
regards,
Christian
--
The bureaucracy is expanding to meet the needs of an expanding bureaucracy.
--- send.c 2010-09-13 19:19:55.0 +0200
+++ send.c.new 2013-09-09 22:25:49.177397477 +0200
@@ -1543,6 +1543,23 @@
if (msg-content-next)
msg-content = mutt_make_multipart (msg-content);
+ if (WithCrypto)
+ {
+ if (msg-security)
+ {
+ if ((crypt_get_keys (msg, pgpkeylist) == -1) ||
+ mutt_protect (msg, pgpkeylist) == -1)
+ {
+ msg-content = mutt_remove_multipart (msg-content);
+
+ FREE (pgpkeylist);
+
+ decode_descriptions (msg-content);
+ goto main_loop;
+ }
+ }
+ }
+
/*
* make sure the message is written to the right part of a maildir
* postponed folder.
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.
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
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 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 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.) That is activated on a per-file basis, conveniently allowing unencrypted editing of general files, and even encrypting of some postponed emails, but not others. That's a major strength of mutt, I believe. The problem is already solved because the toolkit of single-purpose compatible tools that is *nix fixes it naturally, without going down the emacs path. Erik -- Less is more or less more. - Y_Plentyn on #LinuxGER
Re: Encrypting postponed messages
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... --Óscar -- Óscar Pereira | https://erroneousthoughts.org Rules of Optimisation: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. -- M.A. Jackson pgpSwArwzIjsm.pgp Description: PGP signature
Re: Encrypting postponed messages
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
Re: Encrypting postponed messages
Hi Erik! On Sa, 07 Sep 2013, Erik Christiansen wrote: 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. You are being serious here? mutt spawns the editor with some template file that is lying around in some tmp/ folder. 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). I don't see, how your editor comes to mind here, especially, since your editor doesn't even know where to save postponed mails. 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. 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 ;) regards, Christian -- A novice asked the master: I perceive that one computer company is much larger than all others. It towers above its competition like a giant among dwarfs. Any one of its divisions could comprise an entire business. Why is this so? The master replied, Why do you ask such foolish questions? That company is large because it is so large. If it only made hardware, nobody would buy it. If it only maintained systems, people would treat it like a servant. But because it combines all of these things, people think it one of the gods! By not seeking to strive, it conquers without effort. -- Geoffrey James, The Tao of Programming
Re: Encrypting postponed messages
On 07.09.13 12:56, Óscar Pereira wrote: On Sat, Sep 07, 2013 at 07:51:41PM +1000, Erik Christiansen wrote: On 07.09.13 09:44, Óscar Pereira wrote: On Sat, Sep 07, 2013 at 06:13:20PM +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. 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. Please _read_ the second last sentence! It makes your reply a straw man: Do you realise that by your own logic, No, the following scenario of yours is entirely of your own creation, and it is intellectually dishonest of you to attempt to ascribe it to any another person, especially one whose logic has just ruled it out: if one was to use an external program (instead of mutt's default viewer) to view emails, that would mean that it would be **that program's** responsibility to decrypt the email before showing it to the user? Do you think this is a good way to handle encrypted emails? It is fine for you fabricate such a proposal, but it is intellectually dishonest to pretend that the fantasy is anything other than yours. (What motive you have in substituting an editor for mutt's viewer, is obscure, since you merely create problems which otherwise do not exist.) 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.) What you seem to have missed is that when, for instance, you send an encrypted email, mutt saves a copy in the *local* sent folder, encrypted to your public key. Relevance? The posed problem was unencrypted postponed drafts. A means of encrypting them is what is needed. Are we both able to differentiate a draft from a record of a sent email? The former currently needs encryption, and a potential way to achieve that now has been described. The latter is encrypted, so there is no problem to solve there. As far as I know, *mutt* does that (*), not the editor. Am I wrong? No, you are agreeing with my statements about mutt handling email sending. You could try reading the post to which you replied. If I'm not wrong, then what's so baffling about your reasoning is that you seem to be assuming that the (local) drafts folder is something that's totally unrelated to mutt, or to email, or whatever. Your assumptions about my reasoning have not been reliable hitherto. I'd abandon that endeavor as unfruitful. Granted, before saving the encrypted-to-self copy mutt is involved in actually sending the email. But mutt is also involved when you save a draft, because you have tell **mutt** to store the draft! (by pressing P in the appropriate viewer). If mutt ever acquires draft encryption, that integrated solution will be easier to drive, and therefore better in the long term. A config option will be needed, for enabling encryption. But a working solution is significantly more useful today than a mutt feature which might or might not ever eventuate. When, in the interim, an encryption-capable editor is employed, mutt acts only as a transparent pipe between the editor and the draft file, activated by P. I'm not trying to start a flame here, but I am genuinely surprised by your reasoning. My reasoning is that a method which can provide encrypted drafts is somewhat more useful than a method which does not exist. 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. No I don't think it's mutt's job to do hard drive encryption. But I'm not conflating anything either, for mutt already has the ability to write encrypted emails to disk: see above. If mutt were modified to interpose encryption/decryption as an optional filter between the editor and the filesystem, then that would be a very fine solution. But it might never happen. In the interim, a solution which can provide encrypted drafts now beats any imaginary solution. 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
Re: Encrypting postponed messages
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
Re: Encrypting postponed messages
I'll reply to rest of email later, but I want to make two things clear. First, you accuse me of being intellectually dishonest, because I «attempt to ascribe» to you a scenario I thought up. I was (and am) not, but since that seems not to have been clear enough, I'll try to explain it more carefully. You wrote that 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. And you wrote this to justify why the drafts should be encrypted by the editor instead of mutt. So now suppose (*my* scenario, not yours) that mutt used an external program to view emails, and, we were discussing adding the feature of viewing encrypted emails to mutt. By a reasoning *similar* to yours, i.e. reasoning in a way coherent to yours, what would the conclusion be? Well, that because mutt is not involved in the process of viewing the email, decryption should happen within the external viewer, not mutt! See what I did here? My scenario, your reasoning. This is what I meant by by your own logic. If you still can't understand it, and think it's me being intellectually dishonest, then I give up: I cannot put it into simpler terms. By the way, this is not a straw man, because I have not replaced the question, which is were should encryption or decryption happen (in mutt or an outside program). I took the reasoning you used in the case of drafts, and applied it to a hypothetical but possible scenario, to show you how it led to an undesirable conclusion. The only cause I can imagine for you to describe doing so as dishonest, is if you would apply a different reasoning for that different scenario. But then I'm left wandering why couldn't that different reasoning by applied to the drafts' case... Second, some parts of your email seem to suggest that you regard using the editor to encrypt the draft as the possible solution, rather than as the right one. I agree -- and as the original poster, thank you for it. But then you go on (or seem to go on) trying to justify using the editor as the proper solution, and proceed to do what seems to me as defending its merits (besides being the possible solution). Could you clarify which one are you trying to do? --Óscar On Sun, Sep 08, 2013 at 12:18:57AM +1000, Erik Christiansen wrote: On 07.09.13 12:56, Óscar Pereira wrote: On Sat, Sep 07, 2013 at 07:51:41PM +1000, Erik Christiansen wrote: On 07.09.13 09:44, Óscar Pereira wrote: On Sat, Sep 07, 2013 at 06:13:20PM +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. 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. Please _read_ the second last sentence! It makes your reply a straw man: Do you realise that by your own logic, No, the following scenario of yours is entirely of your own creation, and it is intellectually dishonest of you to attempt to ascribe it to any another person, especially one whose logic has just ruled it out: if one was to use an external program (instead of mutt's default viewer) to view emails, that would mean that it would be **that program's** responsibility to decrypt the email before showing it to the user? Do you think this is a good way to handle encrypted emails? It is fine for you fabricate such a proposal, but it is intellectually dishonest to pretend that the fantasy is anything other than yours. (What motive you have in substituting an editor for mutt's viewer, is obscure, since you merely create problems which otherwise do not exist.) 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.) What you seem to have missed is that when, for instance, you send an encrypted email, mutt saves a copy in the *local* sent folder, encrypted to your public key. Relevance? The posed problem was unencrypted postponed drafts. A means of encrypting them is what is needed. Are we both able to differentiate a draft from a record of a sent email? The former currently needs encryption, and a potential way to achieve that now has been described. The latter is encrypted, so there is
Re: Encrypting postponed messages
On Thu, Sep 05, 2013 at 06:45:46PM +1200, Chris Bannister wrote: On Wed, Sep 04, 2013 at 05:30:16PM +0100, Óscar Pereira wrote: Dear all, The subject seems pretty self-explanatory. Use case, you're writing an email, which is already marked as to be sent encrypted, but you have to postpone it. In the meantime offlineimap runs and syncs you mailboxes, and thus your mail which is to be sent encrypted ends up in (say) Gmail's remote folder -- UNencrypted. This seems like an offlineimap issue, rather than anything to do with mutt. It really isn't. If you wanted the message to be encrypted, there's no good reason to save it on the local disk unencrypted. Mutt, for example, does not decrypt incoming messages and then re-save them unencrypted, nor would you typically want that. 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. -- Derek D. Martinhttp://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. pgpql4hiswuk5.pgp Description: PGP signature
Re: Encrypting postponed messages
On Fri, Sep 06, 2013 at 11:05:16AM -0500, Dale Raby wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. Well, its easy enough to encrypt the whole disk with modern OS's, so Ya, except in my original email I said: have to postpone it. In the meantime offlineimap runs and syncs you mailboxes, and thus your mail which is to be sent encrypted ends up in (say) Gmail's remote folder -- UNencrypted. Don't get my wrong: I actually have encrypted my hard drives, and I actually don't have offlineimap running in a background cronjob (it runs before mutt, in a wrapper script I use to start mutt). My problem is thus that the message ends up unencrypted in google's servers. But Derek Martin's comment is relevant: mutt should not *assume* that the user's disk is encrypted; otherwise why bother storing even the original messages encrypted?? Indexing and searching them, for one, would be easier... This wasn't exactly what I was thinking about when I wrote the original email, but now that I have, does seems to justify a bug report (or feature request, depending on your point of view...). Objections? if the message is on your machine it could be made pretty secure with no real extra effort beyond setting it up initially for an encrypted disk. Then they would have to deal with physical security to get the message, i.e.: disarm the operator and hold a gun to his head to get the pass phrase. As only an idiot would actually give the correct pass phrase (because such an assailant would not want any inconvenient loose ends left alive after the data theft), it would be pretty darn secure. I dunno though, why would you want to store a sensitive draft any longer than you need to? Encrypted messages should be as concise as possible, so if you get interrupted during composition, would it not be better to delete the draft and start it over after you have dealt with the KGB or whatever? - -- Dale A. Raby Buy My Book: 777 Bon Mots for Gunslingers and Other Real Men Available at Amazon, Google Books, Barnes Noble, Book Tango, and other online book stores. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIp/TwACgkQq4gfK1twdnfoigCfZ6LmGSmrtj+0B0mpbu3exjXd wx4AniZt/7OChTNkrB2kZYYWWKRP1Qel =LVop -END PGP SIGNATURE- -- Óscar Pereira | https://erroneousthoughts.org Rules of Optimisation: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. -- M.A. Jackson pgpnNZyee7IX_.pgp Description: PGP signature
Re: Encrypting postponed messages
On Wed, Sep 04, 2013 at 05:30:16PM +0100, Óscar Pereira wrote: Dear all, The subject seems pretty self-explanatory. Use case, you're writing an email, which is already marked as to be sent encrypted, but you have to postpone it. In the meantime offlineimap runs and syncs you mailboxes, and thus your mail which is to be sent encrypted ends up in (say) Gmail's remote folder -- UNencrypted. This seems like an offlineimap issue, rather than anything to do with mutt. -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X
Re: Encrypting postponed messages
On Thu, Sep 05, 2013 at 06:45:46PM +1200, Chris Bannister wrote: On Wed, Sep 04, 2013 at 05:30:16PM +0100, Óscar Pereira wrote: The subject seems pretty self-explanatory. Use case, you're writing an email, which is already marked as to be sent encrypted, but you have to postpone it. In the meantime offlineimap runs and syncs you mailboxes, and thus your mail which is to be sent encrypted ends up in (say) Gmail's remote folder -- UNencrypted. This seems like an offlineimap issue, rather than anything to do with mutt. indeed - I had similar problems and changed my setup in a way that offlineimap is started only on demand. Currently, that means: 1. if idlemail.py [1] detects new mail in incoming folders 2. after I quit mutt I want to experiment with fsniper [2] in order to start offlineimap automatically when a maildir is changed locally but also without this, these two triggers are fine. Also you could start it by macro the maildir sync key to a macro which syncs and then starts offlineimap. Best regards Sebastian 1. http://www.cc.gatech.edu/~sburnett/posts/2010-11-21-imap-idle.html 2. https://github.com/l3ib/fsniper -- WebID: http://sebastian.tramp.name pgpzNfuzo0Sw4.pgp Description: PGP signature
Encrypting postponed messages
Dear all, The subject seems pretty self-explanatory. Use case, you're writing an email, which is already marked as to be sent encrypted, but you have to postpone it. In the meantime offlineimap runs and syncs you mailboxes, and thus your mail which is to be sent encrypted ends up in (say) Gmail's remote folder -- UNencrypted. Googling yielded only a question with no answer [1]. The only work-around I have to this is to disabled sync'ing the drafts folder altogether. Is there another way? --Óscar [1] - http://superuser.com/questions/578903/making-mutt-gpg-encrypt-emails-saved-as-drafts -- Óscar Pereira | https://erroneousthoughts.org Rules of Optimisation: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. -- M.A. Jackson pgpuIu7pE6N3O.pgp Description: PGP signature
