Re: sending automated GPG signed mails from batch job
googly.negotiator...@aceecat.org (12024-05-21): > > The problem with any automation, anyway if with GnuPG or not, is how > > to enter the passphrase or PIN to get access to the private key. > Does the gpg-agent help with that? It is supposed to, I think. Makes it worse. Without gpg-agent, your automation process needs to manage the key or their pass phrases securely. With gpg-agent, your automation process needs to manage the key their pass phrases securely AND manage the lifetime of the agent. Regards, -- Nicolas George
Re: sending automated GPG signed mails from batch job
Matthias Apitz (12024-05-21): > I do use GnuPG based on OpenPGP SIM cards even in my Linux telephone > (Pusim L5) for crypting files, ~350 passwords (password-store) and SSH > connections (the RSA secret is on the OpenPGP card). All works fine and > gives access to the secrets by entering a 6 digit PIN: For interactive basic use, GPG is fine. > The problem with any automation, anyway if with GnuPG or not, is how to > enter the passphrase or PIN to get access to the private key. For automation, the key must be unencrypted during the operation. Or the process must have the pass phrase available, which is equivalent. The problem is the agent. GPG now insists to handle all private key operations through an agent started automatically in the background. The control over the behavior of the agent is very limited. For interactive use it is fine, you just let your session manage it. But for automation and tests, you need control. Also, GPG has its system of trust. For interactive use it is still fine. But for automation, we need to control which key we use without some stupid software deciding we are not allowed because it is not trusted. Agents and trust are high-level issues. Proper design requires low-level tools that do their job and no more, “Keep It Simple Stupid” and high-level tools on top of it. GPG does not have the low-level tools, that makes it unsuitable for automation. With sq, no such problem, the keys are in pairs of files, it uses the ones you tell it to use. Regards, -- Nicolas George
Re: sending automated GPG signed mails from batch job
Matthias Apitz (12024-05-21): > How could we expand this for signing mails on the fly? Hi. For fine control, I would suggest: - Build your mail entirely yourself without relying on a MUA like mutt and inject it directly into the MTA local injector /usr/lib/sendmail. - Ditch GPG. GPG has been increasingly incapable of deciding if it is a high-level tool or a low-level tool and batch operation has become increasingly hard or impossible. Instead, you can use Sequoia / sq, a low-level tool suitable for automation. Regards, -- Nicolas George
Re: Default save mailbox from a script
Hi. Cameron Simpson (12023-07-31): > Yes. For something to run lateryou would need to quote them (to defer their > interpretation). But it won't help with save-hook because it does not, > itself, run a command. Thanks for confirming what I suspected. > I take it that you can't easily express what you want with a collection of > save hooks in the right order with clever patterns. My main purpose is to group threads in the same mailbox. For that, the external command will have an index of all the message-id in my archives, as people can reply months later. That would be too big. Also, I might want to take a shot at the “gzip classifies better than large language models” thing. > Go the macro, rebinding the "s" keystroke. That way it only fires when you > try to save. The command can be used to feed the message > content to your script. Some macro which went: > > your_script.sh >mutt-commands.txt > source mutt-commands.txt > Thanks, that will save me a little time to figure out the syntax. Jon LaBadie (12023-07-31): > An alternative approach that I'm not sure is possible. > > If during delivery of your mail it is passes through > a filter like "procmail" before hitting your Inbox, > have the filter invoke your hueristics program "guess". Thanks. I had considered something like that. But the guess on a mail received at 13:00 and read at 15:02 might depend on the choice I made on a mail received at 12:00, read at 14:00 and saved at 14:01. (I am considering doing away with the concept of mailboxes entirely in my use case, and instead have a program populate a maildir in a tempfs with mails based on a search criteria, but that will require a little more work.) Regards, -- Nicolas George signature.asc Description: PGP signature
Default save mailbox from a script
Hi.
I want to use an external command to decide in what mailbox to save
messages.
When I hit ‘s’ with its default action of save-message, mutt asks
“Save to mailbox ('?' for list): =ml/debian”, with the default being
chosen from save-hooks or from the author of the mail.
What I want is that it invokes an external command to set the default.
The idea is that the external command has access to an index of my
mailboxes and implements heuristics of my choosing to store the mail,
but I can still use Mutt's user interface to make a different decision.
What I want could look a little bit like:
save-hook * `~/local/lib/guess_mailbox`
Except it does not work in two ways:
- the backticks are evaluated once when loading the configuration, they
need to be evaluated when saving the message, each time;
- the command in the backticks need access to the content of the mail.
I am considering a solution based on a macro that pipes the message to
the command and generate a temporary configuration file, then sources it
then saves normally.
Also, I would like to avoid any solution that would slow down Mutt when
I am not trying to save a message. A message-hook invoking guess_mailbox
would probably not be acceptable, for example.
Any advice?
Thanks in advance.
--
Nicolas George
signature.asc
Description: PGP signature
Re: order of sending mail and saving to fcc
I can only say, Erik wrote the answer I wanted to write. @Kevin: The new change sounds very promising. Thank you for that and all your work! @Derek: I've read your mails in this thread, and I'm in no way convinced. HAND Nicolas
Re: order of sending mail and saving to fcc
* Derek Martin [2019-06-11 12:47 -0500]: > Not only that, but I neglected the fact that if the send fails, the > file your editor produced in order for it to be passed to Mutt will > still be on disk, so you do IN FACT still have a copy of the message. I did just (using my old mutt) set sendmail to killall -9 mutt. The temporay file that stayed on my disk did contain my text. But there was no other information (recipients, subject, attachments). So if the tmpdir survives, not everything is lost. But the mail as such is lost. > That is, barring catastrophic system failure, which no mail client > will ever save you from. Data loss in case of a catastrophic system failure is not the thing to argue about. The thing to argue about is, which case of events is made catastrophic by mutt. HAND Nicolas
Re: order of sending mail and saving to fcc
* Derek Martin [2019-06-11 12:36 -0500]: > On Tue, Jun 11, 2019 at 10:04:25PM +1000, Erik Christiansen wrote: > > In the event that send fails, the local copy is essential for a resend > > attempt. No ifs, no buts, no maybes. I'm at a loss to imagine any > > scenario in which mutt should risk inability to write that Fcc, through a > > hang-up or conniption during sending. > > This argument seems like complete nonsense to me... if the send > fails, you're left back at the compose screen. If by some > unbelievable coincidence the send fails AND you lose power before you > can do something about it, this is NO DIFFERENT than if the power went > out just before you finished composing the message. It is different. In one case nobody has my mail. In the other case the recipient might have it, but the sender does not. > It's not your > mail client's job to protect you from every conceibable system failure > which might cause data loss, nor should it be. Of course it is not its job. If my computer melts to a blob of something, that is not mutt's problem. But it is mutt's job to make it easier (or even possible without arcane workarounds) to avoid more or less simple problems. Diskless workstations loosing their connectivity at the worst moment. Crashing systems. ... > And for every other > case, the current behavior is the far superior one because it can not > mislead you into thinking you sent a message you did not, and does not > lead to the various encoding issues Kevin mentioned separately. It is quite easy to have a setup, where I can verify if the mail was sent if there is any doubt. The new behavior does create a situation that makes it much more likely to create a situation where I have to ask e.g. a client for a mail I sent to him. That would be quite embarrasing without some good explanation (like a major event, like a house which burned down). > But also, just because the message failed to send, your ideas and the > impetus for writing them down didn't vanish. Your brain is the > back-up. Ahm. No. Any temporary information copied into the mail is just not in my brain. Anything where the exact wording is important cannot be reproduced (so the recipient gets two mails that are different, and the sender only knows one of them). > In the event that the message in question is the unusual > combination of lengthy, complex, and important enough that the pain of > re-composing it from scratch is somehow prohibitive, then you damn > well better be composing it using a word processor that takes frequent > snapshots of your document as you compose, and then sending it as an > attachment (or as a link, or by doing a text conversion, or... > whatever)--not relying on your mail client to preserve it. I'm relying on my mail client, that it safely stores a message of every message sent. > And by the > way even then, you can't guarantee 100% that you won't lose the data. > Your hard disk could explode, say due to a lightning strike. No > software can't protect you from that. At a certain point such > considerations become completely ridiculous. Yeah. But that is no reason to not protect from things it can protect me easily from by just storing the message before sending it. I do not want to protect mutt my mail from a supernova in my hard disk. I consider it quite absurd to use such an argument: "Why should I ever call fsync? The computer may be struck by lightning and might get lost completely." > I hesitate to go far as to say that if you think saving the message > first is the right behavior, you are simply wrong... but I'm > definitely thinking it. =8^) You might consider it wrong but I do not seem to be the only one thinking the old order is the correct one. Considering how often I heard other people swear because they lost some sent mail, because their MUA crashed after sending and before storing it, this does just seem to be the wrong order. Nicolas
Re: order of sending mail and saving to fcc
* Derek Martin [2019-06-11 12:16 -0500]: > On Mon, Jun 10, 2019 at 11:24:11AM +0200, Nicolas Rachinsky wrote: > > * Jack M [2019-06-04 10:20 -0500]: > > > On Tue, June 4, 2019 5:30 am, Nicolas Rachinsky wrote: > > > > The other one (mail sent, but no local copy) > > > > > > Why would this situation would ever occur? > > > > A power failure at the wrong moment. A crash at the wrong moment. ... > > > > These things tend to happen only at wrong moments. > > But the failure mode of the current behavior is superior: With the > old way, you look in Fcc and see the message was sent, so you don't > send it again (unless you're unusually paranoid, maybe). But I cannot create the same message again. > With the current way, you see there's no message in Fcc, and you send > it again. If I do not have the message, how do I send it again? > And by the way, changes like this one don't happen in a vaccuum. The > change was discussed on mutt-dev at some length when it happened, and > it was eventually agreed that the new behavior is the right one. Thanks to Kevin J. McCarthy who referred me to it. I habe read it, but I did not find any convincing argument. HAND Nicolas
Re: order of sending mail and saving to fcc
* Ben Boeckel [2019-06-10 11:56 -0400]: > If you're this paranoid, the only real fix is to have your editor save a > backup somewhere before handing it off to mutt in the first place > anyways. After all, mutt could segfault and lose it before the Fcc! There is one big difference. If mutt crashes before saving the mail to fcc, nobody has one. So this avoids the problem with sent mail without any local copy. I have a related question: When does mutt unlink attached files (with unlink set)? Before sending, between sending and fccing or after fccing? Nicolas
Re: order of sending mail and saving to fcc
* Francesco Ariis [2019-06-04 19:52 +0200]: > Hello Grant, > > On Tue, Jun 04, 2019 at 04:46:50PM -, Grant Edwards wrote: > > On 2019-06-04, Jack M wrote: > > > > > The reason (or *a* reason) is that the old way led to the following > > > situation: Fcc first, then try to send, something weird happens, but > > > the user has no idea whether the mail was actually sent or not > > > > How could the user not know? If the send fails, mutt prints an error > > message and stays on the message compose screen. It's pretty > > obvious... > > I have the bad habit of pressing 'q' (exit to menu) after sending. > Also terminal corruption or similar events: you can't be sure whether > the message was actually sent. With the new order this behaviour might lead to a sent mail without a local copy. If you miss the failure to send, you might as well miss the failure to fcc. HAND Nicolas
Re: order of sending mail and saving to fcc
* Jack M [2019-06-04 10:20 -0500]: > On Tue, June 4, 2019 5:30 am, Nicolas Rachinsky wrote: > > The other one (mail sent, but no local copy) > > Why would this situation would ever occur? A power failure at the wrong moment. A crash at the wrong moment. ... These things tend to happen only at wrong moments. HAND Nicolas
Re: order of sending mail and saving to fcc
* "Kevin J. McCarthy" [2019-06-04 09:44 -0700]: > On Tue, Jun 04, 2019 at 12:30:59PM +0200, Nicolas Rachinsky wrote: > > Does anybody know the reason of this change? > > The most recent discussion on mutt-dev was > <https://marc.info/?l=mutt-dev=146942930418541=2>. The issue is > contentious, and there are arguments on both sides. Thank you for the reference. > In this case, the comments by active developers seemed to be in consensus > that prompting if Fcc fails afterwards is a reasonable compromise. Ok, so I will replace $sendmail by something that saves the mail first, since not having a local copy of a sent mail (for an easily avoidable reason) is just not acceptable here. :( have a nice day Nicolas
order of sending mail and saving to fcc
Hallo, I just noted the entry in UPDATING: ! Fcc now occurs after sending a message. If the fcc fails, mutt will prompt to try again, or to try another mailbox. This seems to be: https://gitlab.com/muttmua/mutt/commit/e106487b1f4ebe7128982486accec11ac6f54b5c Does anybody know the reason of this change? I considered the previous order (save to fcc, then send the mail) always the correct one. If anything bad happens (network connectivity failing (in case of imap), computer crashing,...), it seems to produce the better outcome. The situation where I have the mail locally, but it was not sent can easily recovered on my side. The other one (mail sent, but no local copy) cannot be always recovered without contacting the recipient. Thank you in advance. Nicolas
Re: Add header to local copy of sent messages
* tj 78...@web.de [2013-04-22 17:59 -0400]: I use fcc_clear to store unencrypted copies of encrypted sent messages. Now I would like to add an extra header field to these local copies (for later reference), but not to the mail that is being sent out. Is this possible with mutt? I could not find a solution in the manual or online. I have no idea to achieve that directly. But you could store these mails to a special fcc. Then a cronjob might add the header and move them to your usual fcc. Similarly, I would like to add an extra header field to decrypted copies of encrypted mails that were sent to me. Is there a command that adds a custom header field, which I could bind to a custom key? decrypt-save to a special folder and call some script afterwards to add the header and move the mail. HTH Nicolas -- http://www.rachinsky.de/nicolas
Re: opening +[Gmail]/All Mail is slowish
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/09/13 02:37, James Griffin wrote: Mon 8.Apr'13 at 8:55:16 -0600 Nicolas Bock Hi all, that makes a lot of sense. I just double checked with TB and yes, it is basically the same speed. Synchronizing the headers takes forever :) I will have to start labelling emails much more aggressively, thanks for the tip! nick On Sat, Apr 06, 2013 at 11:31:53AM +0200, Jonny Oschätzky wrote: Hi Nick, The local read test really seems to indicate that it's not the database backend that is controlling performance when switching folders here. It is presumable network communication with Google's imap servers. And that presumably means that I can't do much about it, or can I? I can confirm this. If you have a big mailbox (my All Mail contains ~150,000 messages), then the Google IMAP server is very slow. I've checked this with Thunderbird and the result is mostly the same. TB opens the box very fast and then it takes a long time to update the header cache. The IMAP protocol itself causes this, because it needs to synchronize the folder. The bigger a folder is the longer this process takes. I solved this problem for me with offlineimap and archivemail. I don't need the All Mail folder since I use labels for all my stuff and mailing lists. So it results in different Maildirs on my PC which are synchronized by offlineimap in the background. Older mail is archived by archivemail in gzipped mboxes. That works great. :) Jonny Purely just out of curiosity, why would you need to keep such a high number of email? Is this something quite common (at risk of sounding a bit stupid)? I just can't imagine ever keeping that much email in my account. That's a good question. The thing is that since Google's webinterface makes searching for messages and opening folders so painless it never occurred to me that that's a large number. Only after I started becoming a little bit more paranoid somewhat recently and attempted to back up my emails and set up gpg, did I start to understand that there are limitations with this amount of data. So I take it that you simply delete old emails? Or do you have some archiving protocol? nick -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFkEJEACgkQf15tZKyRylI01ACfVfTsMEblM1Cb12sELwLE21oc zTgAnjr0PKOQ2zy5hjqPU7xB7Y2A+I8k =2SEw -END PGP SIGNATURE-
Re: Deleting messages on Gmail crashes mutt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/08/13 10:29, Michael Elkins wrote: On Fri, Apr 05, 2013 at 10:29:49AM -0600, Nicolas Bock wrote: I use mutt with imap.gmail.com. When I delete a message, I move it to +[Gmail]/Trash which seems to confuse mutt. When everything works fine, all I get is the mailbox was modified externally, and the message simply disappears. Sometimes however, mutt tells me no visible message and I have to change folders to be able to see anything in my INBOX again. Other times mutt segfaults. Which version of Mutt are you using? If you could provide a gdb backtrace the next time the crash happens that would be useful. Also, if you have compiled Mutt yourself with debugging enabled, you can run mutt -d 5 and in ~/.muttdebug0 the IMAP conversation will be recorded, which would be useful in figuring out what is happening. I have been using mutt -d 5 for a while now, and see the following: When I delete, that is move a message to the [Gmail]/Trash folder, then sometimes mutt tells me that there are no visible messages, and the INBOX folder is basically closed. I have to reopen it. But I can't find any error or warning in the log files. I will attempt a backtrace when this happens again. nick -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFkElgACgkQf15tZKyRylJrAQCgojZB6xukWhSH5k0GWlkgU10j V9gAoJkQUcoRQQSCH/6iBIujqmJMFD12 =jQGy -END PGP SIGNATURE-
Re: opening +[Gmail]/All Mail is slowish
Hi all, that makes a lot of sense. I just double checked with TB and yes, it is basically the same speed. Synchronizing the headers takes forever :) I will have to start labelling emails much more aggressively, thanks for the tip! nick On Sat, Apr 06, 2013 at 11:31:53AM +0200, Jonny Oschätzky wrote: Hi Nick, The local read test really seems to indicate that it's not the database backend that is controlling performance when switching folders here. It is presumable network communication with Google's imap servers. And that presumably means that I can't do much about it, or can I? I can confirm this. If you have a big mailbox (my All Mail contains ~150,000 messages), then the Google IMAP server is very slow. I've checked this with Thunderbird and the result is mostly the same. TB opens the box very fast and then it takes a long time to update the header cache. The IMAP protocol itself causes this, because it needs to synchronize the folder. The bigger a folder is the longer this process takes. I solved this problem for me with offlineimap and archivemail. I don't need the All Mail folder since I use labels for all my stuff and mailing lists. So it results in different Maildirs on my PC which are synchronized by offlineimap in the background. Older mail is archived by archivemail in gzipped mboxes. That works great. :) Jonny signature.asc Description: Digital signature
Re: read messages don't appear read on Gmail
Thanks for the tip! Just a quick question though, how do you hide a folder from the folder list? Thanks, nick On Mon, Apr 08, 2013 at 11:26:17AM +0300, Nikola Petrov wrote: I didn't find a solution to this. Basically I just hide the All Mail folder from the list of mailboxes in my config. I can still switch to it in the folder view but It doesn't break my workflow. -- Nikola On Fri, Apr 05, 2013 at 10:33:30AM -0600, Nicolas Bock wrote: Hi, I use imap.gmail.com. I noticed that when I read messages and then archive them, by marking the message as deleted in the inbox, the message shows up as unread in the +[Gmail]/All Mail folder. If I re-sync the +INBOX before I archive the message everything works as expected, i.e. the message is marked read in All Mail. Is there a way around this manual re-syncing? Thanks, nick signature.asc Description: Digital signature
Re: Deleting messages on Gmail crashes mutt
On Mon, Apr 08, 2013 at 04:29:27PM +, Michael Elkins wrote: On Fri, Apr 05, 2013 at 10:29:49AM -0600, Nicolas Bock wrote: I use mutt with imap.gmail.com. When I delete a message, I move it to +[Gmail]/Trash which seems to confuse mutt. When everything works fine, all I get is the mailbox was modified externally, and the message simply disappears. Sometimes however, mutt tells me no visible message and I have to change folders to be able to see anything in my INBOX again. Other times mutt segfaults. Which version of Mutt are you using? If you could provide a gdb backtrace the next time the crash happens that would be useful. 1.5.21 I will try to get a backtrace next time. Also, if you have compiled Mutt yourself with debugging enabled, you can run mutt -d 5 and in ~/.muttdebug0 the IMAP conversation will be recorded, which would be useful in figuring out what is happening. I will try that too. Thanks, nick signature.asc Description: Digital signature
Re: opening +[Gmail]/All Mail is slowish
On Fri, Apr 05, 2013 at 02:19:01PM -0700, Brendan Cully wrote: On Friday, 05 April 2013 at 15:12, Nicolas Bock wrote: On Fri, Apr 05, 2013 at 10:52:51PM +0200, Patrick Ben Koetter wrote: * Nicolas Bock nicolasb...@gmail.com: Hi, I have about 190,000 messages in my +[Gmail]/All Mail folder. Changing to that folder always takes a minute or two despite the fact that I am using header_cache. Is there something else I could do to speed up opening large folders? Something along these lines? # Caching set header_cache=~/.mutt/.cache/ set tmpdir=~/.mutt/.tmp/ set message_cachedir=~/.mutt/.messages/ set message_cache_clean = no Thanks. So far it doesn't seem to make much difference though. I compiled mutt with gdbm, does anyone know whether other database backends make a difference in terms of performance? tokyocabinet should be noticeably faster. I forgot to mention that according to: http://fallabs.com/tokyocabinet/benchmark.pdf it depends a bit on what API one uses with tokyocabinet. I don't know what mutt is using though. nick signature.asc Description: Digital signature
Deleting messages on Gmail crashes mutt
Hi, I use mutt with imap.gmail.com. When I delete a message, I move it to +[Gmail]/Trash which seems to confuse mutt. When everything works fine, all I get is the mailbox was modified externally, and the message simply disappears. Sometimes however, mutt tells me no visible message and I have to change folders to be able to see anything in my INBOX again. Other times mutt segfaults. So my question is really twofold. (1) Is moving message to [Gmail]/Trash the right thing to do if I want to delete a message from Gmail? (2) Is there a work-around or something I could do differently to prevent mutt from acting up? Thanks, nick
opening +[Gmail]/All Mail is slowish
Hi, I have about 190,000 messages in my +[Gmail]/All Mail folder. Changing to that folder always takes a minute or two despite the fact that I am using header_cache. Is there something else I could do to speed up opening large folders? Thanks, nick pgp0NPqeAd0HK.pgp Description: PGP signature
Re: opening +[Gmail]/All Mail is slowish
On Fri, Apr 05, 2013 at 10:52:51PM +0200, Patrick Ben Koetter wrote: * Nicolas Bock nicolasb...@gmail.com: Hi, I have about 190,000 messages in my +[Gmail]/All Mail folder. Changing to that folder always takes a minute or two despite the fact that I am using header_cache. Is there something else I could do to speed up opening large folders? Something along these lines? # Caching set header_cache=~/.mutt/.cache/ set tmpdir=~/.mutt/.tmp/ set message_cachedir=~/.mutt/.messages/ set message_cache_clean = no Thanks. So far it doesn't seem to make much difference though. I compiled mutt with gdbm, does anyone know whether other database backends make a difference in terms of performance? Thanks, nick pgp7oY1MlAIG6.pgp Description: PGP signature
Re: opening +[Gmail]/All Mail is slowish
On Fri, Apr 05, 2013 at 02:19:01PM -0700, Brendan Cully wrote: On Friday, 05 April 2013 at 15:12, Nicolas Bock wrote: On Fri, Apr 05, 2013 at 10:52:51PM +0200, Patrick Ben Koetter wrote: * Nicolas Bock nicolasb...@gmail.com: Hi, I have about 190,000 messages in my +[Gmail]/All Mail folder. Changing to that folder always takes a minute or two despite the fact that I am using header_cache. Is there something else I could do to speed up opening large folders? Something along these lines? # Caching set header_cache=~/.mutt/.cache/ set tmpdir=~/.mutt/.tmp/ set message_cachedir=~/.mutt/.messages/ set message_cache_clean = no Thanks. So far it doesn't seem to make much difference though. I compiled mutt with gdbm, does anyone know whether other database backends make a difference in terms of performance? tokyocabinet should be noticeably faster. I have recompiled mutt a few times now with different database backends. This is really only a quick and dirty benchmark, so I might very well have missed something. First I deleted the header cache and timed switching to All Mail: Cold connection without headers database: 2'56 Then I switched back and forth between All Mail and INBOX a few times and timed opening All Mail when it was cached: Tokyocabinate without compression: 59 Tokyocabinate with compression: 54 qdbm with compression: 56 gdbm: 56 As you can see, I didn't measure much performance difference between the different backends, although tokycabinet is slightly faster than the rest. Then I did the same test on a local copy of the folder (using offlineimap): on local copy of All Mail: 6 Again there wasn't much difference between the backends. The local read test really seems to indicate that it's not the database backend that is controlling performance when switching folders here. It is presumable network communication with Google's imap servers. And that presumably means that I can't do much about it, or can I? nick signature.asc Description: Digital signature
Re: save-message makes a copy instead of a hardlink - why?
* Derek Martin inva...@pizzashack.org [2013-02-02 11:44 -0600]: [save-message] Now, I will grant you, this feature is a bit schizophrenic. It also assumes that once it has done whatever it's going to do, that you no longer want the existing copy of the message, and marks it for deletion. At which point I have to go and undelete it, which I've always found annoying. Because when I use this feature, I do in fact want a separate copy of the message. Pretty much always. I suspect that it behaves this way because ME (I'm assuming) decided that the two operations, moving a message to another folder, and saving a message to a file, were functionally equivalent, and therefore elected for the economy of only implementing one. Trouble is, in neither case does it really do what the user wants it to do, IMO. What the user really wants, I believe, are the three behaviors I described above. There is copy-message (bound to C by default). Nicolas -- http://www.rachinsky.de/nicolas
Re: email has changed, you won't change everyone, and you don't have to
* Peter Davis p...@pfdstudio.com [2012-11-20 13:37 -0500]: Most workplaces are using email to communicate, and they want maximum efficiency in that. Users want a way to get a message across quickly, as opposed to trying to create a beautiful and literate archive. These efficient mails usually look this way: | Yes | | some header ... | a or b? | | c or d? ... Nicolas -- http://www.rachinsky.de/nicolas
Re: Automatically erase N flag of all messages
On Wed, Sep 12, 2012 at 01:26:31PM +0200, Didier COURTAUD wrote: I would want to clear automatically the N flags of all the messages of a given mailbox. I use these two macros, binded to ESC-c: # # Catchup (index,pager) # macro index\ec tag-pattern~Nentertag-prefix-condclear-flagNuntag-pattern.*enterend-cond macro pager \ec exit\ec -- Nicolas
Re: mutt on an IMAP-Server (dovecot): folder names and structure
On Thu, Aug 16, 2012 at 01:07:36PM +0200, martin f krafft wrote: Do you have alternative approaches? I do not want to use mutt's IMAP for localhost access, nor do I want to set up offlineimap on localhost. My home server runs a dovecot server, and I always use Mutt's IMAP to access folders locally; it works pretty well. Is there a special reason to not use this combination? -- Nicolas
Re: mutt on an IMAP-Server (dovecot): folder names and structure
On Thu, Aug 16, 2012 at 06:11:26PM +0200, martin f krafft wrote: also sprach Nicolas KOWALSKI nicolas.kowal...@gmail.com [2012.08.16.1757 +0200]: Is there a special reason to not use this combination? I find it slow and cumbersome to work with. For the slowness I activated the header cache feature (one file per folder): set header_cache=~/.hcache With this setup, on this server (Athlon XP 1500, 512M RAM), opening a 15k mails folder takes from 3 to 5 seconds. -- Nicolas
Re: mutt on an IMAP-Server (dovecot): folder names and structure
On Thu, Aug 16, 2012 at 06:29:42PM +0200, martin f krafft wrote: What do you do about the password? I don't want to store that in .muttrc! I enter it manually. Thanks to screen, my mutt session never ends (until server reboot), so this is not a problem. -- Nicolas
Re: mutt and some GMail features
On Sun, Jun 05, 2011 at 02:13:21PM -0400, Chris Brennan wrote: OK, so hitting 's' and then '=target folder' or is it :s='target folder'? The first. After hitting 's', mutt will ask you the destination folder name. My next question is this, if the :s= cmd is used, do I put everything in single or double quotes after the equal sign? Treat it as a variable containing a string? No need to quote the destination folder name, mutt will take care of it. This link explains the basics to IMAP in gernal, for which I already know, what it didn't explain was how to use GMail's IMAP features from within mutt, which seems to be a dead-zone of information, Maybe you should just experiment? I did, learned from that. If unsure, you can just create another Gmail account for testing, so that you won't do mistakes against important mail. Be sure to apply the same IMAP options to both accounts, then test, test, test, and you'll be happy with the power of mutt. :) -- Nicolas
Re: mutt and some GMail features
On Sat, Jun 04, 2011 at 10:31:54AM -0400, Chris Brennan wrote: * Nicolas KOWALSKI nicolas.kowal...@gmail.com [2011-06-04 10:24:01 +0200]: On Fri, Jun 03, 2011 at 04:00:32PM -0400, Chris Brennan wrote: Gmail labels are available as folders in IMAP. So, to label a message, just save it to the corresponding folder. This also works for tagging messages as Spam. OK, so how are you saving the mail to folders? That part I haven't figured out yet. For example, having this in my ~/.muttrc: set folder=imaps://nicolas.kowal...@imap.gmail.com/ Let's say I have a news label defined in Gmail. It also appears as an IMAP folder news, at the root of the IMAP hierarchy. When viewing a message in INBOX, if I want to label it as news, then archive it, I just hit s, followed by =news. Mutt first copies the message in the news folder (labels it in Gmail), then removes the message from INBOX (archives it in Gmail). Gmail/IMAP things are explained in details here: http://mail.google.com/support/bin/answer.py?answer=75725 -- Nicolas
Re: mutt and some GMail features
On Fri, Jun 03, 2011 at 04:00:32PM -0400, Chris Brennan wrote: * properly label (I think mutt calls it tagging) my e-mail based on the labels I have already created in the Web Interface. (While I suspect the answer to this is no, I also suspect the answer to be yes with procmail, this would require I actually learn regex (which I haven't had time to get around to yet).) Gmail labels are available as folders in IMAP. So, to label a message, just save it to the corresponding folder. This also works for tagging messages as Spam. -- Nicolas
Re: New tool for sending HTML mail with Mutt
On Thu, Dec 09, 2010 at 07:25:11PM +0200, Amit Ramon wrote:
Nicolas Williams nicolas.willi...@oracle.com [2010-12-08 13:25 -0600]:
On Wed, Dec 08, 2010 at 09:17:02PM +0200, Amit Ramon wrote:
Chip Camden sterl...@camdensoftware.com [2010-12-08 11:01 -0800]:
On a related topic, is there any way to get mutt to display RTL for
certain characters? The Hebrew characters in your signature, for
instance, are displayed LTR in my mutt, so they read backwards.
Not directly. For that you have to use a bidi-aware terminal. I'm
running Mutt in Mlterm terminal emulator, which can handle LTR and RTL
quiet well (but not perfectly).
I agree, this is a job for the rendered, which is also why you shouldn't
need your plain2html program -- the web browsers displaying your email
in webmail apps should handle bi-di correctly as long as they understand
UTF-8. Might the webmail backend be doing something wrong?
I don't agree... web browsers are not supposed to be able to know how
to render bidi text. For this reason there are dir tags in
HTML. Webmail backends are also not doing it. This is not the same as
understand UTF-8.
I'm not too familiar with bi-di, and I can see that a dir tag does exist
for HTML. We seem to agree that terminals (which have no HTML-like
tags) are supposed to figure out how to render bi-di correctly. Looking
around a bit I see that there are three standard ways to indicate
direction changes:
- Use Unicode control characters, most of which are discouraged, except
for the right-to-left and left-to-right marks (which are for
specifying direction for weak-directional characters relative to
surrounding strong-directional characters);
- Use HTML dir attribute or bdo element;
- Use CSS rules ('direction' and 'bidi-override' props).
The last two are for HTML docs only. The first one is the only one that
works in all contexts, while markup solutions based on anything other
than Unicode require tags/attributes to be defined.
But there is a Unicode bi-di algorithm... From what I can tell,
renderers that implement it should not require marks (except for
weak-directional characters, as mentioned above).
How would I know if the Hebrew text in your signature is displaying
correctly? [...]
The first Hebrew letter in my first name is Ayn, which looks
schematically like this:
[...]
In a correct appearance you should see it at the rightmost place on
the line that has my first name, Amit, in my signature... if it
follows the word Amit immediately after the blank space, the terminal
does not support bidi.
Indeed, my terminal is not displaying those in right-to-left. I see
that some applications do display properly (for example, the Bluefish
editor does, but vim/gvim does not).
Nico
--
Re: New tool for sending HTML mail with Mutt
On Wed, Dec 08, 2010 at 09:17:02PM +0200, Amit Ramon wrote: Chip Camden sterl...@camdensoftware.com [2010-12-08 11:01 -0800]: On a related topic, is there any way to get mutt to display RTL for certain characters? The Hebrew characters in your signature, for instance, are displayed LTR in my mutt, so they read backwards. Not directly. For that you have to use a bidi-aware terminal. I'm running Mutt in Mlterm terminal emulator, which can handle LTR and RTL quiet well (but not perfectly). I agree, this is a job for the rendered, which is also why you shouldn't need your plain2html program -- the web browsers displaying your email in webmail apps should handle bi-di correctly as long as they understand UTF-8. Might the webmail backend be doing something wrong? How would I know if the Hebrew text in your signature is displaying correctly? The glyphs appear to be correct. Would inserting spaces between the characters change the order in which they appear? If so, my terminal (Terminator) is not handlint bi-di correctly :( Nico --
Re: muttjump (was: ad: muttlearn - tool for managing multiple identities)
On Mon, Nov 29, 2010 at 11:11:11AM +0100, Christian Ebert wrote: 5) ps has no --no-heading option here on Mac OS X (BSD-like). Does it have a -o option where terminating the format list with an '=' causes no heading to be printed? It should, at least according to this: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/ps.1.html
Re: unicode
On Sun, Nov 28, 2010 at 07:50:08PM -0600, Derek Martin wrote: On Sun, Nov 28, 2010 at 02:52:22PM -0800, Chip Camden wrote: inside rxvt-unicode (urxvt) v9.07 and I can't seem to get unicode characters to display properly. I have: set charset=utf-8 This comes up often enough that it should probably be a FAQ... First off, don't set charset. You shouldn't need to, and -- unless you're doing something very funky and you really, really know what you're doing -- having to do this means your environment is not set up properly. Most likely, setting this manually will only work against you. [...] +1 In general, using an off-the-shelf desktop on Linux/*BSD/Solaris should cause everything to be in order, particularly if you use a UTF-8 locale to begin with. When everything's in order (you have the necessary locales and fonts installed, and you're using blessed desktops / start scripts) then you will have the locale environment variables properly setup and your tools will find their fonts/renderers and codeset conversion modules and so on. Mutt too will be able to do codeset conversions and thus display foreign characters to the best of your locale's ability. If you must use a non-UTF-8 locale yet want to be able to use UTF-8 for your mutt instances (e.g., to be able to display more characters than your locale allows, or to be able send mail using UTF-8 as your locale), then you'll want to run a terminal emulator that allows you to pick an encoding: set the encoding of the terminal where you run mutt to UTF-8, make sure to change the locale env vars accordingly in that session, and start mutt. For example, gnome-terminal allows you to set the encoding on a per-tab basis. But it's better to just use a UTF-8 locale for all your sessions and work. Nico --
Re: setting mutt to charset UTF-8 ?
On Wed, Oct 06, 2010 at 09:52:22AM -0500, Kyle Wheeler wrote: On Wednesday, October 6 at 04:31 PM, quoth Matthias Apitz: It is converted *before* it is stored into the temp file for 'vim'; I've checked this with truss(1) what mutt hands over to vim (see the marked bytes): [...] g...@current:~ env | egrep 'LANG|LC_' LANG=es_ES.UTF-8 Presumably, that's a valid LANG on your system. Just for giggles, make sure. Run It is, since Matthias must be using Solaris (given the reference to truss(1)), and on Solaris es_ES.UTF-8 is very much a valid locale name. Of course, that locale might not be _installed_, so the locale -a check is still a good idea. Nico --
Re: setting mutt to charset UTF-8 ? [SEC=UNCLASSIFIED]
On Wed, Oct 06, 2010 at 11:07:28PM +0800, Wilkinson, Alex wrote: 0n Wed, Oct 06, 2010 at 10:00:27AM -0500, Nicolas Williams wrote: It is, since Matthias must be using Solaris (given the reference to truss(1)), #uname -s which truss FreeBSD /usr/bin/truss :P Ah... OK, thanks for that. I should install FreeBSD some time to catch (it's been a decade since I last used it, at least). Nico --
Re: Usage poll for mutt on Solaris
On Mon, Sep 27, 2010 at 03:56:59PM +0200, Dagobert Michelsen wrote: Now here is the question: Would it be more likely that all zones share the same mutt configuration or would a typical administrator adjust each of them individually? It has never occurred to me to edit Muttrc -- so much so that I wasn't even conscious of it. It's too bad that Muttrc/Muttrc.dist aren't empty. If Muttrc/Muttrc.dist were empty (ignoring comments), then you could just not ship it and thus avoid the issue altogether. So maybe that's the right question: why is Muttrc not empty by default? Nico --
Re: Inconsisten locale language in mutt 1.5.19
On Fri, Sep 24, 2010 at 09:30:27AM -0700, Michael Elkins wrote: On Fri, Sep 24, 2010 at 10:06:00AM +0200, Matthias Apitz wrote: #: commands.c:513 #, fuzzy msgid Sort (d)ate/(f)rm/(r)ecv/(s)ubj/t(o)/(t)hread/(u)nsort/si(z)e/s(c)ore/s(p) am?: msgstr Órden fech(a)/d(e)/(r)ecep/a(s)unto/(p)ara/(h)ilo/(n)ada/ta(m)año/punta(j)e: The problem seems to be that gettext() ignores the translation when the 'fuzzy' keyword appears. That attribution gets added when the gettext tools detect that the input string has been altered, and thus is no longer sure that the translated string is correct. Someone who is a Spanish speaker will have to update the translation file in order to resolve this issue. The above translation is not incorrect, except, maybe, for the puntaje translation of spam -- puntaje means grade or mark. But also recep for recv and nada for unsort all rub me the wrong way. A better translation of spam is no deseado. The English string also sports incorrect grammar: it should be Sort by ... There's lots of possible translations. Órden is a bit weird here -- Ordernar por (same grammatical fix as in the English version) is better, plus Arreglo or Compaginación, Recopilación, all sound better than Órden to me, but they're also much longer... My version, then: Ordenar por fech(a)/d(e)/(r)ecivido/a(s)unto/(p)ara/(h)ilo/(d)esordenado/ta(m)año/(n)o-deseado: Note that such long messages may need to be wrapped. But mutt should always assume that all such messages may need to be wrapped (the user could be on a particularly small tty). Nico --
Re: Inconsisten locale language in mutt 1.5.19
On Fri, Sep 24, 2010 at 12:38:30PM -0700, David Ellement wrote: On 2010-09-24, Nicolas Williams wrote On Fri, Sep 24, 2010 at 09:30:27AM -0700, Michael Elkins wrote: On Fri, Sep 24, 2010 at 10:06:00AM +0200, Matthias Apitz wrote: #: commands.c:513 #, fuzzy msgid Sort (d)ate/(f)rm/(r)ecv/(s)ubj/t(o)/(t)hread/(u)nsort/si(z)e/s(c)ore/s(p) am?: msgstr Órden fech(a)/d(e)/(r)ecep/a(s)unto/(p)ara/(h)ilo/(n)ada/ta(m)año/punta(j)e: The problem seems to be that gettext() ignores the translation when the 'fuzzy' keyword appears. That attribution gets added when the gettext tools detect that the input string has been altered, and thus is no longer sure that the translated string is correct. The above translation is not incorrect, except, maybe, for ... Does it matter that the English string offers 10 options, while the Spanish string only offers 9 options? Oops, I missed the s(c)ore option. Ah, so what's missing in the Spanish version is the translation for s(p)am. I looked at what spam translates to in online dictionaries, and sadly there's no good word in Spanish -- basura is often used, but that's also the translation for trash, which is ambiguous in this context. I'd settled for no deseado (unwelcome), with a dash if need be. Nico --
Re: Stuck on 97% changing mailboxes
On Thu, Sep 23, 2010 at 02:13:05PM -0700, Michael Elkins wrote: Yes, this is the problem. Mutt expects to see a FETCH response for each message the server says EXISTS. The IMAP standard requires that no holes exist in the message sequence numbers, and mutt is not prepared to handle them. Mutt could be a lot more asynchronous though. Mutt could display a page-ful of messages, filling in slots (re-drawing as necessary) as the FETCH responses come in. Right now mutt wants to enumerate a mailbox when opening it. It has to for mbox/mh/maildir folders, given their nature. But IMAP is designed to allow for listing page-fuls of messages at a time instead of enumerating folders -- the fact that mutt doesn't do this has me sad. IMAP is also designed to allow multiple concurrent requests, that is, it's designed to allow for asynchronous operation. I've looked at mutt source code, and ISTM that it'd require massive surgery to add support for using IMAP this way. Nico --
Re: Stuck on 97% changing mailboxes
On Thu, Sep 23, 2010 at 02:32:54PM -0700, Brendan Cully wrote:
On Thursday, 23 September 2010 at 14:13, Michael Elkins wrote:
On Thu, Sep 23, 2010 at 10:19:28PM +0200, Michael Williams wrote:
On 23 Sep 2010, at 19:17, Christian Brabandt wrote:
4 * 3700 FETCH (UID 17146 FLAGS (\Seen) INTERNALDATE 23-Sep-2010
09:14:57 +0100 RFC822.SIZE 2612 BODY[HEADER.FIELDS (DATE FROM SUBJECT
TO CC MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO
REPLY-TO LINES LIST-POST X-LABEL)] {404}
4 * 3702 FETCH (UID 17148 FLAGS (\Seen) INTERNALDATE 23-Sep-2010
14:35:54 +0100 RFC822.SIZE 20548 BODY[HEADER.FIELDS (DATE FROM SUBJECT
TO CC MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO
REPLY-TO LINES LIST-POST X-LABEL)] {408}
Here is one missing.
Is this the problem? Is there a workaround or is the conclusion that mutt
is not compatible with Exchange 2010 IMAP's support (or Exchange 2010 is
not compatible with mutt)?
Yes, this is the problem. Mutt expects to see a FETCH response for
each message the server says EXISTS. The IMAP standard requires that
no holes exist in the message sequence numbers, and mutt is not
prepared to handle them.
We might be able to work around this by creating an empty message
marked as expunged for the holes, then running the expunge compactor
after the command finishes. But it does seem like there's probably
something wrong with your mailbox on the server side. It might go away
if the exchange server administrator runs some kind of maintenance
tool on the problematic mailbox.
That's a good idea -- we know how many messages there are, so pretend we
know them all and fill in the details as the responses come in. The
only other part of the puzzle: how to handle curses input and IMAP async
I/O? I think doing this with minimal surgery might require a thread to
poll for curses input and another to handle IMAP responses.
Nico
--
Re: Stuck on 97% changing mailboxes
On Thu, Sep 23, 2010 at 02:45:47PM -0700, Michael Elkins wrote: The main issue is that some popular IMAP servers (gmail, exchange), do not support the SORT extensions, so you wouldn't be able to do the pageful-at-a-time and still have all of Mutt's current threading capabilities. Interesting. I'd still like to open the folder and see it in the one order quickly, with the enumeration happening in the background, so that eventually I could sort it any way I like. You are correct that major surgery would be required to change Mutt. A few years back I wrote a patch to lazily load the message headers, but the lack of threading support made it mostly useless. Are you referring to pthreads or mail therading? Nico --
Re: Stuck on 97% changing mailboxes
On Thu, Sep 23, 2010 at 02:58:56PM -0700, Michael Elkins wrote: On Thu, Sep 23, 2010 at 04:52:37PM -0500, Nicolas Williams wrote: Are you referring to pthreads or mail therading? Mail threading. That's OK. I'd be happy to live with that, since eventually the folder does get fully enumerated. And if you have a server that doesn't answer some FETCHes, as in this case, it'd be a perfect workaround.
Re: How to match all theaded emails excluding the first one?
On Mon, Sep 20, 2010 at 03:38:16PM +0200, mjsseppl-m...@yahoo.de wrote: On 10.09.20, mjsseppl-m...@yahoo.de wrote: On 10.09.20, Yue Wu wrote: Do H and look at the headers and you'll see under References: 20100919012315.gc36...@fbsd.t60.cpu 20100919071840.ga26...@murdoc etc. In-Reply-To: is also used. In-Reply-To: is standard, while References: is a Usenet-ism. Good MUAs will thread based on both. Some MUAs break threading (by including neither of those two headers), so sometimes it's necessary to match replies via subject matching. Mutt supports all of this, and uses asterisks to mark mails which break threading. (MUAs could go so far as to match quoting in mail bodies, but that's really hard.) See: http://www.jwz.org/doc/threading.html Nico --
Re: Searching for hook to save new read mail to its particular mailbox
On Fri, Sep 10, 2010 at 09:49:57AM +0200, j...@telefonica.net wrote: Nico, I will search for your macro to see what can I do with regular expressions. For your convenience: macro index , tag-pattern!~D^Jtag-prefix-condsave-message/path/to/some/maildir/^J^Jend-condsync-mailbox Move all undeleted messages to maildir folders Then use ',' to move all undeleted mail to a maildir. Change the tag-pattern to your liking, and, of course, the save-message path. Nico --
Re: Searching for hook to save new read mail to its particular mailbox
On Thu, Sep 09, 2010 at 06:53:07AM -0700, Michael Elkins wrote: On Tue, Sep 07, 2010 at 12:57:51PM +0200, j...@telefonica.net wrote: I'm searching about a hook that will save to its mailbox all mails with To: list_...@server.com after had read them, I think when changing mailboxes. Now, I received all mails to +spoolfile but I would like to move with a hook the ones coming To: list_...@server.com after had read them. I have tried with save-hook, fcc-hook, but I can't find which one will do that move or copy. Mutt does not really have any automatic filtering built in. What most people do in this situation is to use something like procmail to filter incoming mail into separate mailboxes per email list, then put mailboxes +list1 +list2 in their ~/.muttrc to be informed when each mailbox has new mail. Mutt has a wonderful regular expression language that makes it easy to write small, powerful search expressions. Searches are filters, really (see gmail). It seems like a pity that mutt doesn't have a first-class filter. Procmail is not easy to use by comparison to mutt. Sure, sure, if you're using a text-based MUA you can write procmail filters. True. But for some use cases external programs like getmail, fetchmail and procmail all fall short. For example, I've given up on fetchmail because it dropped 30K messages once (from a 100K msg folder). I've given up on getmail because it doesn't preserve message flags, so if I've an IMAP Inbox that I want to leave a few days' worth of messages at a time for accessing from multiple MUAs (say, mobiles), then I can't use getmail to later move those off the IMAP server. (No, the getmail maintainer was not interested in patches to preserve message status/flags.) If I use IMAP, can't or don't leave mail on the server, but can use neither getmail nor fetchmail then how am I to use procmail? So I use mutt as a mail fetcher. It's easy: I've a simple macro that tags all un-deleted messages and the tag-saves them to their destination (I've posted this macro before). It'd be easy to add multiple steps, with each step tagging messages matching a given filter, then tag-saving to specific folders. Well, 'easy' is relative -- easy for me, but then, I don't file e-mail (I depend on searches). Mutt could provide this off the shelf, and then it would be really easy. Seems like a shame to have a great search language that cannot also be used for writing filters. Mutt has everything it needs to replace that getmail/fetchmail/procmail mix -- only the finishing touches are missing. Nico --
Re: Default To: per folder
E. Prom e3p...@gmail.com writes: On Saturday, 04 September 2010, 19:05:40 +0200, Nicolas KOWALSKI n...@petole.demisel.net wrote: Andre Majorel aym-t...@teaser.fr writes: Is there a way to set a default value for To: in mail ? It would be very useful after a folder-hook for mailing lists etc. Yes, using my_hdr. Here is an example of what is in my ~/.muttrc: folder-hook =list.debian 'my_hdr To: debian-u...@lists.debian.org' folder-hook =list.dovecot'my_hdr To: dove...@dovecot.org' folder-hook =list.mutt 'my_hdr To: mutt-users@mutt.org' This seemed great to me, but I notice that when replying a mail after defining a default To: address, this address is not replaced by but added to the person's address I'm replying to. Yes, when replying. However, it works when replying to list (I also defined the subscribe variable). For me, these folder-hooks are only useful when composing a new mail to a mailing-list. -- Nicolas
Re: Default To: per folder
Andre Majorel aym-t...@teaser.fr writes: Is there a way to set a default value for To: in mail ? It would be very useful after a folder-hook for mailing lists etc. Yes, using my_hdr. Here is an example of what is in my ~/.muttrc: folder-hook =list.debian'my_hdr To: debian-u...@lists.debian.org' folder-hook =list.dovecot 'my_hdr To: dove...@dovecot.org' folder-hook =list.mutt 'my_hdr To: mutt-users@mutt.org' -- Nicolas
Re: mutt - color problem
May I suggest that trimming some of the quoted material in these messages? It'd make it easier to read the thread, and maybe help out. Nico --
Re: mutt - color problem
BTW, I use screen in gnome-terminal. I notice the following: - TERM is screen-bce; - VIM works fine, handles colors; - Mutt built with S-Lang does not start unless I set TERM to xterm or xterm-color; Mutt complains that Key sequence is too long, SLcurses_initscr: init failed; - If I set TERM=xterm then VIM thinks the terminal is monochrome; - If I set TERM=xterm then Mutt does produce colors; - If I set TERM=xterm-color then both, VIM and Mutt handle color. Weird, no? This is almost certainly a result of using different APIs (VIM uses curses, Mutt uses S-Lang). I believe my colleague Will F. has shown that Mutt works fine with curses (ncurses). This is all on Solaris. Nico --
Re: mutt - color problem
On Tue, Aug 31, 2010 at 02:37:48PM -0700, Chip Camden wrote: You could probably get mutt to start with TERM=screen-bce is termcap has an appropriate entry for it. I found that even though mutt with slang uses terminfo, it queries termcap on startup. screen(1) does set TERMCAP in the environment... There is a termcap entry for screen, but not for screen-bce. If I add the screen-bce entry I still get the same error, as I do if I set TERM=screen. Aha! I must unset TERMCAP to make Mutt/S-Lang happy. Nico --
Re: Mutt - only sets delete flag but doesn't delete
Personally I like having control over when expunges happen. Use '$' to expunge (with default index key bindings). Nico --
Re: sending an email with a mutt one-line without being prompted
On Tue, Aug 03, 2010 at 10:36:05AM +0200, Christoph Kukulies wrote: -- has special meaning in some unix command lines to provide an escape when names starting with a --sign are concerned. (doesn't getopt use it as an escape anyway? not sure). mkdir -- -foo rmdir -- -foo -- means end of option arguments. How about mutt -a * \; j...@foo.bar ? Lots of conventions could be established, but none that getopt/getopts would know already. For example, using '' results in no ambiguity (you can have files named ';', but not files named ''). Either way, the matter is clearly closed for the time being. Nico --
Re: sending an email with a mutt one-line without being prompted
On Tue, Aug 03, 2010 at 02:00:46PM +, Grant Edwards wrote:
On 2010-08-02, Nicolas Williams nicolas.willi...@oracle.com wrote:
Right. There's no good convention for end of list of arguments to an
option. There's only a good convention for end of variable argument
list ('--'), and since this is the closest thing...
And since there _is_ a convention that '--' ends the option list, it's
A Bad Thing(TM) to use it for something else. I think violating the
almost universal convention about what '--' means is a terrible idea,
but apparently we're now stuck with it.
The convention is that '--' ends the entire option list, not a list of
arguments to a single option. Therefore mutt clearly uses something
other than the existing convention.
Nico
--
Re: sending an email with a mutt one-line without being prompted
On Tue, Aug 03, 2010 at 12:45:12PM -0500, David Champion wrote:
* On 03 Aug 2010, Nicolas Williams wrote:
On Tue, Aug 03, 2010 at 02:00:46PM +, Grant Edwards wrote:
On 2010-08-02, Nicolas Williams nicolas.willi...@oracle.com wrote:
Right. There's no good convention for end of list of arguments to an
option. There's only a good convention for end of variable argument
list ('--'), and since this is the closest thing...
And since there _is_ a convention that '--' ends the option list, it's
A Bad Thing(TM) to use it for something else. I think violating the
almost universal convention about what '--' means is a terrible idea,
but apparently we're now stuck with it.
The convention is that '--' ends the entire option list, not a list of
arguments to a single option. Therefore mutt clearly uses something
other than the existing convention.
Strictly speaking, no: since mutt requires the -a option to be last,
a '--' terminating the list of arguments to -a implicitly terminates
the option list as well. I think this may have been part of the design
consideration.
Ah, well, if -a has to be last then you're right. (Still feels icky,
but that's just aesthetics.)
Re: sending an email with a mutt one-line without being prompted
On Sun, Aug 01, 2010 at 10:52:01PM -0500, David Champion wrote: Syntax has been changed: -a indicates a *list* of attachment files ending with --. I don't recall which version was first to boast this new syntax, but it's the problem you're seeing right now even if it's not related to the problem you saw earlier. Try: mutt -s test -a Bild.jpg -- m...@some.org body.txt I recommend against this use of '--'. It makes it harder to write wrapper scripts that parse the same arguments using getopt/ getopts, for example. Sadly, I don't have a counter-proposal, nor am I suggesting this get ripped out now. Nico --
Re: charsets
On Thu, Jul 29, 2010 at 11:32:47AM -0600, Paul E Condon wrote:
In this, iconv-hook is described as a method of handling a 'character
set name' that is not known to Mutt. Is there a place where I can find
a list of the character set names that are known to the copy of Mutt
on my machine? Where? How? Or (gently, please) why is this a silly
question?
FWIW, the charset.c source file says that mutt's charset names come from
http://www.isi.edu/in-notes/iana/assignments/character-sets
and that only charsets for which a preferred MIME name is given are
listed.
The recommended additions to my .muttrc appear to use a regualar
expression for the value of 'alias'. What part of an email system
would insert things like unknown-8bit into the headers of an email?
See RFC1428 (Transition of Internet Mail from Just-Send-8 to
8bit-SMTP/MIME). The answer is: a mail gateway handling an email sent
by a pre-MIME client. In English: someone using a very old MUA is
sending you e-mail, and you should ask them to upgrade to modern
software. Your software can at best only guess what that someone is
sending you.
I am certain that my system is improperly configured. I want to fix
it. I have tried many things, well beyond what I would ask you to read
about. But nothing, as done by me, has fixed the problem(s)
If you're seeing unknown-8bit then the configuration problem isn't
yours. When someone sends you an unknown-8bit message, it could be
coded in any of a large number of codesets, and it might even be
possible to render that message without question marks in more than one
codeset, but it may make sense in only one codeset (or none, if the
message is garbage). How can your MUA (mail client) determine which
codeset, if any, to use to display unknown-8bit?
The best an MUA could do is let you tell it what codeset you think a
peer is using (possibly the MUA could try them all, and you'd pick
whichever makes sense to you), and then the MUA could keep a little
database that it uses to map {sender, unknown-8bit} to a codeset later
on. It's easier for you to tell your peers to use newer software.
Nico
--
Re: charsets
On Wed, Jul 28, 2010 at 12:41:37AM -0600, Paul E Condon wrote: Thanks for tip about iconv. I do have both WINDOWS-1252 and CP1252 on my computer. So the second line should not be needed. While composing this email I suddenly realized that the charset names are probably case sensitive and my WINDOWS-1252 is not going to work with windows-1252, as used in the advice given on this list. I changed the advice magic strings to match what Squeeze is currently programmed to expect, and IT WORKS. Problem solved until DDs move to what appears to be the Linux community standard of mostly lower case in charset names. Yay! On RHEL5 iconv codeset names are all upper-case, and evidently case-sensitive (the iconv_open(3) manpage doesn't say anything about case-sensitivity). On Solaris they are mixed-case, but aliases are explicitly case-insensitive (per the output of iconv -l). So mutt can't blindly up-case charset names -- it'd have to know to do it on Linux but not elsewhere. Nico --
Re: sending to a list of undisclosed recipients
On Tue, Jul 27, 2010 at 09:57:39PM +, Grant Edwards wrote: Instead of going through a for i in `cat users`do mutt ... $i done loop I could make an alias of these users, but how do I tell to hide the 100 users and only show up the one addressee plus a note that the email went to a group of undisclosed users? I assume you know it's not uncommon for people to route message like that directly into the spam folder? ssh...
Re: prevent gmail from rewriting from envelope
On Thu, Jul 08, 2010 at 11:10:35AM +0200, Ben Moon wrote: Dear Nicolas, If I send the mail with mutt the 'from: otheru...@yahoo.de' is always changed to 'from: usern...@gmail.com'. Is there a way to prevent this rewriting by google when I use mutt? Yes, this is my current work flow. In mutt I set my_hdr From: m...@email and in gmail I remove the envelope rewriting (somewhere in the options). thank you for your answer. Could you please be a bit more precise about the 'somewhere in the options'? I haven't found anything. It works with thunderbird, though. @ Nathaniel Yes, since set use_envelope_from=no is default, I have tried both Notice I don't set use_envelope_from. -- Nicolas Sebrecht
Re: prevent gmail from rewriting from envelope
On Thu, Jul 08, 2010 at 11:10:35AM +0200, Ben Moon wrote: If I send the mail with mutt the 'from: otheru...@yahoo.de' is always changed to 'from: usern...@gmail.com'. Is there a way to prevent this rewriting by google when I use mutt? Yes, this is my current work flow. In mutt I set my_hdr From: m...@email and in gmail I remove the envelope rewriting (somewhere in the options). thank you for your answer. Could you please be a bit more precise about the 'somewhere in the options'? I haven't found anything. It works with thunderbird, though. - settings - accounts and import - send mail as - edit info - Specify a different reply-to address (optional): nothing -- Nicolas Sebrecht
Re: prevent gmail from rewriting from envelope
On Wed, Jul 07, 2010 at 03:41:05PM +0200, Ben Moon wrote: If I send the mail with mutt the 'from: otheru...@yahoo.de' is always changed to 'from: usern...@gmail.com'. Is there a way to prevent this rewriting by google when I use mutt? Yes, this is my current work flow. In mutt I set my_hdr From: m...@email and in gmail I remove the envelope rewriting (somewhere in the options). -- Nicolas Sebrecht
Can't set alternates
Hi, I've added this line in my muttrc file set alternates=...@email.address but got alternates : unknown variable (translated message) with mutt v1.5.18. Any idea on what's going on? -- Nicolas Sebrecht
Re: Can't set alternates
On Fri, Jul 02, 2010 at 11:00:32AM +0200, Christian Ebert wrote: Since some time alternates has become a command: alternates ^...@email\\.address$ ^anot...@email\\.address$ See man(5) muttrc. You can use less strict patterns of course. Thank you very much, it did solve the problem. I refered to this page : http://www.mutt.org/doc/manual/manual-6.html May I ask why alternates is still in the 6.3 Configuration variables chapter? -- Nicolas Sebrecht
Re: imap way for slow connection (imap without attachment)
Michelle Konzack linux4miche...@tamay-dogan.net writes: There is NO way for the MUA or IMAP server, to select which part of the body should be downloaded. Yes there is. This is in the IMAP protocol, see http://www.faqs.org/rfcs/rfc2060.html. 2.4.Message Texts In addition to being able to fetch the full [RFC-822] text of a message, IMAP4rev1 permits the fetching of portions of the full message text. Specifically, it is possible to fetch the [RFC-822] message header, [RFC-822] message body, a [MIME-IMB] body part, or a [MIME-IMB] header. On the MUA side, mutt does not handle it, but others (at least alpine) do. -- Nicolas
Re: Wrapping on internal pager
On Sun, Apr 11, 2010 at 06:17:24PM +, Camaleón wrote: - Image sample of failing e-mail (it will be auto-deleted in 7 days): http://picpaste.com/20100411_mutt_pager_wrapping.png - Raw code sample of failing e-mail (it will be auto-deleted in 1 day): http://pastebin.com/4t4kPSrh (For others: Camaleón has a very long line of 'o's unbroken by space. The PNG shows this flowed to fill all available columns, plus the leading continuation marker on continuations.) This is just what mutt does. I do find markers (the leading '+' on the continuation lines) to be really obnoxious, particularly when they pollute URLs, so I turn them off. IMO the flowing algorithm could use some work. Breaks should be placed at breaking white-space, and if none is available then wrap at the _last_ column, with no marker (markers should be used, if at all, only when breaking at breaking white-space). The reason for wrapping at the last column is simple: so URLs aren't broken up (so one can mouse double click + copy to copy a URL into the clipboard). Of course, breaking only at breaking white-space means that mutt has to pick breaking points carefully so that text flows reasonably well, with the least chance of long non-breaking sequences going past the wrapmargin -- the algorithm suddenly got complex. (Piping through fmt(1) is probably not a good idea.) Nico --
Re: handling List-Id header
On Mon, Apr 12, 2010 at 10:47:21AM +0200, ilf wrote: On 04-11 20:32, Michael Elkins wrote: On Sat, Apr 10, 2010 at 01:38:19AM +0200, ilf wrote: I would like a workaround to use Regex in 'lists' and 'subscribe', but that feels dirty. Why doesn't Mutt allow 'lists'/'subscribe' to lists based on the List-Id: header? The List-ID header is not necessarily a valid email address. All that the RFC requires is that it be a unique value for each list. As such, it's not terribly useful for figuring out where to reply. I never proposed using List-Id to figure out where to reply, List-Post is the right field for that and it's being done nicely. But I think Mutt could display messages as from a list (in index with %L and %Z) automatically, if a List-Id header is present. Then I would not need lists/subscribe at all. And also match them with ~l when searching. Maybe. (I'm not sure how that would work for IMAP.) Another possibility would be to have a tool that scans a folder for list addresses and constructs list/subscribed lists accordingly. Nico --
Re: FAQ: How to spawn terminal/screen to reply to messages separately?
On Tue, Mar 30, 2010 at 08:58:20PM -0400, Patrick Shanahan wrote: You might consider looking at tmux as a replacement for screen. I find it much more robust and the learning curve is not much. It makes some of screen's *features* more functional such as split screen w/o using one of the screen numbers that allow direct access (ctrl-a2). Tmux uses ctrl-b rather than ctrl-a, and allows direct access to 10 screens, buffers, This is all completely OT, but... using ctrl-b is an absolute non-starter as it's an emacs-mode editing character. I've been using screen for almost two decades now. The lack of quick access to screens past 9 is somewhat annoying, but I can live with that. Same with buffers. So I doubt I'll switch, but I may give it a try sometime just to see.
Re: FAQ: How to spawn terminal/screen to reply to messages separately?
On Mon, Mar 29, 2010 at 08:05:26PM -0700, Gary Johnson wrote: I think you can do all of your first idea with a macro. The basic idea is: It won't do: [...] 5. Execute a script as you did before to start mutt on that postponed message. First, this is a bad UI since I'll have to hit 'r' (or 'g', or ...) to reply to the message in the spawned instance of mutt. This might be fixable using the -e CLI option. Second, and this is worse, is: The tricky part is, and has always been in these discussions, making sure the 'replied' flag on the original message is set properly. Exactly. That seems to require the primary mutt to listen on some sort of IPC mechanism for a command to set the 'replied' flag on the message of a specified Message-ID as you have outlined in your second idea above. Mutt currently checks things like the presence of new mail upon user input or the expiry of a timer, so it seems that it could check the IPC mechanism the same way. If mutt had CLI options naming a specific message in a specific folder to immediately reply to then the replied flag could get set correctly and then the original instance of mutt could eventually sync up. But that has the problem that there's no connection sharing and no password caching. The latter is yet more bad UI. This problem screams for a specific solution rather than trying to bend existing facilities of mutt. The archives are littered with incomplete and unsatisfying solutions. Yours sounds better than all the previous ones, and still, it's not satisfying. I think the solution to the second problem may influence the solution to the first, so it would be my suggestion to work on the second problem first. I'm thinking along the same lines. But I want this to be simple. I'm thinking of doing something with Unix domain sockets (to be portable, else I'd use Solaris doors :) like so: - one main socket - spawned instances connect to the parent's main socket and request any of: - another socket on which to talk SMTP/SUBMIT or IMAP to some server In both cases the parent would hand back to the child a pipe which the parent would proxy to the real server. The parent would do all TLS and SASL work. In the case of IMAP the parent could share a single connection with its children, making sure to remap the IMAP request XIDs to avoid conflicts (or perhaps the parent could hand each child an XID namespace for itself). (IIRC IMAP requests and replies have an XID picked by the client.) - tell the parent to sync its view of some message or folder - other commands? The child process could be a wrapper around an instance of mutt -H. If that mutt exits with a status of 0, the wrapper writes the set replied for this Message-ID command to stdout and exits. Otherwise, it just exits. Rather than a wrapper, of course, it would be nice to just invoke mutt with a flag that tells it to do all that. Yes. But I want a more complete solution. I don't know where in the code to suggest that you start. I usually run cscope on the source code directory tree, then run vim -c 'grep some_likely_string *.[hc]' where some_likely_string is something I expect to find associated with the code I'm interested in, and start browsing the code from there. Unfortunately I'm very busy. I may not get to this any time soon. But I may start by reading the code. Cscope is one of my favorite tools. Thanks, Nico --
Re: FAQ: How to spawn terminal/screen to reply to messages separately?
On Mon, Mar 29, 2010 at 10:11:40PM -0700, George Davidovich wrote: Maybe I'm missing something here, but wouldn't temporarily resetting mutt's `sendmail' variable to a custom mailer (a variation on the OP's script, perhaps) take care of the replied flag issue? No. The sendmail thing comes too late. We want asynchrony between the point the user chooses to reply to some message and the point the reply is sent. That is, the user hits 'r' (or ...) and a new terminal pops up running a different instance of mutt to take care of invoking $editor and all that while the main instance returns to the index (where the user could then spawn another reply before even finishing the first). The way I normally work around this is to postpone drafts, go back to the index, and go from there. I'm sort-of time-slice multi-tasking the reply process. That's something computers and software are good for. (Note that I don't want a GUI MUA -- if I did I would not be here. I particularly like running things in screen(1). I solve a similar problem with cscope by using a wrapper around my $EDITOR that spawns a new screen to run my $EDITOR.) (Note also that others have referred to this problem as making mutt multi-threaded, but that's not useful unless one instance of mutt can drive multiple ptys at once. There's no need to make mutt MT for that as async I/O will do. Making mutt support multiple ptys would be nice, but I'm sure it'd involve significant changes.) Nico --
Re: FAQ: How to spawn terminal/screen to reply to messages separately?
On Tue, Mar 30, 2010 at 07:04:22PM +1100, Cameron Simpson wrote: On 29Mar2010 17:19, Nicolas Williams nicolas.willi...@sun.com wrote: | I saw in the archives that this is a bit of an FAQ, and it seems that to | this day there's not much of an answer, sadly. Here's what I do: set edit_headers=yes set editor=muttedit set autoedit=yes Muttedit is here: http://www.cskk.ezoshosting.com/cs/css/bin/muttedit Now, muttedit mostly just runs the reply process in a screen session; it does some work to give the session a good name. Very nice sed scripting. If I complete the reply immediately (as now), it's all seamless. But if I want to defer the reply for later, I simply detach from screen and reattach later. Here's this message in progress: But what happens on detach in the parent mutt (edit abort?)? (I've tried it, and the screen does not appear to start. Does that workflow address your needs? Almost, but see the other e-mails in this thread. Nico --
Re: FAQ: How to spawn terminal/screen to reply to messages separately?
On Tue, Mar 30, 2010 at 10:43:08AM -0500, Nicolas Williams wrote: On Tue, Mar 30, 2010 at 07:04:22PM +1100, Cameron Simpson wrote: If I complete the reply immediately (as now), it's all seamless. But if I want to defer the reply for later, I simply detach from screen and reattach later. Here's this message in progress: But what happens on detach in the parent mutt (edit abort?)? (I've tried it, and the screen does not appear to start. Oh, I got it to work. I needed to insert env TERM=xterm-color into the screen command-line (I'd completely forgotten). screen -ls output gets mangled, but that's screen's fault: There are screens on: [...] 3820.mutt-30mar2010-11:06 Re_Foobars_Request_1 (Detached) Does that workflow address your needs? Almost, but see the other e-mails in this thread. This is the closest so far though. Thanks, Nico --
Re: FAQ: How to spawn terminal/screen to reply to messages separately?
On Wed, Mar 31, 2010 at 09:44:09AM +1100, Cameron Simpson wrote: On 30Mar2010 11:11, Nicolas Williams nicolas.willi...@sun.com wrote: | On Tue, Mar 30, 2010 at 10:43:08AM -0500, Nicolas Williams wrote: | On Tue, Mar 30, 2010 at 07:04:22PM +1100, Cameron Simpson wrote: | If I complete the reply immediately (as now), it's all seamless. | | But if I want to defer the reply for later, I simply detach from screen | and reattach later. Here's this message in progress: | | But what happens on detach in the parent mutt (edit abort?)? (I've | tried it, and the screen does not appear to start. | | Oh, I got it to work. I needed to insert env TERM=xterm-color into | the screen command-line (I'd completely forgotten). That's surprising; it suggests your $TERM isn't set up right outside mutt. It's a terminfo / libslang issue. | screen -ls output | gets mangled, but that's screen's fault: | There are screens on: | [...] | 3820.mutt-30mar2010-11:06 Re_Foobars_Request_1 (Detached) Cool. So, working for you now? Turns out I can screen -r pid, so, yes. Glad to here it. Any specific problems remaining to address? The replied flag issue. The connection sharing and password caching issues. I can live. (Actually, _I_ don't need this, as I'm happy to postpone messages when I need to switch gears. But I know of at least one user who desperately needs a new MUA but will not adopt mutt because of this missing feature.) Nico --
Re: FAQ: How to spawn terminal/screen to reply to messages separately?
On Wed, Mar 31, 2010 at 11:44:35AM +1100, Cameron Simpson wrote: On 30Mar2010 17:51, Nicolas Williams nicolas.willi...@sun.com wrote: | That's surprising; it suggests your $TERM isn't set up right outside | mutt. | | It's a terminfo / libslang issue. Lucky the screen internal terminal and xterm both base off the ANSI stuff, eh? :) | | screen -ls output | | gets mangled, but that's screen's fault: | | There are screens on: | | [...] | | 3820.mutt-30mar2010-11:06 Re_Foobars_Request_1 (Detached) | | Cool. So, working for you now? | | Turns out I can screen -r pid, so, yes. Ah. I mostly use screen through a wrapper of my own called scr that numbers the listing, so I'd be going scr 5 or whatever. I do the same (I call my wrapper rscreen), but it gets fooled by the run-on fields above. In any case, I will not use the -m option, since I don't want a whole new screen but a new window. | Glad to here it. Any specific problems remaining to address? | | The replied flag issue. You could be optimistic and mark it at the point you commence the reply. Hmmm, maybe. Or I could have a script go through my sent folder and searching for the messages they reply to just to set the replied flag. | The connection sharing and password caching | issues. I can live. Connection sharing? See other posts on this thread. | (Actually, _I_ don't need this, as I'm happy to postpone messages when I | need to switch gears. But I know of at least one user who desperately | needs a new MUA but will not adopt mutt because of this missing | feature.) Ah. Well I know I really wanted it too, hence the script. I never did come to grips with the postponed folder approach. Thanks for your script and usage info, Nico --
FAQ: How to spawn terminal/screen to reply to messages separately?
I saw in the archives that this is a bit of an FAQ, and it seems that to this day there's not much of an answer, sadly. The best I could do was to create an index macro that pipes the current message to a script that then: a) pipes stdin to formail, b) saves the result in a tmp file, c) starts a new instance of mutt -f that_file. Or perhaps using -H. But that's clearly not quite what I want, nor what the various users who have asked for this want. Ideas: - Add a function like pipe-message but which instead of piping the message puts the message in a temp file and then allows for expansion of several parameters in the command line, including: %f (the address of the sender of the message) %r (the To: addresses of the message) %c (the Cc: addresses of the message) %a (the To: and Cc: addresses of the message) %l (the To: and Cc: addresses of the message that are lists) %R (the Reply-To: address of the message) %s (the Subject: of the message, with Re: prefixed if not %already) %F (the name of the file containing the message) - Same as above but also provide a Unix domain socket/door/whatever that mutt can listen on for commands from the external command. The purpose of this is to support connection sharing and avoid having to re-type IMAP/SMTP passwords. The main sub-command would be to send the message found in a given file, and also to mark a message in a folder as replied. The name of the rendezvous would be set in an environment variable and mutt would support using it. All send/save/*-hooks would be applied in the primary mutt. (This is not really needed when using SASL/GSSAPI, of course. It's primrarily useful when there are passwords to type.) Where would I start if I was to try to implement the first of the above? Nico --
Set a default To value based on current folder name?
Hello, When composing a new mail, is it possible to specify a default To address based on the current folder name ? For example, when I am in the folder list.mutt, I would like the To: field to be prefilled with the mutt-users@mutt.org value when composing a new mail. Thanks, -- Nicolas
Re: Set a default To value based on current folder name?
On Mon, Feb 22, 2010 at 03:45:32PM +0100, Jostein Berntsen wrote: On 22.02.10,14:07, Nicolas KOWALSKI wrote: On Mon, Feb 22, 2010 at 01:10:57PM +0100, Zeerak Mustafa Waseem wrote: On Mon, Feb 22, 2010 at 12:51:55PM +0100, Nicolas KOWALSKI wrote: When composing a new mail, is it possible to specify a default To address based on the current folder name ? For example, when I am in the folder list.mutt, I would like the To: field to be prefilled with the mutt-users@mutt.org value when composing a new mail. I don't know if that can be done, but couldn't a work around be that you specified the list in your alias file? I have already. I just would like to automate the process for all my mailing-lists folders, if possible. Have you tried with folder-hook and my_hdr? Thanks for the tip! With the following it works perfectly: folder-hook . 'unmy_hdr to' folder-hook =list.debian'my_hdr To: debian-u...@lists.debian.org' folder-hook =list.debian-backports 'my_hdr To: backports-us...@lists.backports.org' folder-hook =list.debian-french 'my_hdr To: debian-user-fre...@lists.debian.org' folder-hook =list.mutt 'my_hdr To: mutt-users@mutt.org' ...[and so on]... Thanks a lot, -- Nicolas
Re: reply_regexp help to match 'RE :'
On Mon, Nov 23, 2009 at 08:32:33PM +0100, Nicolas KOWALSKI wrote: On Mon, Nov 23, 2009 at 11:23:19AM -0800, Gary Johnson wrote: changed my 'reply_regexp' by adding [ \t]* before the color per Cameron's suggestion, and replied to it. Mutt removed the RE : and replaced it with Re: , as it should. So there's something else broken in my config. I will search. Just for the record, it looks like it works (not always, but that does not matter). I received other mails issued from these broken MUA, and they are threaded correctly, and the replies subjects are ok. Thanks to all, -- Nicolas
Re: Problem with Mutt and Dovecot-Listescape
Hello Daniel, Daniel Spannbauer d...@marco.de writes: I think, the error is the script which finds the folders in the maildir-folder: Maybe something like the following: mailboxes =INBOX `cd $HOME/.maildir ; find . -maxdepth 1 -type d -name '.[0-9a-zA-Z_-]*' | sed -e 's,^\./\.,=,' | sort | tr '\n' ' '` My 0.02.. -- Nicolas
Re: reply_regexp help to match 'RE :'
On Mon, Nov 23, 2009 at 10:01:09AM +1100, Cameron Simpson wrote: There's no whitespace before the colon in the above pattern, so it won't match RE :. Try: set reply_regexp=^((re([\[^-][0-9]+\]?)*|aw|antwort|antw|wg)[ \t]*:[ \t]*)+ You can see I've added [ \t]* before the colon. Thanks for your reply. I just tried, and it is still not working; this is quite puzzling... Well, I just saved the raw message, and when here is what's in the start of the subject header: Subject: =?ISO-8859-1?Q?RE_=3A_ This would explain why the regexp never matches. But now, how to make it match this encoded string? -- Nicolas
Re: reply_regexp help to match 'RE :'
On Mon, Nov 23, 2009 at 11:23:19AM -0800, Gary Johnson wrote: changed my 'reply_regexp' by adding [ \t]* before the color per Cameron's suggestion, and replied to it. Mutt removed the RE : and replaced it with Re: , as it should. So there's something else broken in my config. I will search. Thanks for your testing, -- Nicolas
reply_regexp help to match 'RE :'
Hello, Sometimes I receive mail replies with the RE : original subject string as subject. This RE : is apparently not recognized by the default reply_regexp value, because when I reply to this kind of mail, mutt add another Re: in front of the subject line; furthermore, the threading is broken. Instead of the default, I tried to use the following value, by inserting a space just before the [\[ 0-9\]+], but it still does not work: set reply_regexp=^(re( [\[ 0-9\]+])*|aw):[ \t]* I am not especially good at regexps, so any help would be welcome. Thanks, -- Nicolas
Re: reply_regexp help to match 'RE :'
On Sat, Nov 21, 2009 at 09:14:08PM +0100, Michael Wagner wrote: * Nicolas KOWALSKI n...@petole.demisel.net 21.11.2009 Sometimes I receive mail replies with the RE : original subject string as subject. This RE : is apparently not recognized by the default reply_regexp value, because when I reply to this kind of mail, mutt add another Re: in front of the subject line; furthermore, the threading is broken. Instead of the default, I tried to use the following value, by inserting a space just before the [\[ 0-9\]+], but it still does not work: set reply_regexp=^(re( [\[ 0-9\]+])*|aw):[ \t]* Hello Nicolas, I have this in my muttrc and it works: set reply_regexp=^((re([\[^-][0-9]+\]?)*|aw|antwort|antw|wg):[ \t]*)+ Thanks for your reply. Well, I just tried it (edited my ~/.muttrc and restarted), and it still does not work. :-/ -- Nicolas
Re: Displaying tar.gz archives
On Wed, Jul 22, 2009 at 08:00:47AM +0100, Noah Slater wrote: I would like to add a mailcap entry so that I view the contents of tar.gz archives as a list of filenames, but I'm, not sure how to do it. When I attach one, it is added with the application/octet-streem MIME type. Any thoughts on how to approach this? Look at mime_lookup in the documentation. -- Nicolas Sebrecht
Re: mutt removing stuff in brackets from subject
On Wed, Jun 17, 2009 at 02:57:45PM +0200, Michael Tatge wrote: * On Wed, Jun 17, 2009 09:47AM +0200 Rejo Zenger (mutt-us...@subs.krikkit.nl) muttered: ++ 16/06/09 19:51 +0200 - Michael Tatge: When I respond to an email that has a subject similar to: [StuffHere] Blah Blah Blah Mutt actually *removes* everything inside of the brackets and the brackets themselves. Any thoughts on why this happens? Works fine here. There is a setting that might be resposible though. Check reply_regexp Correct me if I'm wrong, but I don't think that particular setting would remove a thing form the subject. The manual says: A regular expression used to recognize reply messages when threading and replying. ^ I tend to think it should not be used when threading: replying and threading are two unrelated tasks. What about adding a $thread_regexp? -- Nicolas Sebrecht
Re: use current folder name as argument to abitrary command
* Rocco Rutte pd...@gmx.net [2009-07-10 13:44 +0200]: I don't know if I mentioned this already, but I think I once hacked support for read-only variables in mutt-ng that would expose certain internal settings. Would something like this be useful for mutt, too? If yes, doing this for one variable only is silly, so anything else that's needed besides the current folder name? I think, this could be very useful. Message-ID of the current message, filename of the current message (for maildir/mh folders). Nicolas -- http://www.rachinsky.de/nicolas
Re: How can I know if error happens when sending mail?
* JP Bruns emailj...@gmx.de [2009-06-02 10:37 +0200]: Is there anything for console-only systems? Mutt is a great piece of software, but - in my eyes - is lacking this important feature. Would it be possible to take the return-code/-message of the *smtp program and display that on the status-line (or the message(?)-line)? What about creating a mail-reply to that message on its own with the sending-error as body and mark that as new mail? Please wrap your lines. The manual says about sendmail_wait: Note that if you specify a value other than 0, the output of the child process will be put in a temporary file. If there is some error, you will be informed as to where to find the output. So it seems, the feature you want is already there. Nicolas -- http://www.rachinsky.de/nicolas
Re: Check folders in an alphabetical way
On Tue, May 05, 2009 at 10:33:17AM +0200, Aiko Barz wrote: I use set imap_check_subscribed=yes to check all my subscribed IMAP folders. Is it possible to order the subscribe list from the server in an alphabetical way? To be precise: The 'c' (change-folder) key shall return the next folder in alphabetical order. I don't know if it would work with imap but it should be possible to order the folder using the key o. -- Nicolas Sebrecht
Re: [Solved?] mailing lists and gmail with mutt
On Sat, May 02, 2009 at 08:55:41AM +0200, Nicolas Sebrecht wrote: Recently, I moved one of my email address to gmail. The problem is that Google thinks it's a good idea to not show what _they_ consider to be duplicated mails. I have one folder per mailing list. When I send/receive emails to a mailing list, I expect to have a copy into my INBOX and another copy into the dedicated folder (e.g. the sender did To: list-address Cc: me ) Also, I'm filtering emails with imapfilter. The rules are based on fields like List-Id. What's happening quite often is that when somebody answers (both to a mailing list and me), the first message I receive is that which addressed to me. As the second mail is not downloaded, it breaks the threads in the folder of the mailing list. There seems to be a workaround. Instead of basing the filter rules against the List-Id field, imapfilter can easily parse both the Cc: and To: headers (contain_cc() and contain_to()) and copy the mails to the good folder (copy_messages()). I expect it should work but as the folders are labels at Google, I can't say. I didn't tested and probably won't because I've already switched to gmx. -- Nicolas Sebrecht
Re: mailing lists and gmail with mutt
On Sat, May 02, 2009 at 07:40:11PM +0700, Dave Patterson wrote: To get around the gmail problem of not sending what they think is a copy, I use a folder-hook to make a copy of mail sent and place the copy in the folder I'm working from, or the catch-all 'Sent' folder. Yes. I had some minds like that, but it won't work for the mail I receive: To: me Cc: list Occasionally, I will actually log on to their site and delete everything I can see. One day later, moѕt 'conversations' will remain. Think about it. Ouch. Actually, I'm switching to another emails provider (gmx.com). Thank you all, -- Nicolas Sebrecht
mailing lists and gmail with mutt
Hi folks! (My question is not purely mutt related. I'm posting here because I think here is where I can have the best answers). Recently, I moved one of my email address to gmail. The problem is that Google thinks it's a good idea to not show what _they_ consider to be duplicated mails. I have one folder per mailing list. When I send/receive emails to a mailing list, I expect to have a copy into my INBOX and another copy into the dedicated folder (e.g. the sender did To: list-address Cc: me ) Also, I'm filtering emails with imapfilter. The rules are based on fields like List-Id. What's happening quite often is that when somebody answers (both to a mailing list and me), the first message I receive is that which addressed to me. As the second mail is not downloaded, it breaks the threads in the folder of the mailing list. Is there a way to tell Google to NOT do what _they_ think is the best for me? Or maybe I missed a mutt configuration option? My web researchs didn't help me. Thanks, -- Nicolas Sebrecht
Re: Detecting new mail in mbox format
Grant Edwards gra...@visi.com writes: Another poster claimed that it works for him. I didn't (and don't) believe him. You are right, my testing was not extensive enough. The timeout setting was handling the refresh of my mailboxes itself, not my manual hit of '.' Using the advice of Wolf, on my (debian version of) mutt, I now have defined this hook, which works well: folder-hook '^imap://' 'macro index,pager $ sync-mailboximap-fetch-mail' -- Nicolas
Re: Detecting new mail in mbox format
Nicolas KOWALSKI n...@petole.demisel.net writes: folder-hook '^imap://' 'macro index,pager $ sync-mailboximap-fetch-mail' Oops, please forget the above. For '.', I have this: folder-hook '^imap://' 'macro index,pager . imap-fetch-mailbuffy-list' -- Nicolas
Re: Detecting new mail in mbox format
Grant Edwards gra...@visi.com writes: 2) I just tried it, and it does nothing. It's bound to '.'. When I hit '.' absolutely nothing happens. No IMAP commands are sent to server to check either the current folder or the folders in the mailboxes list. Hello, What are your settings for mail_check and timeout? In my case (with a dovecot Imap server), I am using: set mail_check=30 set timeout=60 It works well. -- Nicolas
Re: Detecting new mail in mbox format
Grant Edwards gra...@visi.com writes: On 2009-04-25, Nicolas KOWALSKI n...@petole.demisel.net wrote: Grant Edwards gra...@visi.com writes: 2) I just tried it, and it does nothing. It's bound to '.'. When I hit '.' absolutely nothing happens. No IMAP commands are sent to server to check either the current folder or the folders in the mailboxes list. What are your settings for mail_check and timeout? mail_check is 90 timeout is 15 In my case (with a dovecot Imap server), I am using: set mail_check=30 set timeout=60 It works well. It being hitting the '.' key to check for new mail in the current folder? Yes, both '$' and '.' work. -- Nicolas
Re: get mail in directory browser
On Mon, Apr 06, 2009 at 09:56:08PM -0500, Zhengquan Zhang wrote: macro index,pager G ! /usr/bin/getmail -v \n Invoke getmail macro generic,pager G ! /usr/bin/getmail -v \n Invoke getmail -- Nicolas Sebrecht
