Re: [Feature request] mailbox aliases and internal filtering
* Vincent Lefevre ([EMAIL PROTECTED]) [020701 08:47]: And using push doesn't work correctly with IMAP folders because the corresponding characters are sent as password characters (for security reasons, I don't store my password on my account, though I could change my mind later). If you're not using SSH or SSL for your IMAP anyway, it's no less safe in your go-r .muttrc than it is on the wire each time you connect. You might as well set it there. good times, Vineet -- http://www.doorstop.net/ -- Computer Science is no more about computers than astronomy is about telescopes. -E.W. Dijkstra msg29341/pgp0.pgp Description: PGP signature
Re: [Feature request] mailbox aliases and internal filtering
On Tue, Jul 02, 2002 at 00:20:17 -0700, Vineet Kumar wrote: If you're not using SSH or SSL for your IMAP anyway, it's no less safe [...] On the internal network, we have the choice between using SSL or not (and it's regarded as safe as it's on the internal network, though I prefer to use SSL even in this case). From external machines, we have to use SSL. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Deleting portions of large mail folders
This is a both a suggestion for a message pattern matching facility which currently isn't implemented, and a usage question about how to use the existing capabilities of mutt more efficiently. I subscribe to many (probably too many) mailing lists. Most get automatically sorted by procmail to their own mail files. Some of these folders quietly accumulate hundreds, thousands, and in one case tens of thousands of messages over the course of months or years. Every so often I take a look at these and try to keep some of the messages and get rid of the rest. Most of the messages in such mail folders are going to be deleted unread. I have found that while targeted subject or author searches are useful, my usual tool for identifying what I want to read is the Mark I eyeball--a quick scan over an index screen with a threaded subject listing, with a few quick previews is usually enough to identify what I want to keep. Manually deleting each unwanted message or thread is fine when deleting on the order of tens or dozens of unwanted messages/threads. However, this gets tedious when I want to delete hundreds of messages/threads. In this case, the ~U pattern is my friend, and it isn't too much of a problem to go through a few screenfuls of messages, pick out the ones to save, and delete the other several hundred unread messages. Where my current methods break down is dealing with mail files with thousands of unread messages. I have found that it isn't practical to do even a cursory scan in one sitting of all of the message index displays before discarding all of the unread messages (~U). In that case I either give up and get of all the old messages, perhaps losing something that I might want to read, or just continue to let messages accumulate without trimming significantly. While mutt easily handles mail files with tens of thousands of messages, and tens or hundreds of megabytes (given sufficient tmp file space), I don't really like letting things get that big without cleaning it out. I can scan a portion of the unread messages in one session, so what I would like to be able to is to match, in some fashion, the messages that I have scanned. One possibility would be a pattern, say ~I, which would match all messages currently displayed in the Mutt index display. Then I could bind a key sequence to something like delete-pattern ~I ~U and scan and delete messages a screenful at a time. My ~I pattern doesn't seem to be currently implemented in Mutt, so I'll throw it out as a suggestion. How do the rest of you handle cleaning out really big mail folders? Thanks, -- Wayne Chapeskie GnuPG/PGP KeyID: 0xB9D2D272
BUG/RFI: scope of 'send-hook' too large ...
Not sure if my list subscription has gone through yet (I haven't seen any confirmation so it might not have) but you might want to know about this anyway ... Is there any way to limit the scope of the changes made with the -hook commands? For instance, I have several mailing lists for which I use a different address to post from, so I use something like send-hook blah 'my_hdr From: Malcolm Herbert [EMAIL PROTECTED]' to set my From: header appropriately. Unfortunately if I send to these lists my From: header remains changed, for the life of the session. Is there any way to limit the scope of the send-hook change to just the message being composed, then either reverse the change, or have it revert automatically? -- Malcolm HerbertThis brain intentionally [EMAIL PROTECTED]left blank
Re: BUG/RFI: scope of 'send-hook' too large ...
On Tuesday, 02.07.2002 at 15:52 +1000, Malcolm Herbert wrote: Is there any way to limit the scope of the changes made with the -hook commands? For instance, I have several mailing lists for which I use a different address to post from, so I use something like send-hook blah 'my_hdr From: Malcolm Herbert [EMAIL PROTECTED]' to set my From: header appropriately. Unfortunately if I send to these lists my From: header remains changed, for the life of the session. This is one of Mutt's most frequently asked questions. :-) The behaviour you describe is how hooks work, by design. In order to do what you need, you should have something like: send-hook . 'my_hdr From: Default From [EMAIL PROTECTED]' send-hook blah 'my_hdr From: Malcolm Herbert [EMAIL PROTECTED]' The hooks are 'executed' for every message, so you need to make sure that something will match for every message in the way you'd like. The first line I've given above sets a default, which can then be followed by one or more modifications - just one in this case. Does that make sense? Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 msg29345/pgp0.pgp Description: PGP signature
Mutt Error
Hi all, I have a problem with my mutt mail reader. I use Exim as my mail server with Maildir option. My Mutt can read mails from the Maildir folder quite alright butwhen i try to send mails, it returns with this error below Error sendind message, child exited 127 (Exec error.). Please what could be wrong and how can i correct this. Thanks and kind regards, -fisayo
Re: Mutt Error
--liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Lee J. Moore [EMAIL PROTECTED], 2002-07-02 08:17 -0400: On Tue, 02 Jul 2002, Fisayo Adeleke wrote: =20 Hi all, =20 I have a problem with my mutt mail reader. I use Exim as my mail server= =20 [snip] Error sendind message, child exited 127 (Exec error.). =20 Please what could be wrong and how can i correct this. =20 Have you specified the location of your MTA in muttrc? =20 Example: set sendmail=3D/usr/exim/bin/exim Also check -rwxr-sr-x1 root mail 7652 Jun 28 15:59 /usr/bin/mutt_dotlo= ck -Andre --liOOAslEiF7prFVr Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9IZ4vWkhBtALlJZ0RAuDXAKCF6ehyigCEsXVml065pnASsspn2QCgvTte 1kbsxPPam0Ejj1bxYCtngEI= =e98p -END PGP SIGNATURE- --liOOAslEiF7prFVr--
Re: Deleting portions of large mail folders
--bCsyhTFzCvuiizWE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Wayne Chapeskie [EMAIL PROTECTED], 2002-07-02 08:16 -0400: [snip] How do the rest of you handle cleaning out really big mail folders? 1. collpased threads #collapse threads folder-hook . push \eV set collapse_unread=3Dyes set uncollapse_jump=3Dyes 2. delete duplicates #Delete duplicates folder-hook . push D~=3Denter 3. scoring to delete old Mails either not related to myself directly or flagged as important (which is the criterium to keep mails): # index_format is of course optional set index_format=3D%4C %2M%Z%2N %[%y%m%d] %-17.17F (%3l) %s set score_threshold_delete=3D0 set score_threshold_flag=3D30 set score_threshold_read=3D15 unscore * score '~A' 20 score '~=3D' - score '~P|~p|~Q' 20 # delete unflagged and non-me-related mails oder than 14 days folder-hook . 'score ~=3D|(!(~p|~P|~Q|~F)~d14d) -' # Flagged as ! color index cyan default '~F' 4. archiving the surviving mails (using Esc S) to a folder save. plus foldername: #Delete old; archive macro index \eS 1\ncollapse-alluntag-pattern~A\ntag-pattern= (~P|~p|~Q|~F)~r3w\n;s\n Delete old; archive=20 macro pager \eS q1\ncollapse-alluntag-pattern~A\ntag-patter= n(~P|~p|~Q|~F)~r3w\n;s\n Delete old; archive folder-hook . 'save-hook . =3Dsave.%B' I hope this helps! -Andre --bCsyhTFzCvuiizWE Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9IaSwWkhBtALlJZ0RAmH0AJwNFjISgNyJefx73p0zHJqoW+11vgCgz5zl YFXpZH/vr3VxVa3but8CgF0= =GsN0 -END PGP SIGNATURE- --bCsyhTFzCvuiizWE--
Mailboxstatus and changing box
Hi, I am trying to use procmail and mutt in combination and now have my incoming mails arriving to the spool directory while some mailinglists are sorted to some mailboxes in my home directory. The mailboxes are specified in the .muttrc file but I havenät fully understood if I can : * Step between my mailboxes specified int the .muttrc file without opening the filebrowser? Is their any commando like next-mailbox? * In the statusbar see a total of new messages in all mailboxes? See which mailboxes that have new messages? Cheers, juman
MUTT AND NNTP
Hello, Justed downloaded mutt 1.4 and am interested in patching in NNTP support. which is the best NNTP patch to use? I understand that more than one exists. Thanks in advance, Doug -- Doug Lawlor [EMAIL PROTECTED]
Minor annoyance with fcc-save-hooks
Hi all, i've set up a lot of fcc-save-hooks to set the default folders for certain people (~L pattern folder). This works quite good if there's only one recipient in the headers or one person to whom i send mail. If there are many recipients in the headers or me doing a group-reply, the hook matches one (the first it seems) of them and set the fcc or save-folder accordingly. If i prepend the pattern with ^ then the fcc-hooks won't match if there is more than one recipient, so the fcc's are going to my default send-mail-folder, which is fine. The save-hook of course also won't match and mutt will present me the default-save-folder, which isn't the behaviour i want. Is there any chance in a future version that the behaviour of fcc-save-hooks with the ~L-patterns will get modified to address this issue? I know it's possible to reach my goal if i use save-hooks and fcc-hooks instead of fcc-save-hooks. The disadvantage of this is clear: i (and any other mutt user) will have to set two hooks for every correspondent. With some 50+ correspondents in the configuration file it becomes quite intricate. regards - Lars.
Trouble with macros
Hi everybody, i've got some problems with setting the attributions lines in dependence of the folder and the reply-function used (e.g. reply, group-reply and list-reply). My goal is to set up separate attributions for replies to personal mails (which should be personalised), for group-replies (which of course should name the sender to whoms mail i replied) in the adequate language - which is the problem. The macros... | macro index g ':set attribution=%n schrieb am %[%d.%m.%Y]:\n \ |entergroup-reply' | macro index r ':set attribution=Hallo %v,\n \ |enterreply' ... work as expected. Then i tried the following: | folder-hook . macro index L 'set attribution=%n schrieb \ |am %[%d.%m.%Y]:\n'enterlist-reply It doesn't work. Then after a suggestion from Rocco i tried to source the macros from separate files: | folder-hook . source /home/lars/.mutt/.attributions | folder-hook %personal source /home/lars/.mutt/.attributions.personal | folder-hook %englishlists source /home/lars/.mutt/.attributions.english Again it didn't worked out as i hoped. Has anybody an idea? Is it possible? I tried other ways too, for example checking for multiple recipients with a send-hook | send-hook ~C .+ 'set attribution=%n schrieb am %[%d.%m.%Y]:\n' It doesn't do it. I guess it's because mutt checks every recipient against the regexp and not the whole to/cc-header? TIA. regards, - Lars.
Feature request: cross-mbox threading
Hi, Situation: I usually have to switch between =mbox and =outbox to check the mails on a specific topic we've gone on for a while. Sometimes, another one, say =work/project-A, needs to get involved, too. The same case happens among =mbox.mutt, =outbox, and =mlist/mutt for my daily life. (=mbox,mutt is the in-coming one, =mlist/mutt is for saving the mail I'd like to keep.) Request: Is it possible to have a cross-mbox-threading function as following: 1. A variable, say ref-mboxes (Type: string, default: =mbox:=outbox), to specify related mboxes to reference. The mailbox in front of ':' is the main (or working) mail box, the right side lists the mailboxes to reference. You can add more reference groups by separating them with ';'. 2. A variable, say cross-reference (Type: boolean, default: no), to turn on or off the cross-reference. It will make the referenced mail appear/disappear on the index. 3. When you work on your coming-in =mbox, you can see the threading also reference to those mails in =outbox. (with some display difference) Not all the mails in =outbox appear in current work session - only those belonging to the threads in =mbox will appear. The mails of ref. mailboxes can be read but are read-only. User can not delete or edit them. (unless another variable 'allow-change-ref-mbox' is turned on) It's to avoid confusing. I found such 3-way cross-reference is quite common in my life, and hope it to come true. Thanks. best regards, charlie
Re: Deleting portions of large mail folders
--YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alas! Wayne Chapeskie spake thus: How do the rest of you handle cleaning out really big mail folders? Don't let them get that big in the first place! :P Really. My mail setup looks like this: feztaa@feztron:/home/feztaa/mail$ ls -R =2E: alfs-discuss cron lfs-dev mutt-users wftl-lug archives fetchmail-friends lfs-security netmd-dev blfs-dev inbox lfs-support spam blfs-support lfs-chat mutt-dev wftl-announce =2E/archives: 2001-11-bugtraq.bz22002-04-lfs-security.bz2 2001-11-inbox.bz2 2002-04-lfs-support.bz2 2001-11-marcel-gagne.bz2 2002-04-marcel-gagne.bz2 2001-11-mutt.bz2 2002-04-mutt.bz2 2001-11-rewt.bz2 2002-04-sent-mail.bz2 2001-11-sent-mail.bz2 2002-04-spam.bz2 2001-11-spam.bz2 2002-04-wftl-announce.bz2 2001-12-bugtraq.bz22002-04-wftl-lug.bz2 2001-12-important.bz2 2002-05-alfs-discuss.bz2 2001-12-inbox.bz2 2002-05-blfs-dev.bz2 2001-12-marcel-gagne.bz2 2002-05-blfs-support.bz2 2001-12-mplayer.bz22002-05-cron.bz2 2001-12-mutt.bz2 2002-05-fetchmail-friends.bz2 2001-12-sent-mail.bz2 2002-05-inbox.bz2 2001-12-spam.bz2 2002-05-lfs-chat.bz2 2002-01-blfs-support.bz2 2002-05-lfs-dev.bz2 2002-01-bugtraq.bz22002-05-lfs-security.bz2 2002-01-fetchmail.bz2 2002-05-lfs-support.bz2 2002-01-inbox.bz2 2002-05-mutt.bz2 2002-01-lfs-support.bz22002-05-mutt-users.bz2 2002-01-marcel-gagne.bz2 2002-05-sent-mail.bz2 2002-01-mutt.bz2 2002-05-spam.bz2 2002-01-sent-mail.bz2 2002-05-wftl-announce.bz2 2002-01-spam.bz2 2002-05-wftl-lug.bz2 2002-02-blfs-support.bz2 2002-06-alfs-discuss.bz2 2002-02-fetchmail.bz2 2002-06-blfs-dev.bz2 2002-02-important.bz2 2002-06-blfs-support.bz2 2002-02-inbox.bz2 2002-06-cron.bz2 2002-02-lfs-support.bz22002-06-fetchmail-friends.bz2 2002-02-marcel-gagne.bz2 2002-06-inbox.bz2 2002-02-mutt.bz2 2002-06-lfs-chat.bz2 2002-02-sent-mail.bz2 2002-06-lfs-dev.bz2 2002-02-spam.bz2 2002-06-lfs-security.bz2 2002-03-blfs-support.bz2 2002-06-lfs-support.bz2 2002-03-duplicates.bz2 2002-06-mutt-dev.bz2 2002-03-fetchmail.bz2 2002-06-mutt-users.bz2 2002-03-inbox.bz2 2002-06-netmd-dev.bz2 2002-03-lfs-chat.bz2 2002-06-sent-mail.bz2 2002-03-lfs-support.bz22002-06-spam.bz2 2002-03-marcel-gagne.bz2 2002-06-wftl-announce.bz2 2002-03-mutt.bz2 2002-06-wftl-lug.bz2 2002-03-sent-mail.bz2 2002-07-blfs-dev 2002-03-spam.bz2 2002-07-blfs-support 2002-04-alfs-discuss.bz2 2002-07-cron 2002-04-blfs-dev.bz2 2002-07-inbox 2002-04-blfs-support.bz2 2002-07-lfs-chat 2002-04-cron.bz2 2002-07-lfs-dev 2002-04-fetchmail-friends.bz2 2002-07-lfs-support 2002-04-important.bz2 2002-07-mutt-users 2002-04-inbox.bz2 2002-07-netmd-dev 2002-04-lfs-chat.bz2 2002-07-sent-mail 2002-04-lfs-dev.bz22002-07-spam So as you can see, I have a bunch of mailboxes, and a monthly archive of each mailbox. My system may look cumbersome and hard to work with, but really it's not because of these things: * procmail automatically detects mailing lists and sorts them into appropriate folders. I don't have a single procmail rule that is specific to any one mailing list. * mutt automatically detects mboxes and sets up the mbox-hooks accordingly.=20 * because of the wonderful mbox-hooks, every time I leave a folder, all the mails I read are moved into the appropriate archive folder. * a script that I run from cron every month automatically compresses the old mboxes that are archived. So basically all I have to do is read my email everyday (not even -- I just have to mark it as read if I don't want to read it), and my computer does the rest of the work for me ;) Each archived mbox contains a month's mail from that particular list; obviously the amount of mail in each mbox depends on list traffic for that month, but generally no mbox ever exceeds 1000 mails (though there are at least a couple that have 1500 ;) Oh yeah, and one really great part of this system: Since any read mail in an mbox is automatically moved out, and mail that exists in an mbox is by definition, unread. So when I'm looking at my index, the size of the mbox becomes the new mail indicator: zero for no mail, nonzero for new mail. It works really well for me. YMMV. --=20 Rob 'Feztaa' Park http://members.shaw.ca/feztaa/ -- Lost: gray and white female cat. Answers to electric can opener. --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline
Feature queries
Hi, Broken up into 2 parts for confusion in pieces ;) --Interactive Macros-- Is there a way to define a macro that has the capability to prompt the user for input? The main reason that provoked this question is creating a command similar to sort-mailbox for the secondary sort pattern (sort_aux). I've worked around the problem by creating several views using macros, although I'm still curious if such a feature would have any other use. --Sub-threads-- Does the ability to collapse/expand sub-threads exist in Mutt? (Described with an example at the end of this email) I would imagine that explicit expand and collapse calls (as opposed to a toggle) would provide better flexibility and functionality. collapsing sub-threads is also mentioned in (0 Replies): REF: David T-G 2002-01-20 [mutt-users]turning threads inside out (well, sorta) Finally, while jumping to a message # that is hidden (from a collapsed thread for example), mutt jumps to the next visible message. I haven't dug around on this one to know if that is the intended behavior. Any thoughts? -Joseph (mutt-users digest subscriber, CC appreciated) Example sub-thread functionality: (Arrow is current message) -A -B +C -D -- -E ::collapse-subthread:: -A -B +C -- +D ::collapse-subthread:: -- +A ::collapse-subthread:: -- +A (no effect) ::expand-subthread:: -- -A +B +D A collapse-subthread routine may *need* to first advance to the parent if the current subthread is already collapsed (with either the parent-message function or something else), as it doesn't make to much sense any other way (or at least I couldn't envision much usefulness without it).
