Re: Add header automatically
Eric Smith schrieb am 25.06.2010 um 08:11 (+0200): Is it possible to configure mutt to place an extra header in the edit buffer each time you go into edit mode? I want the line `attach:' Yes, it is possible: add the header with a non-empty value and it'll be present in the edit buffer, no need to unignore it: my_hdr Attach: ~/empty.txt set edit_headers = yes Then it is easier to paste in filenames or if you paste nothing it is ignored. (When I use vim, I have a nice binding for this but not with nano - which for some reason I am using more and more). Can only be minimalism ;-) -- Michael Ludwig
folder-hook doesn't work anymore with gmail
hi mutt users, time ago i set folder hooks to set different macros for different folders, in particulary gmail's imap. now these hooks don't work anymore. i controlled it twice and i'm preatty sure they worked for a while: when i change folder and enter gmail's inbox, folder variable is still set to '~/mail' and macros are not changed. i'm using debian testing's package[1] and before debian stable, maybe in the upgrade something changed. thanks m. here the hooks: unhook folder-hook folder-hook . 'push collapse-all; \ set folder=~/mail; \ source ~/.mutt/key_bindings; \ macro index,pager S enter-commandunset wait_keyenterpipe-messagespamassassin --progress -renterenter-commandset wait_keyentersave-message=spamenter \ Tags a given message as SPAM and report it to spamassassin; \ macro index,pager H enter-commandunset wait_keyenterpipe-messagesa-learn --progress --hamenterenter-commandset wait_keyentersave-message=inboxenter \ Tags a given message as HAM and save it to inbox;' folder-hook 'imaps://imap\.gmail\.com/' 'set folder=imaps://imap.gmail.com; \ macro index,pager S save-message=[GoogleescspaceMail]/Spamenter \ Mark message as spam; \ macro index,pager H save-message=INBOXenter mark message as ham;' [1] Mutt 1.5.20 (2009-06-14) Copyright (C) 1996-2009 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 2.6.33.1 (x86_64) ncurses: ncurses 5.7.20100313 (compiled with 5.7) libidn: 1.15 (compiled with 1.18) hcache backend: tokyocabinet 1.4.37 Opzioni di compilazione: -DOMAIN +DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_IMAP +USE_SMTP -USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +USE_GSS +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +COMPRESSED +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL=/usr/sbin/sendmail MAILPATH=/var/mail PKGDATADIR=/usr/share/mutt SYSCONFDIR=/etc EXECSHELL=/bin/sh MIXMASTER=mixmaster To contact the developers, please mail to mutt-...@mutt.org. To report a bug, please visit http://bugs.mutt.org/. debian-specific/467432-write_bcc.patch debian-specific/Md.etc_mailname_gethostbyname.diff debian-specific/Muttrc debian-specific/assumed_charset-compat debian-specific/build_doc_adjustments.diff debian-specific/correct_docdir_in_man_page.diff debian-specific/document_debian_defaults debian-specific/dont_document_not_present_features.diff debian-specific/sort-patchlist debian-specific/use_usr_bin_editor.diff features-old/patch-1.5.4.vk.pgp_verbose_mime features/compressed-folders features/compressed-folders.debian features/ifdef features/purge-message features/sensible_browser_position features/trash-folder features/xtitles misc/am-maintainer-mode misc/define-pgp_getkeys_command.diff misc/gpg.rc-paths misc/hg.pmdef.debugtime misc/hyphen-as-minus.patch misc/smime.rc misc/smime_keys-manpage.patch mutt.org upstream/228671-pipe-mime.patch upstream/311296-rand-mktemp.patch upstream/383769-score-match.patch upstream/393926-internal-viewer.patch upstream/528233-readonly-open.patch upstream/531430-imapuser.patch upstream/533209-mutt_perror.patch upstream/533370-pgp-inline.patch upstream/533439-mbox-time.patch upstream/533459-unmailboxes.patch upstream/533520-signature-highlight.patch upstream/534543-imap-port.patch upstream/535096-pop-port.patch upstream/537694-segv-imap-headers.patch upstream/537818-emptycharset.patch upstream/538128-mh-folder-access.patch upstream/542344-dont_fold_From_ upstream/542817-smimekeys-tmpdir.patch upstream/542910-search-segfault.patch upstream/543467-thread-segfault.patch upstream/544180-italian-yesorno.patch upstream/544794-smtp-batch.patch
Re: folder-hook doesn't work anymore with gmail
Marco Giusti schrieb am 25.06.2010 um 08:50 (+0200): i'm using debian testing's package[1] and before debian stable, maybe in the upgrade something changed. There is a slight version change: http://packages.debian.org/lenny/mutt - stable - mutt (1.5.18-6) http://packages.debian.org/squeeze/mutt - testing - mutt (1.5.20-9) -- Michael Ludwig
Re: A wish for the mailboxes command
On Thu, Jun 24, 2010 at 09:07:01AM -0700, Chip Camden wrote: On Jun 24 16:09, Chris G wrote: After all the recent discussion of detecting new mail etc. it occurs to me that it would be very useful to be able to tell mutt that it should scan all files in a particular directory for new mail. If one does have more than one (and non-standard) incoming mail destinations then it's almost inevitable that they will be in one place, or at most two or three places. In my case I have:- ~/Mail/In with inbox, junk and bcs in it ~/Mail/Li with all my mailing list incoming mail, each to its own file/folder If I could just say:- mailboxes ~/Mail/In ~/Mail/Li it would make my life a whole lot simpler. (I guess I might want to unmailboxes ~/Mail/In/junk) -- Chris Green I don't rely on mutt to tell me when new mail arrives. For one thing, I usually have a different workspace active. So I display it in an xmobar section, and use this ruby script to test for new mail in each mbox file: I don't really want to know when new mail arrives, what I want is the ability to quickly go to all the mailboxes which have new incoming mail when I'm running mutt. I don't have any need to respond quickly to messages, just a need to be able to find them. Mutt usually sits running in a dedicated terminal on one of my workspaces with the 'main' inbox displayed so I just need to glance at that to see any non-list E-Mails. -- Chris Green
Re: Message save causes erroneous New mail detection.
On Thu, Jun 24, 2010 at 09:00:13AM -0800, rog...@sdf.org wrote: On Thu, Jun 24, 2010 at 03:05:14PM +0200, Christian Ebert wrote: I can't reproduce this, neither with $check_mbox_size set or unser. Unless, of course, I copy a message that is flagged as New. I've seen this sporadically when receiving new email, reading it, then restarting mutt later or returning a few hours later and finding the email is again marked new. If you don't exit from mutt properly this is exactly what you will see. I.e. if you have mutt running in a terminal window and close your computer down without exiting from mutt any messages you have read will not be marked as read when you start up again. -- Chris Green
Re: Message save causes erroneous New mail detection.
On Thu, Jun 24, 2010 at 02:57:05PM +0100, Chris G wrote: If one writes a message to an mbox file then the size changes and (if atime is enabled) the modification time will be after the access time. So mutt *has* to say there's new mail in the mailbox. Ah, then it is possibly only the immediate message in the status line at the bottom of the window, which is new. Since the erroneous [1] behaviour isn't user correctable, instead of saving messages for later action to !, I'll save them to todo, then. Since that folder will never receive real new mail, it'll be clear that the status line message from mutt does in fact not relate to new mail. Since the emails will no longer be in !, I'll need something to prompt me to go into the todo mail folder e.g. after the next boot. A trivial script can cat an empty email to the file, on every login, to flag the folder for reading. I wonder if there is a more elegant way than cluttering the folder with piffle? It gets it right to the extent that the 'new' mail isn't marked as such in the index if it's not really new but I can see no way that mutt could act otherwise regarding seeing the mailbox as having new mail in it. [1] If mutt knows not to flag the transferred email as new, then it also knows enough not chuck up the erroneous New mail message. The logic used for the message flags is different from that used for confusing the user with a false message, it appears. Many thanks for the explanation. Erik -- Further north on Queensland's Gold Coast, a company constructing a new apartment block on low-lying ground was ordered to install emergency moorings for rescue boats on the building's first floor because of concerns over the possible impact of climate change. - http://news.bbc.co.uk/2/low/asia-pacific/8542355.stm
Two alternative proposed fixes [Was: Re: A wish for the mailboxes command]
On Fri, Jun 25, 2010 at 10:47:29AM +0100, Chris G wrote: I don't really want to know when new mail arrives, what I want is the ability to quickly go to all the mailboxes which have new incoming mail when I'm running mutt. I don't have any need to respond quickly to messages, just a need to be able to find them. Mutt usually sits running in a dedicated terminal on one of my workspaces with the 'main' inbox displayed so I just need to glance at that to see any non-list E-Mails. That is also my usage pattern. If a script like Chip Camden's, or one in Gawk, running as a coprocess to mutt, could steer mutt's mail Newness decisions, then mutt's current erroneous behaviour could be fixed, possibly using more effort than is necessary. I would be delighted to write, debug, and maintain the coprocess, if it were necessary to go that way. While that would be a lot of fun, mutt itself does seem able to be cured of its current fibbing behaviour. (Try copying this message to this mail folder. Mutt says New mail in this mailbox. What hokum.) Mutt needs to check the size and/or atime of the destination folder _before_ it writes, rather than cookily doing it _after_. Then the erroneous and misleading immediate message would go away. To fix the problem of mutt adding the transfer recipient folder to its list of New folders on its next scan, another small bugfix is also required. Once the recipient file has been written, mutt needs to update its current values for file size and atime, so that the Newness reference will be correct. Would that not put an end to its fibbing ways? Erik -- Never worry about theory as long as the machinery does what it's supposed to do. -- Robert A. Heinlein
Re: Message save causes erroneous New mail detection.
On Fri, Jun 25, 2010 at 08:05:31PM +1000, Erik Christiansen wrote: [1] If mutt knows not to flag the transferred email as new, then it also knows enough not chuck up the erroneous New mail message. The logic used for the message flags is different from that used for confusing the user with a false message, it appears. Yes, the N[ew], O[ld] and other flags are actually written to the mbox as I understand it - yes, just looked, there's a Status: line in the message header which has flags in it. Scanning for new messages is done (for mbox) by looking to see if the mbox file has changed since last read. Presumably mutt doesn't look at the header Status: line because that would take too long. It's a pity that there isn't an option to tell mutt to use the Status: header to check for new messages, on a fast single-user system that would be quite fast enough and much more accurate. -- Chris Green
Re: Message save causes erroneous New mail detection.
On Fri, Jun 25, 2010 at 12:10:54PM +0100, Chris G wrote: On Fri, Jun 25, 2010 at 08:05:31PM +1000, Erik Christiansen wrote: [1] If mutt knows not to flag the transferred email as new, then it also knows enough not chuck up the erroneous New mail message. The logic used for the message flags is different from that used for confusing the user with a false message, it appears. Yes, the N[ew], O[ld] and other flags are actually written to the mbox as I understand it - yes, just looked, there's a Status: line in the message header which has flags in it. Yes, and when the Status: header is missing, the message is New. That began to become evident when I started throwing a fudged message into my todo mailbox, to make it New, to prompt me to look in there. Scanning for new messages is done (for mbox) by looking to see if the mbox file has changed since last read. Presumably mutt doesn't look at the header Status: line because that would take too long. Yes, but the primitive nature of the scanning is causing the false detection of New mail. It's a pity that there isn't an option to tell mutt to use the Status: header to check for new messages, on a fast single-user system that would be quite fast enough and much more accurate. There is a much faster way, as I've proposed on your other thread A wish for the mailboxes command. On my system though, it would be enough for mutt to check six times per hour, since that is how often the mailhost is polled. Here the method would not have to be ultra high speed. Erik -- A computer is like an air conditioner, it works poorly when you open Windows.
Re: folder-hook doesn't work anymore with gmail
On Fri, Jun 25, 2010 at 09:08:56AM +0200, Michael Ludwig wrote: Marco Giusti schrieb am 25.06.2010 um 08:50 (+0200): i'm using debian testing's package[1] and before debian stable, maybe in the upgrade something changed. There is a slight version change: http://packages.debian.org/lenny/mutt - stable - mutt (1.5.18-6) http://packages.debian.org/squeeze/mutt - testing - mutt (1.5.20-9) Changelogs don't explain why my configuration doesn't work anymore. Maybe I am missing something oblivious. m. -- C'è un'ape che se posa su un bottone di rosa: lo succhia e se ne va... Tutto sommato, la felicità è una piccola cosa. -- Trilussa, Felicità
Re: Two alternative proposed fixes [Was: Re: A wish for the mailboxes command]
Erik Christiansen schrieb am 25.06.2010 um 20:48 (+1000): While that would be a lot of fun, mutt itself does seem able to be cured of its current fibbing behaviour. (Try copying this message to this mail folder. Mutt says New mail in this mailbox. What hokum.) Confirmed :-) Mutt needs to check the size and/or atime of the destination folder _before_ it writes, rather than cookily doing it _after_. Then the erroneous and misleading immediate message would go away. To fix the problem of mutt adding the transfer recipient folder to its list of New folders on its next scan, another small bugfix is also required. Once the recipient file has been written, mutt needs to update its current values for file size and atime, so that the Newness reference will be correct. Would that not put an end to its fibbing ways? Sounds like it would! One more example, I have the following setting to store mail conversations as threads: set spoolfile = +Neu # c! set record = +Neu # c So when I send a message that is not going to a list, it goes to +Neu, and I'm notified of a new message in +Neu, which is technically correct, but as I put it there myself I don't need to be told about it. Checking for new mail before a user-triggered write operation, as you suggested, would, I think, fix the issue. -- Michael Ludwig
where do you store your gpg-keys
Hi everybody, since I use screen on a remote server to read mails with mutt, the question of how to securely store gpg-keys is bothering me. At the moment I simply don't use gpg on the remote machine. But since I receive more encrypted mails lately, I am looking for a solution. Asking google reveals that gpg-agent is not capable of something like ssh-agents ForwardAgent. I found a rather confusing tutorial for using the linux-kernels keystore[1]. But before I try that, I wanted to ask if someone here has a working solution for this problem. Cheers, Christoph [1] http://snafu.priv.at/interests/crypto/remotegpg.html
Re: A wish for the mailboxes command
On Fri, Jun 25, 2010 at 10:47:29AM +0100, Chris G wrote: On Thu, Jun 24, 2010 at 09:07:01AM -0700, Chip Camden wrote: I don't really want to know when new mail arrives, what I want is the ability to quickly go to all the mailboxes which have new incoming mail when I'm running mutt. I don't have any need to respond quickly to messages, just a need to be able to find them. Mutt usually sits running in a dedicated terminal on one of my workspaces with the 'main' inbox displayed so I just need to glance at that to see any non-list E-Mails. Hmmm, if i understand it right sidebar will be your friend. It shows all folders/files with new mails and give you quick acces to them. Greetings Alex Huth
Re: A wish for the mailboxes command
On Fri, Jun 25, 2010 at 03:23:55PM +0200, Alex Huth wrote: On Fri, Jun 25, 2010 at 10:47:29AM +0100, Chris G wrote: On Thu, Jun 24, 2010 at 09:07:01AM -0700, Chip Camden wrote: I don't really want to know when new mail arrives, what I want is the ability to quickly go to all the mailboxes which have new incoming mail when I'm running mutt. I don't have any need to respond quickly to messages, just a need to be able to find them. Mutt usually sits running in a dedicated terminal on one of my workspaces with the 'main' inbox displayed so I just need to glance at that to see any non-list E-Mails. Hmmm, if i understand it right sidebar will be your friend. It shows all folders/files with new mails and give you quick acces to them. Only if it knows which ones have new mail in them! That's where we came in. -- Chris Green
Re: Two alternative proposed fixes [Was: Re: A wish for the mailboxes command]
On Fri, Jun 25, 2010 at 02:46:23PM +0200, Michael Ludwig wrote: Checking for new mail before a user-triggered write operation, as you suggested, would, I think, fix the issue. Thank you. After checking 114 fleas which mentioned New mail, I've added ticket #3424. Erik -- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw
Re: A wish for the mailboxes command
On Fri, Jun 25, 2010 at 03:33:07PM +0100, Chris G wrote: On Fri, Jun 25, 2010 at 03:23:55PM +0200, Alex Huth wrote: Only if it knows which ones have new mail in them! That's where we came in. That´s what i am talking about. I am using sidebar with lot of maildirs and the following in the config: set check_new=yes set mail_check=60 Works perfect! Greetings Alex Huth
Re: where do you store your gpg-keys
I'm not an expert, but there is a work around I think will work. You can store your keys on a flash drive... and possibly the entire OS for that matter. If you do this, you have no problems. Alternatively, you can encrypt a document and send it as an attachment. Your fellow international spy types can do the same. With this method, you don't even need full gpg/email integration... and you don't have to worry about inline versus mime encryption. Dale On Fri, Jun 25, 2010 at 8:10 AM, Christoph Kluenter christ...@kluenter.de wrote: Hi everybody, since I use screen on a remote server to read mails with mutt, the question of how to securely store gpg-keys is bothering me. At the moment I simply don't use gpg on the remote machine. But since I receive more encrypted mails lately, I am looking for a solution. Asking google reveals that gpg-agent is not capable of something like ssh-agents ForwardAgent. I found a rather confusing tutorial for using the linux-kernels keystore[1]. But before I try that, I wanted to ask if someone here has a working solution for this problem. Cheers, Christoph [1] http://snafu.priv.at/interests/crypto/remotegpg.html -- Nothing is ever so bad that it couldn't be worse, and if it could be worse than it is, then maybe its not so bad!
Re: where do you store your gpg-keys
On Fri, Jun 25, 2010 at 03:10:34PM +0200, Christoph Kluenter wrote: Hi everybody, since I use screen on a remote server to read mails with mutt, the question of how to securely store gpg-keys is bothering me. If you have junk gpg keys, then put them on a shared remote machine and type your passphrase across the network. Do this only with junk keys, however, as you may be dealing with a trojaned sshd, cracked remote machine, etc. If you have secure gpg keys, then keep them on a USB flash drive (optionally in an encrypted filesystem), mount it only when you are encrypting and decrypting, don't allow inbound network connections or other users on your system, and only type your passphrase(s) on the local console keyboard. This minimizes the opportunities to steal your keyrings and capture your passphrases. For casual users whose threats are mostly opportunistic eavesdropping, the former should be good enough. For security work, where the threats are focused on trojaning things to get at the meaty details, the latter is pretty much required. The latter can still be done with a remote mail setup with two extra steps. Pulling a saved message onto the secure desktop from the remote machine, then manually running gpg on the secure desktop, is the best way to handle remote mail + secure keyrings. In reverse, we 'gpg -sea' a file on the secure desktop, push the resulting .asc file up to the remote mail system, and attach it to a mail message as a text file. Most correspondents can handle the results. Richard
What-key Example
How is the what-key function used and should the Mutt wiki include an example of it's usage? (From reading, I'm guessing it should be set within either the muttrc or :set command prompt.) -- Roger http://rogerx.freeshell.org/
What map is default for .maildir?
I'm trying to figure out why bind keys are not working, and finding the reason being, the default view for my $HOME/.maildir folder on startup isn't defined as index or pager (or any maps mentioned within the Mutt Wiki map/bind keys sections). Here's what my default view looks like: q:Exit c:Chdir m:Mask ?:Help 1 4.0K Jun 19 15:25 =.abook-devel/ 2 4.0K Jun 21 22:44 =.cdw-devel/ 3 4.0K Feb 13 09:35 =.cmus-devel/ 4 4.0K Jun 25 13:12 =.dillo/ 5 4.0K Jun 25 13:02 =.Drafts/ 6 4.0K Feb 13 09:48 =.dsctl-devel/ 7 4.0K Jun 12 21:26 =.gcc-bugzilla/ 8 4.0K Jun 25 13:05 =.gentoo-bugzilla/ 9 4.0K Feb 12 22:48 =.gentoo-wiki/ 10 4.0K Jun 17 22:31 =.kernel-bugzilla/ ... and so on. I have a basic $HOME/.maildir with $HOME/.maildir/.subfolders listed. I'm guessing, this is just a basic folder view with no map definition at all! Once I enter a folder, I'm guessing that would be called index view/map and pager view/map would be when my $PAGER is invoked to read an email. (The other maps mentioned within the Mutt Wiki are self explanatory, but a few are still unknown to me -- ie. alias and generic.) -- Roger http://rogerx.freeshell.org/
