Re: folder-hook for postponed messages
On Sat, Nov 28, 2015 at 9:37 PM, Xu Wang <xuwang...@gmail.com> wrote: > On Sat, May 30, 2015 at 5:44 AM, Xu Wang <xuwang...@gmail.com> wrote: >> On Fri, May 29, 2015 at 5:22 PM, Andrzej Popielewicz >> <apopi...@amu.edu.pl> wrote: >>> * Xu Wang <xuwang...@gmail.com> [2015-05-27 22:27:00]: >>> >>>> Dear all, >>>> >>>> I would like set a folder hook for postponed messages, which I hope is >>>> run when I do "R" to change to the postponed folder. >>>> >>>> Note that in my .muttrc I have: >>>> >>>> set postponed="+[Gmail].Drafts" >>>> >>>> but the hook does not seem to work. I tried many, including: >>>> >>>> folder-hook 'Drafts' 'set editor = "vim"' >>>> >>>> Is there a reason this is not matched by regex? >>>> >>>> Kind regards, >>>> >>>> Xu >>> >>> I have just tested . >>> The following works >>> >>> set editor="elvis" >>> folder-hook "imap.amu.edu.pl/Drafts" set editor="vim" >>> >>> If I use >>> mutt -f imaps://imap.amu.edu.pl/INBOX/ >>> and I use "e" command to edit the message then elvis is used >>> if I use >>> mutt -f imaps://imap.amu.edu.pl/Drafts/ >>> and I use "e" command to edit the message then vi is used >>> >>> Seems it is exactly what You wanted . Or ? >>> >>> Andrzej >> >> Dear all, >> >> Thank you very much for such great responses. I understand the issue I >> had much better now. I thought I wanted folder-hook, but actually I >> think I want something like postpone-hook, which does not exist >> (probably for good reason). >> >> I now see two options, to use folder hook and 'c' to change >> directories, such as Andrzej is suggesting, or to use macros, such as >> Kevin is suggesting. >> >> I will test and figure out which is best for my set up. Thank you so much. >> >> Kind regards, > > I am still attempting to configure things to my preference. > > I have currently in my .muttrc: > > > set index_format = "%4C %Z %[%b %d %R] %-15.15n (%X) %s" > macro index,pager R "set index_format='%4C %Z %[%b %d > %R] %-15.15F (%X) %s' > push R > > I prefer a different index format when in the list of postponed > messages. Because we don't have such a thing as "map-based hooks" I > use macro. > The last command is what opens postponed messages on startup, which is > my preference. > > However, now my default index is changed. For example, suppose no > postponed message. Then index is set as above and not set to index I > prefer when not in postpone map. I attempted: > > folder-hook "." 'set index_format = "%4C %Z %[%b %d %R] %-15.15n (%X) %s"' > > but that does not help (=does not change anything unless I first > change to a folder and then change back). > Is there a method to set a variable when *leaving* postponed map? > > Does someone have a suggestion? > > Kind regards, > > Xu Hello, I still have the above question. I am unsure how to proceed. Basically, I would like one index_format (using -15.15n) in every situation except when I am in the postponed map, where I would like a different index_format (-15.15L). Is there a suggestion for achieving above goal? Kind regards, Xu
Re: folder-hook for postponed messages
On Sat, May 30, 2015 at 5:44 AM, Xu Wang <xuwang...@gmail.com> wrote: > On Fri, May 29, 2015 at 5:22 PM, Andrzej Popielewicz > <apopi...@amu.edu.pl> wrote: >> * Xu Wang <xuwang...@gmail.com> [2015-05-27 22:27:00]: >> >>> Dear all, >>> >>> I would like set a folder hook for postponed messages, which I hope is >>> run when I do "R" to change to the postponed folder. >>> >>> Note that in my .muttrc I have: >>> >>> set postponed="+[Gmail].Drafts" >>> >>> but the hook does not seem to work. I tried many, including: >>> >>> folder-hook 'Drafts' 'set editor = "vim"' >>> >>> Is there a reason this is not matched by regex? >>> >>> Kind regards, >>> >>> Xu >> >> I have just tested . >> The following works >> >> set editor="elvis" >> folder-hook "imap.amu.edu.pl/Drafts" set editor="vim" >> >> If I use >> mutt -f imaps://imap.amu.edu.pl/INBOX/ >> and I use "e" command to edit the message then elvis is used >> if I use >> mutt -f imaps://imap.amu.edu.pl/Drafts/ >> and I use "e" command to edit the message then vi is used >> >> Seems it is exactly what You wanted . Or ? >> >> Andrzej > > Dear all, > > Thank you very much for such great responses. I understand the issue I > had much better now. I thought I wanted folder-hook, but actually I > think I want something like postpone-hook, which does not exist > (probably for good reason). > > I now see two options, to use folder hook and 'c' to change > directories, such as Andrzej is suggesting, or to use macros, such as > Kevin is suggesting. > > I will test and figure out which is best for my set up. Thank you so much. > > Kind regards, I am still attempting to configure things to my preference. I have currently in my .muttrc: set index_format = "%4C %Z %[%b %d %R] %-15.15n (%X) %s" macro index,pager R "set index_format='%4C %Z %[%b %d %R] %-15.15F (%X) %s' push R I prefer a different index format when in the list of postponed messages. Because we don't have such a thing as "map-based hooks" I use macro. The last command is what opens postponed messages on startup, which is my preference. However, now my default index is changed. For example, suppose no postponed message. Then index is set as above and not set to index I prefer when not in postpone map. I attempted: folder-hook "." 'set index_format = "%4C %Z %[%b %d %R] %-15.15n (%X) %s"' but that does not help (=does not change anything unless I first change to a folder and then change back). Is there a method to set a variable when *leaving* postponed map? Does someone have a suggestion? Kind regards, Xu
Re: folder-hook for postponed messages
W dniu 2015-05-28 o 23:23, Andrzej Popielewicz pisze: * Xu Wang xuwang...@gmail.com [2015-05-27 22:27:00]: Dear all, I would like set a folder hook for postponed messages, which I hope is run when I do R to change to the postponed folder. Note that in my .muttrc I have: set postponed=+[Gmail].Drafts but the hook does not seem to work. I tried many, including: folder-hook 'Drafts' 'set editor = vim' Is there a reason this is not matched by regex? Kind regards, Xu For me works the following folder-hook imap.googlemail.com set record ==Sent folder-hook imap.googlemail.com set postponed = =Drafts Andrzej Well, In the first part of Your email You have claimed that preceeding hook does not work. This is why I supplied the example , which for sure works because I am using it. Your editor problem seemed to be another problem. Now it is clear , what You want. So You want to achieve something like shown below folder-hook imap.googlemail.com/Drafts set editor=vim folder-hook imap.googlemail.com/Sent set editor=pico Well, I am not sure if it is possible, try it out . If not ,one could try to invent new option set postpone_editor=myeditor Andrzej
Re: folder-hook for postponed messages
On Fri, May 29, 2015 at 10:24:01AM +0200, Andrzej Popielewicz wrote: So You want to achieve something like shown below folder-hook imap.googlemail.com/Drafts set editor=vim folder-hook imap.googlemail.com/Sent set editor=pico Note that for folder-hooks it is important to have a default, otherwise the last folder-hook is still in effect, if you change folders and the new folder does not match any folder-hooks. Well, I am not sure if it is possible, try it out . If not ,one could try to invent new option set postpone_editor=myeditor I believe invented variables are required to start with my_, otherwise you will probably get an unknown variable error. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: folder-hook for postponed messages
W dniu 2015-05-29 o 10:35, Suvayu Ali pisze: On Fri, May 29, 2015 at 10:24:01AM +0200, Andrzej Popielewicz wrote: So You want to achieve something like shown below folder-hook imap.googlemail.com/Drafts set editor=vim folder-hook imap.googlemail.com/Sent set editor=pico Note that for folder-hooks it is important to have a default, otherwise the last folder-hook is still in effect, Yes, this is what I would expect too. I wanted only to show what he wanted to achieve, and not what is possible. if you change folders and the new folder does not match any folder-hooks. Well, I am not sure if it is possible, try it out . If not ,one could try to invent new option set postpone_editor=myeditor I believe invented variables are required to start with my_, otherwise you will probably get an unknown variable error. It is obvious. But I wanted to suggest something different. By invent I have meant implement as a new added feature. It means he would have to apply to the mutt team for this new variable.:-) Andrzej Cheers,
Re: folder-hook for postponed messages
* Kevin J. McCarthy ke...@8t8.us [2015-05-29 10:08:35]: Xu Wang wrote: I would like set a folder hook for postponed messages, which I hope is When you use R you aren't really changing to the postponed folder. If there is more than one postponed message, it will provide a list to choose from, however it's not the same as the message index and so folder-hooks are not run. -Kevin And what if I use c command to change explicitly to Drafts folder ? Andrzej
Re: folder-hook for postponed messages
Xu Wang wrote: I would like set a folder hook for postponed messages, which I hope is run when I do R to change to the postponed folder. When you use R you aren't really changing to the postponed folder. If there is more than one postponed message, it will provide a list to choose from, however it's not the same as the message index and so folder-hooks are not run. You may want to try using macros instead (these are untested): macro index,pager R enter-commandset editor=vimenterrecall-message recall macro macro index,pager m enter-commandset editor=emacsentermail mail macro macro index,pager r enter-commandset editor=nanoenterreply reply macro macro index,pager g enter-commandset editor=edentergroup-reply group reply macro macro index,pager L enter-commandset editor=picoenterlist-reply list reply macro Note that editor stays set after each macro, which is why I've created it for all the other mailing commands. -Kevin signature.asc Description: PGP signature
Re: folder-hook for postponed messages
* Xu Wang xuwang...@gmail.com [2015-05-27 22:27:00]: Dear all, I would like set a folder hook for postponed messages, which I hope is run when I do R to change to the postponed folder. Note that in my .muttrc I have: set postponed=+[Gmail].Drafts but the hook does not seem to work. I tried many, including: folder-hook 'Drafts' 'set editor = vim' Is there a reason this is not matched by regex? Kind regards, Xu I have just tested . The following works set editor=elvis folder-hook imap.amu.edu.pl/Drafts set editor=vim If I use mutt -f imaps://imap.amu.edu.pl/INBOX/ and I use e command to edit the message then elvis is used if I use mutt -f imaps://imap.amu.edu.pl/Drafts/ and I use e command to edit the message then vi is used Seems it is exactly what You wanted . Or ? Andrzej
Re: folder-hook for postponed messages
* Xu Wang xuwang...@gmail.com [2015-05-27 22:27:00]: Dear all, I would like set a folder hook for postponed messages, which I hope is run when I do R to change to the postponed folder. Note that in my .muttrc I have: set postponed=+[Gmail].Drafts but the hook does not seem to work. I tried many, including: folder-hook 'Drafts' 'set editor = vim' Is there a reason this is not matched by regex? Kind regards, Xu For me works the following folder-hook imap.googlemail.com set record ==Sent folder-hook imap.googlemail.com set postponed = =Drafts Andrzej
Re: folder-hook for postponed messages
On Thu, May 28, 2015 at 5:23 PM, Andrzej Popielewicz apopi...@amu.edu.pl wrote: * Xu Wang xuwang...@gmail.com [2015-05-27 22:27:00]: Dear all, I would like set a folder hook for postponed messages, which I hope is run when I do R to change to the postponed folder. Note that in my .muttrc I have: set postponed=+[Gmail].Drafts but the hook does not seem to work. I tried many, including: folder-hook 'Drafts' 'set editor = vim' Is there a reason this is not matched by regex? Kind regards, Xu For me works the following folder-hook imap.googlemail.com set record ==Sent folder-hook imap.googlemail.com set postponed = =Drafts Andrzej Thank you for the reply Andrzej. I am not sure I understand. What I would like is to have a special command set for editor only when resuming postponed messages. Kind regards, Xu
folder-hook for postponed messages
Dear all, I would like set a folder hook for postponed messages, which I hope is run when I do R to change to the postponed folder. Note that in my .muttrc I have: set postponed=+[Gmail].Drafts but the hook does not seem to work. I tried many, including: folder-hook 'Drafts' 'set editor = vim' Is there a reason this is not matched by regex? Kind regards, Xu
Send all postponed messages?
Dear all, I would like to have a key that is bound to a function that sends all drafts, one by one. I have searched and have not found any mutt solution, although I have found external solutions: http://objectmix.com/mutt/202590-send-all-postponed-messages.html http://mutt-users.mutt.narkive.com/2uvmjX4M/sending-in-bulk-mode-from-draft-folder http://comments.gmane.org/gmane.mail.mutt.user/28752 Is it indeed too difficult to do it entirely within mutt? Kindly, Xu
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
postponed messages
hello when I have multiple postponed messages I cannot enter into them First it was telling me that rxvt was not installed So I installed it and now is like it tries to open it very quicly and then it closes but I cannot open it with my normal editor nano here is the line in my .muttrc that I think it might relate to: macro generic \cj !rxvt -bg wheat -e joe $HOME/.muttrc\r and another question related to postponed messages would be possible to send all the postponed messages at once (rather than one by one)? thanks mattin
Re: Send off all postponed messages
On Tue, Sep 17, 2002 at 03:18:23PM +0200, René Clerc wrote: What about installing a simple SMTP daemon on your machine, which will relay your emails to your office's mailserver, once you're back online? As it turns out exim was already configured to do this. I just hadn't given it a chance to prove itself. alex -- Alex Polite http://plusseven.com/gpg/
Send off all postponed messages
I regularly deal with mail when I'm away from my DSL pipe. Right now I'm at the coffee shop and the postponed messages are piling up. When I get back to the office I'd like to be able to send-all-postponed-messages. -- Alex Polite http://plusseven.com/gpg/
Send off all postponed messages
I regularly deal with mail when I'm away from my DSL pipe. Right now I'm at the coffee shop and the postponed messages are piling up. When I get back to the office I'd like to be able to send-all-postponed-messages. -- Alex Polite http://plusseven.com/gpg/
Re: Send off all postponed messages
* Alex Polite [EMAIL PROTECTED] [17-09-2002 14:20]: I regularly deal with mail when I'm away from my DSL pipe. Right now I'm at the coffee shop and the postponed messages are piling up. When I get back to the office I'd like to be able to send-all-postponed-messages. You want the functionality of an outbox, I suspect. This is not what postponed is meant for (and therefore, this functionality will most probably will not be added to mutt). What about installing a simple SMTP daemon on your machine, which will relay your emails to your office's mailserver, once you're back online? -- René Clerc - ([EMAIL PROTECTED]) Ik ben niet droknen. -Rachel Pieterse msg30966/pgp0.pgp Description: PGP signature
Re: Send off all postponed messages - tell you MTA
* Alex Polite [EMAIL PROTECTED] [2002-09-17 12:20]: I regularly deal with mail when I'm away from my DSL pipe. Right now I'm at the coffee shop and the postponed messages are piling up. When I get back to the office I'd like to be able to send-all-postponed-messages. the trick is to send them all right away - and tell your MTA to really send them away as soon as you have an internet connection. so this is an MTA configuration problem. Sven
Re: Send off all postponed messages
* On 2002.09.17, in [EMAIL PROTECTED], * Alex Polite [EMAIL PROTECTED] wrote: I regularly deal with mail when I'm away from my DSL pipe. Right now I'm at the coffee shop and the postponed messages are piling up. When I get back to the office I'd like to be able to send-all-postponed-messages. Some would say that this should be a function of your SMTP agent, not your MTA. I think that, for once, I would agree. Set your MTA of choice to queue outbound messages when you're off-line, and flush the queue when you're on again. -- -D.We establised a fine coffee. What everybody can say Sun Project, APC/UCCO TASTY! It's fresh, so-mild, with some special coffee's University of Chicago bitter and sourtaste. LET'S HAVE SUCH A COFFEE! NOW! [EMAIL PROTECTED] Please love CAFE MIAMI. Many thanks.
Re: postponed messages
Hello! Nevertheless I have a similar problem. I want to use the traditional encrypted formats for only some people. So I do this: send-hook . 'set pgp_create_traditional=no' send-hook 'first@email\.address' \ 'set pgp_create_traditional=yes pgp_autoencrypt=yes' send-hook 'second@email\.address' \ 'set pgp_create_traditional=yes pgp_autoencrypt=yes' send-hook 'third@email\.address' 'set pgp_create_traditional=yes' Only mail to [EMAIL PROTECTED], [EMAIL PROTECTED] and [EMAIL PROTECTED] is encrypted the traditional way. The first line ensures that the default is to sent quality email. After postponing mail and restarting mutt of course I get the default non-traditional setting, even when recalling postponed messages. How can I keep the setting for postponed messages? Raoul Boenisch
postponed messages
Hi all. I'm using mutt 1.4 and folder-hooks to set from and return-path headers. The problem is that when i postpone a message and then send it, i'm loosing the return-path setup, and it's replaced by default folder-hook return-path. Is there any way to postpone a message and don't miss the return-path header? TIA -Eduardo -- Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. - Albert Einstein
Multiple postponed messages
Howdy, I'm just wondering if it's possible to have multiple postponed messages, as whenever I try to compose a new message, it loads the previously postponed message. TIA, David. -- All generalizations are false, including this one. -- Mark Twain - David Clarke [EMAIL PROTECTED] | David Clarke u3353950 Key Fingerprint : 869B 53DD 5E80 E1F0 93F6 9871 0508 0296 5957 F723
Re: Multiple postponed messages
On Feb 8, David Clarke wrote: I'm just wondering if it's possible to have multiple postponed messages, as whenever I try to compose a new message, it loads the previously postponed message. Sure it is posible to have multiple postponed msgs. You must have the quadoption 'postpone' set to yes (the default is ask-yes) as it loads the postponed msg automatically. Change it to another value. I prefer to have it set to 'no'. The default key for recalling postponed msgs is 'R'. Holger
Re: Multiple postponed messages
On Fri, Feb 08, 2002 at 08:42:21PM +1100, David Clarke wrote: I'm just wondering if it's possible to have multiple postponed messages, as whenever I try to compose a new message, it loads the previously postponed message. Yes. When you have more than one postponed messages, Mutt will show a list of them. -- Lorin Winchester [EMAIL PROTECTED] msg24322/pgp0.pgp Description: PGP signature
Re: Multiple postponed messages
On Fri, 08 Feb 2002, Holger Lillqvist wrote: Sure it is posible to have multiple postponed msgs. Once I have one postponed message, I am not able to compose new messages until I have sent the postponed messages, I am only able to compose replies, which I can then postpone. Is there a different command to compose a new message as opposed to what 'm' is bound to by default? David -- All generalizations are false, including this one. -- Mark Twain - David Clarke [EMAIL PROTECTED] | David Clarke u3353950 Key Fingerprint : 869B 53DD 5E80 E1F0 93F6 9871 0508 0296 5957 F723
Re: Multiple postponed messages
David Clarke wrote: On Fri, 08 Feb 2002, Holger Lillqvist wrote: Sure it is posible to have multiple postponed msgs. Once I have one postponed message, I am not able to compose new messages until I have sent the postponed messages, I am only able to compose replies, which I can then postpone. Is there a different command to compose a new message as opposed to what 'm' is bound to by default? perhaps you have 'recall' set to 'yes' instead of 'ask-yes'? w
Re: Multiple postponed messages
On Fri, 08 Feb 2002, Will Yardley wrote: perhaps you have 'recall' set to 'yes' instead of 'ask-yes'? That was exactly it! Thank-you. David -- All generalizations are false, including this one. -- Mark Twain - David Clarke [EMAIL PROTECTED] | David Clarke u3353950 Key Fingerprint : 869B 53DD 5E80 E1F0 93F6 9871 0508 0296 5957 F723
Batch sending postponed messages
Is there a way of sending all postponed messages as a batch without having to do them one at a time? -- Rod Pike rodneyp @ utanet.at
Re: Batch sending postponed messages
No. Actually, what you are describing heavily sounds like you should rather use your MTA's queue for the job. On 2001-05-31 22:27:37 +0200, Rod Pike wrote: Date: Thu, 31 May 2001 22:27:37 +0200 From: Rod Pike [EMAIL PROTECTED] To: Mutt-users [EMAIL PROTECTED] Subject: Batch sending postponed messages Mail-Followup-To: Mutt-users [EMAIL PROTECTED] User-Agent: Mutt/1.2.5i Is there a way of sending all postponed messages as a batch without having to do them one at a time? -- Rod Pike rodneyp @ utanet.at -- Thomas Roesslerhttp://log.does-not-exist.org/
Re: Batch sending postponed messages
Rod Pike [mutt-users] Thu, May 31, 2001 at 10:27:37PM +0200: Is there a way of sending all postponed messages as a batch without having to do them one at a time? As you're running sendmail see http://www.hserus.net/sendmail.html -- Suresh Ramasubramanian + Wallopus Malletus Indigenensis mallet @ cluestick.org + Lumber Cartel of India, tinlcI EMail Sturmbannfuhrer, Lower Middle Class Unix Sysadmin
Re: sending postponed messages
On Tue, Feb 20, 2001 at 12:54:21PM -0800, [EMAIL PROTECTED] wrote:
On Tue, Feb 20, 2001 at 08:11:22AM +0100, Pacholleck wrote:
I cannot afford long online times waiting that some sendmail
deceides to try delivery again or recalling every of all those
postponed in vi again.
If you're offline when you send messages (not postpone them),
sendmail should queue the messages. When you're online again, "sendmail -q"
should flush the queue, i.e., send all the messages in the queue.
Have a look at:
http://lists.suse.com/archives/suse-linux-e/2000-Jun/2112.html
http://cork.linux.ie/projects/install-sendmail/
I'd like to add another Sendmail tip:
So that Sendmail doesn't take long to return to Mutt when it runs
while sending a message, you might also consider using its -odd
option.
"-o" some configuration [o]ption
"d" the [d]elivery mode option
"d" delivery mode "[d]eferred", which is like queued, but also skips
initial DNS lookups.
This is what I do. In fact, my sendmail Mutt variable is set to a
shell script which looks through the numeric ("-n") output of
netstat(1) for the default ("0.0.0.0") route. Since I generally use
the "defaultroute" option to pppd(8), when I'm online, a default route
will be present, but will be absent while offline:
#!/bin/bash
sendm='/usr/sbin/sendmail -oem -oi'
if netstat -nr | grep '^0\.0\.0\.0' /dev/null 21
then # there is a default route; we're on the Internet
: # so do nothing extra
else # we aren't, so use the Sendmail defer option
sendm="$sendm -odd"
fi
exec $sendm "$@"
I hope you Mutt w/ Sendmail users like this :-)
--
Oo---o, Oo---o, O-weem-oh-wum-ooo-ayyy
In the jungle, the silicon jungle, the process sleeps tonight.
Joe Philipps [EMAIL PROTECTED], http://www.philippsfamily.org/Joe/
public PGP/GPG key 0xFA029353 available via http://www.keyserver.net
PGP signature
Re: sending postponed messages
( Die, 20 Feb 2001 ) [EMAIL PROTECTED] -- : If you're offline when you send messages (not postpone them), sendmail should queue the messages. When you're online again, "sendmail -q" should flush the queue, i.e., send all the messages in the queue. ( Mit, 21 Feb 2001 ) BWise -- : Erika, don't throw Mutt out! I'm on a dial-up connection (as you are) and have a script run by a cron-daemon which connects me to my isp, checks my various mail accounts, and sends queued mail (using "sudo qsend" so that I do not have to be logged in as root) at regular intervals. And at this moment I have in the neighborhood of a half-dozen postponed messages in Mutt. Ok, in kmail I made myself a folder out.wait for drafts besides out. But you are right sendmail -q does the trick - for god sake this is not one of those postfix's sendmail commands whith (ignored:), so I only have to discipline myself that sent is nearly out and not longer a draft ... But better than this mousing around - and no I do not intend to throw Mutt out but kmail as soon as I got my headers correct. And of course I will end up with scripting the whole thing, that's at least what I exactely know how to do it ;) Thanks to all for that hint. Erika
Re: sending postponed messages
Erika Pacholleck proclaimed on mutt-users that: But better than this mousing around - and no I do not intend to throw Mutt out but kmail as soon as I got my headers correct. Try my howto at http://www.hserus.net/dlhowto.html (email on a dialup). That's a howto on how to configure sendmail + mutt on a dialup. There's also a copy of my .muttrc in case you are interested. -s -- Suresh Ramasubramanian + Wallopus Malletus Indigenensis mallet @ cluestick.org + Lumber Cartel of India, tinlcI EMail Sturmbannfuhrer, Lower Middle Class Unix Sysadmin
sending postponed messages
I have already been through dejanews for search and as far as I understood form the thread it is really not possible to send the postponed messages in one bunch once I am connected to the net? Can't really believe that there is not yet a solution out there from one of all those mutt users, but unfortunately those I asked told me well, I am always online, that doesn't touch me. I cannot afford long online times waiting that some sendmail deceides to try delivery again or recalling every of all those postponed in vi again. Just began to love mutt and if someone helps with this one now I could just throw away all the other stuff. Thank you. Erika
Re: sending postponed messages
Erika, Wouldn't that be a function of sendmail's mail queue? I know sendmail can be configured to send mail when connected. The mail queue is pretty powerful, so your solution might lie there. * Pacholleck ([EMAIL PROTECTED]) wrote: I have already been through dejanews for search and as far as I understood form the thread it is really not possible to send the postponed messages in one bunch once I am connected to the net? Can't really believe that there is not yet a solution out there from one of all those mutt users, but unfortunately those I asked told me well, I am always online, that doesn't touch me. I cannot afford long online times waiting that some sendmail deceides to try delivery again or recalling every of all those postponed in vi again. Just began to love mutt and if someone helps with this one now I could just throw away all the other stuff. Thank you. Erika
Re: sending postponed messages
On Tue, Feb 20, 2001 at 08:11:22AM +0100, Pacholleck wrote: I have already been through dejanews for search and as far as I understood form the thread it is really not possible to send the postponed messages in one bunch once I am connected to the net? I cannot afford long online times waiting that some sendmail deceides to try delivery again or recalling every of all those postponed in vi again. If you're offline when you send messages (not postpone them), sendmail should queue the messages. When you're online again, "sendmail -q" should flush the queue, i.e., send all the messages in the queue. Have a look at: http://lists.suse.com/archives/suse-linux-e/2000-Jun/2112.html http://cork.linux.ie/projects/install-sendmail/ HTH, -rex -- Photons have mass? I didn't even know they were Catholic.
Re: sending postponed messages
[EMAIL PROTECTED] proclaimed on mutt-users that: On Tue, Feb 20, 2001 at 08:11:22AM +0100, Pacholleck wrote: I have already been through dejanews for search and as far as I understood form the thread it is really not possible to send the postponed messages in one bunch once I am connected to the net? It is, very much so Have a look at: http://lists.suse.com/archives/suse-linux-e/2000-Jun/2112.html http://cork.linux.ie/projects/install-sendmail/ Or my howto at http://www.hserus.net/dlhowto.html (which has a copy of my muttrc as well -- mentioned for the sake of staying on topic for the mutt-users list g) -- Suresh Ramasubramanian + Wallopus Malletus Indigenensis mallet @ cluestick.org + Lumber Cartel of India, tinlcI EMail Sturmbannfuhrer, Lower Middle Class Unix Sysadmin
Re: sending postponed messages
Erika, don't throw Mutt out! As others have mentioned, the solution is in the mail queue, not in the postpone function of Mutt. The postpone feature of Mutt applies only to the drafting of messages, not to sending them. IOW, the postpone feature allows you to save the message you are composing so you can finish it later without queuing it for send. I'm on a dial-up connection (as you are) and have a script run by a cron-daemon which connects me to my isp, checks my various mail accounts, and sends queued mail (using "sudo qsend" so that I do not have to be logged in as root) at regular intervals. And at this moment I have in the neighborhood of a half-dozen postponed messages in Mutt. On Tue, Feb 20, 2001 at 08:11:22AM +0100, Pacholleck wrote: I have already been through dejanews for search and as far as I understood form the thread it is really not possible to send the postponed messages in one bunch once I am connected to the net? Thank you. Erika -- HTH, BWise
Re: sending postponed messages
On Tue, Feb 20, 2001 at 12:54:21PM -0800 or so it is rumoured hereabouts, [EMAIL PROTECTED] thought: On Tue, Feb 20, 2001 at 08:11:22AM +0100, Pacholleck wrote: I have already been through dejanews for search and as far as I understood form the thread it is really not possible to send the postponed messages in one bunch once I am connected to the net? I cannot afford long online times waiting that some sendmail deceides to try delivery again or recalling every of all those postponed in vi again. If you're offline when you send messages (not postpone them), sendmail should queue the messages. When you're online again, "sendmail -q" should flush the queue, i.e., send all the messages in the queue. Have a look at: http://lists.suse.com/archives/suse-linux-e/2000-Jun/2112.html http://cork.linux.ie/projects/install-sendmail/ I used install-sendmail to get set up initially and then use a script that gets fired up when I go online to do a 'sendmail -q' to send queued mail. There's a few other things that happen with that script like: firing up my firewall, fetching mail from numerous pop servers and fetching news for my local news server. That's available if you want but you need to check out how to start a script once you go online (I use diald which has an option for a "just connected" script). -- Conor Daly [EMAIL PROTECTED] Domestic Sysadmin :-) - faenor.cod.ie 12:48am up 120 days, 7:17, 0 users, load average: 0.08, 0.02, 0.01 Hobbiton.cod.ie 12:53am up 25 days, 14:43, 1 user, load average: 0.00, 0.00, 0.00
Stale ^From lines in my copies of sent postponed messages
[hmmm... did it again... answered my question as I was composing it... but thought the group might be interested...] Original question = Greetings! This is a minor annoyance, but I thought I'd ask about it anyway. If I postpone a message and send it, say, three days later, the "^From " line that gets sent with the message (at least in my own bcc'd copy) contains the date and time corresponding to when I last postponed the message (i.e., three days ago). So my bcc'd copy of such a message that I send will have the "correct" date in the Date: header, i.e., the Date: header will contain the date and time at which I sent the message. But the "^From " line will have a date from three days ago (in my current example). This messes up the date-received order of a mail folder. I realize I could sort the folder by date, and the message would appear in the correct order, but sometimes I need to sort by date-received. Can I somehow get mutt to send "fresh" "^From " lines when sending postponed messages? This seems like a bug to me, as it misrepresents the date and time a message was received. Thanks! David Answer == The stale "^From " lines were showing up in my bcc copies, so I thought I better see if they showed up in actual received copies of the postponed-but-then-sent messages. So I went into my postponed folder and sent a message to another of my accounts. The "^From " line contained the "fresh" date, i.e., a time which occurred after the message was actually sent. Then it dawned on me: when I keep copies of non-mailing-list email that I send to folks, I use *fcc*, not bcc to keep a copy! And fcc just blindly appends the message to a file, whereas actually sending the message, a recipient (whether a To:, Cc:, or Bcc: recipient) has the advantage of their local mail transport agent inserting the correct date in the "^From " line. (Oh yeah, I forgot that the MTA does that. [sound of palm hitting head]) So, now I'll bcc myself instead of fcc'ing a folder when I send previously postponed messages. No bug. User error! :-) -- Live in a world of your own, but always welcome visitors.
postponed messages to =sent?
Is mutt supposed to FCC a postponed message to =sent? This server had a problem the other day where exim ran out of disk space to I could not send mail, so I posponed it until I could send it. After doing this a few times it sent. I just went into =sent and found a copy of those mails for every time I postponed it. -Ken -- [EMAIL PROTECTED]AIM: ScopusFest
Re: postponed messages to =sent?
mutt copies the message to the sent folder and then calls the MDA. So if the MDA fails, the copy to sent mail is already made. Postponing it just makes the correct copy that you think it does. randy On Sun, Sep 26, 1999 at 09:54:02PM -0400, Ken W wrote: Is mutt supposed to FCC a postponed message to =sent? This server had a problem the other day where exim ran out of disk space to I could not send mail, so I posponed it until I could send it. After doing this a few times it sent. I just went into =sent and found a copy of those mails for every time I postponed it. -Ken -- [EMAIL PROTECTED]AIM: ScopusFest -- Five hundred, twenty-five thousand six hundred minutes, how do you measure...? [EMAIL PROTECTED] http://www.louisville.edu/~rjmill01/ Triangle Fraternity http://www.louisville.edu/rso/triangle/ Association for Computing Machinery http://acm.louisville.edu/
Re: Re: sending postponed messages
on Apr 28, Stefan `Sec` Zehl wrote:
On Wed, Apr 28, 1999 at 12:36:55PM +0200, Renaud Colinet wrote:
Hi
when i recall a postponed message, the only thing I can do (afaik) is press
return, which brings me in insert mode. To send the message I have to exit
the editor and send. Is it possible to skip this phase and send the message
without editing ? (the 'y' key has no effect in this mode)
You probably could archive something like that with
macro postpone y ":set editor=touch\nreturn:set editor='vim'\ny"
Hmm, mutt complains at startup: no such menu
I tried 'postponed' instead of 'postpone' (the former seems more likely from
what I read in the manual), but I get the same message.
I wonder if it recognizes this menu (maybe a problem of version, I use version
0.91.1)
Any hint appreciated
--
___
{~._.~}Renaud COLINET |
( Y ) [EMAIL PROTECTED] |
()~*~()(33)1 48 42 22 80 (home) |
(_)-(_)(33)1 41 75 31 37 (off) |
Re: Re: sending postponed messages
On Thu, Apr 29, 1999 at 06:09:00PM +0200, Renaud Colinet wrote: Hmm, mutt complains at startup: no such menu I tried 'postponed' instead of 'postpone' (the former seems more likely from what I read in the manual), but I get the same message. I wonder if it recognizes this menu (maybe a problem of version, I use version 0.91.1) I use 95.4i and it works here. So I think you migt try upgrading your mutt. CU, Sec -- The attached bug will fix that. -- Byrial Jensen [EMAIL PROTECTED] on mutt-dev/21.7.98
sending postponed messages
Hi
when i recall a postponed message, the only thing I can do (afaik) is press
return, which brings me in insert mode. To send the message I have to exit
the editor and send. Is it possible to skip this phase and send the message
without editing ? (the 'y' key has no effect in this mode)
TIA
--
___
{~._.~}Renaud COLINET |
( Y ) [EMAIL PROTECTED] |
()~*~()(33)1 48 42 22 80 (home) |
(_)-(_)(33)1 41 75 31 37 (off) |
