Maildir or mbox?
I'm using mutt about 6 month. For this time I have about 5000 messages in my mbox folder. What format is preffered for using with many messages? Is Maildir faster? I read in this mailing list that someone stores his mail in the folder, organized by years and month. I think that is very good idea. Is it very difficult to do that?
Re: Mailbox is unchanged
Hi, * m...@coreland.ath.cx wrote: I've still not got to the bottom of this problem. My spool now has 200 read emails that I can't get mutt to move. Please read: http://dev.mutt.org/hg/mutt/raw-file/tip/UPDATING when updating mutt. It lists incompatible changes during the development cycle. There you'll find a note about the default value for $move having changed to no so mutt no longer will move mails by default (or ask). Maybe 'set move' in .muttrc does help? Rocco
Re: Maildir or mbox?
Hi, * Andrey Zhidenkov wrote: I'm using mutt about 6 month. For this time I have about 5000 messages in my mbox folder. What format is preffered for using with many messages? Is Maildir faster? I read in this mailing list that someone stores his mail in the folder, organized by years and month. I think that is very good idea. Is it very difficult to do that? It depends on how you receive mail. If you use fetchmail (or the like) it's unlikely that you modify a folder during fetchmail is running and thus mbox likely is a bit faster. Otherwise maildir is the choice as it has no concurrency issues. Sorting into folders can be done using an mbox-hook and 'set move=yes' in .muttrc. Rocco
Re: Maildir or mbox?
On Thu, May 07, 2009 at 01:16:20PM +0200, Rocco Rutte wrote: Hi, * Andrey Zhidenkov wrote: I'm using mutt about 6 month. For this time I have about 5000 messages in my mbox folder. What format is preffered for using with many messages? Is Maildir faster? I read in this mailing list that someone stores his mail in the folder, organized by years and month. I think that is very good idea. Is it very difficult to do that? It depends on how you receive mail. If you use fetchmail (or the like) it's unlikely that you modify a folder during fetchmail is running and thus mbox likely is a bit faster. Yes, I'm using fetchmail to get my mail and procmail to sort it. Otherwise maildir is the choice as it has no concurrency issues. Thanks, I'll try it. Sorting into folders can be done using an mbox-hook and 'set move=yes' in .muttrc. Thank you. One more question: can I convert my mbox folder to maildir format? I can suppose that I can move all my mail into another folder, configure procmail to work with maildir and then run procmail again. Is that right solution? Rocco
Re: Maildir or mbox?
Andrey Zhidenkov wrote: Thank you. One more question: can I convert my mbox folder to maildir format? Yes you can. I can suppose that I can move all my mail into another folder, configure procmail to work with maildir and then run procmail again. Is that right solution? You can convert your mbox to maildir first. The only difference between mbox and maildir in procmail is / at the end of the mailbox name. Cheers, -- Raf http://www.catb.org/~esr/faqs/smart-questions.html
Message header fields displayed in viewer
When mutt displays a message, it also displays some message header
fiels ('From:', 'To:' and etc.). But I cannot find out, where I can
configure what field will be displayed. For example, I want to see
'X-Mailer' field if it present.
Re: Message header fields displayed in viewer
On Thu, May 07, 2009 at 03:45:40PM +0400, Andrey Zhidenkov wrote:
When mutt displays a message, it also displays some message header
fiels ('From:', 'To:' and etc.). But I cannot find out, where I can
configure what field will be displayed. For example, I want to see
'X-Mailer' field if it present.
you can use the ignore and unignore directives for that. i have the
following in my .muttrc:
ignore *
unignore Date: From: Subject: To: User-Agent: X-Mailer: Cc: Bcc:
see man muttrc for details.
HTH
--
Joost Kremers
Life has its moments
Re: Message header fields displayed in viewer
On Thu, May 07, 2009 at 01:52:26PM +0200, Joost Kremers wrote:
On Thu, May 07, 2009 at 03:45:40PM +0400, Andrey Zhidenkov wrote:
When mutt displays a message, it also displays some message header
fiels ('From:', 'To:' and etc.). But I cannot find out, where I can
configure what field will be displayed. For example, I want to see
'X-Mailer' field if it present.
you can use the ignore and unignore directives for that. i have the
following in my .muttrc:
ignore *
unignore Date: From: Subject: To: User-Agent: X-Mailer: Cc: Bcc:
see man muttrc for details.
HTH
It works, thank you ;)
--
Joost Kremers
Life has its moments
Re: Sorting incoming mail by domain
I started with the idea I could configure mutt to accomplish the goal I describe below, but I'm not sure I can. Why not? I retrieve mail with fetchmail, which I have poll both mail servers. And it's delivered to different mail folders? That's the problem. While I can tell mutt to read the mail in a specific mail folder, I need to somehow to send mail addressed to a particular domain into that folder in the first place. I suppose I need to turn to procmail for that. Haines Brown
Re: Sorting incoming mail by domain
Hi, * Haines Brown wrote: That's the problem. While I can tell mutt to read the mail in a specific mail folder, I need to somehow to send mail addressed to a particular domain into that folder in the first place. I suppose I need to turn to procmail for that. Yes. Or really ugly folder-hooks that do sorting for you from within mutt) but these are a pain to write and debug/test. Rocco
Re: Sorting incoming mail by domain
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, May 7 at 09:14 AM, quoth Haines Brown: I retrieve mail with fetchmail, which I have poll both mail servers. And it's delivered to different mail folders? That's the problem. While I can tell mutt to read the mail in a specific mail folder, I need to somehow to send mail addressed to a particular domain into that folder in the first place. I suppose I need to turn to procmail for that. That's one way, sure. Or maildrop. Or, if you use maildir, you can just use two instances of fetchmail (one for each server) that uses safecat to deliver messages to each location. Email is like perl; there's almost always more than one way to do it. ~Kyle - -- This job of playing God is a little too big for me. Nevertheless, someone has to do it, so I'll try my best to fake it. -- Larry Wall -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkoC6FgACgkQBkIOoMqOI166fQCfb1ttxxq4MGvtaIhbauXryQts vDAAmgMUVMKDTdZTTghrY2TltQQOsg4L =QKFx -END PGP SIGNATURE-
Re: Mailbox is unchanged
On 2009-05-07 13:05:09, Rocco Rutte wrote: Please read: http://dev.mutt.org/hg/mutt/raw-file/tip/UPDATING when updating mutt. It lists incompatible changes during the development cycle. There you'll find a note about the default value for $move having changed to no so mutt no longer will move mails by default (or ask). Maybe 'set move' in .muttrc does help? Thank you! That got it. I didn't even know UPDATING existed. I'll remember to check that in future..
Set separate colors within mini-index
I was wondering if it is possible to set separate colors for the mini-index. I find the coloring of the mini-index distracting, and I would like to make it monochrome, with perhaps the current highlighted message as brightblack. Is this possible? -- Eric Patton
Re: folder-hook commands
* Michael Tatge schrieb: * On Wed, May 06, 2009 03:33PM +0200 Alex Huth (alex.h...@alice-dsl.net) muttered: folder-hook . 'set sort=reverse-date-received' folder-hook =freebsd-current 'set sort=threads' folder-hook =freebsd-acpi 'source ~/.mutt/defaults.maillist' Now i get the reverse sort as default, threads in freebsd-current and the error unknown command for freebsd-acpi. All folder-hooks now have valid syntax good. It seems that source is the problem. Yes But if this is a unknown command in folder-hooks, how can i set multiple values for a folder? It's not the source command that's the problem. Lost likely there an error in the sourced file. So check ~/.mutt/defaults.maillist for errors. HTH, Michael -- Linux is not user-friendly. It _is_ user-friendly. It is not ignorant-friendly and idiot-friendly. -- Seen somewhere on the net PGP-Key-ID: 0xDC1A44DD Jabber: init...@amessage.de Thanks for the help and the patience, that was the problem. In the sourced file was a space after the =. Alex
Re: Set separate colors within mini-index
* On Thu, May 07, 2009 11:02AM -0300 Eric Patton (epat...@nrcan.gc.ca) muttered: I was wondering if it is possible to set separate colors for the mini-index. I find the coloring of the mini-index distracting, and I would like to make it monochrome, with perhaps the current highlighted message as brightblack. Mutt doesn't do default colors. If you have those they come from your distro. /etc/Muttrc et al. uncolor index * in your own ~/.muttrc will get rid of those. HTH, Michael -- To err is human -- to blame it on a computer is even more so. PGP-Key-ID: 0xDC1A44DD Jabber: init...@amessage.de
Re: Sorting incoming mail by domain
Kyle, I've got a lot to learn about mutt :-(. I guess the most straightforward procedure would be to rely on procmail to direct incoming mail to differet inboxes that rmail and mutt can access. You were kind to reply, but your message starts with the set of lines below. Were you trying to tell me something? I don't have a public key. Are you saying that I really need one? [-- PGP output follows (current time: Thu 07 May 2009 01:16:12 PM EDT) --] gpg: failed to create temporary file `/home/brownh/.gnupg/.#lk0x8116a58.teufel.14872': Permission denied gpg: keyblock resource `/home/brownh/.gnupg/secring.gpg': general error ... gpg: Can't check signature: public key not found [-- End of PGP output --] And then I go to reply to your message within mutt, and my reply is aborted when an editor should show up. So I had to retreat to rmail for this reply. To save a message in mutt, if I hit the s key I'm prompted for a mailbox. However I'm used to saving messages as a plain text that I can name and put into a default directory, and if I page back to use the same saveAs... name, the message is appended to the previous one with the same name. As best I can make out, that is done with save-hook, I suppose, but not sure how to call that function. Thanks, Haines Brown
Re: Set separate colors within mini-index
Michael Tatge wrote: * On Thu, May 07, 2009 11:02AM -0300 Eric Patton (epat...@nrcan.gc.ca) muttered: I was wondering if it is possible to set separate colors for the mini-index. I find the coloring of the mini-index distracting, and I would like to make it monochrome, with perhaps the current highlighted message as brightblack. Mutt doesn't do default colors. If you have those they come from your distro. /etc/Muttrc et al. uncolor index * in your own ~/.muttrc will get rid of those. But will I still be able to maintain colors within the pager? To be clear, I was looking for a colored index, colored pager, but colorless (monochrome) mini-index. Thanks, -- Eric Patton
Re: Sorting incoming mail by domain
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, May 7 at 01:31 PM, quoth Haines Brown: I guess the most straightforward procedure would be to rely on procmail to direct incoming mail to differet inboxes that rmail and mutt can access. Probably, yup. You were kind to reply, but your message starts with the set of lines below. No, my message actually *doesn't* start with those lines. Those are something that your mutt displayed because it tried to verify my PGP signature. I use PGP (or, more specifically, GnuPG) to sign all of my messages. Since you don't have gpg set up properly, gpg was unable to verify my signature, and that's essentially what it's telling you. If you don't like seeing that junk at the top of messages, you should either set up gpg correctly OR you should change your mutt configuration so that it doesn't attempt to verify all signatures (e.g. set crypt_verify_sig=no). And then I go to reply to your message within mutt, and my reply is aborted when an editor should show up. So I had to retreat to rmail for this reply. That happened for the same reason: you have told mutt that it *must* verify pgp signatures, but then you didn't set up gpg so that mutt *could*. Either don't tell mutt that it must verify pgp signatures OR set up gpg so that it can do as you've told it. Put another way, you've essentially placed mutt in a round room (i.e. a computer without gpg set up properly) and told it whenever a message with a signature arrives, go stand in the corner (i.e. verify that signature). My message had a signature, and so mutt went crazy trying to find a corner to stand in. Of course, since it's in a round room, it failed miserably. So, either put mutt in a room with a corner (e.g. set up gpg correctly) OR don't tell mutt to stand in a corner whenever messages with signatures show up (e.g. set crypt_verify_sig=no). Does that make sense? To save a message in mutt, if I hit the s key I'm prompted for a mailbox. Yup - that's how you can move messages between folders. However I'm used to saving messages as a plain text that I can name and put into a default directory, Why would you do that? and if I page back to use the same saveAs... name, the message is appended to the previous one with the same name. ...right... because you've essentially told mutt copy the message into the mailbox that I specify by name, and delete the version of the message in the current mailbox. When you do that, mutt has to figure out what kind of mailbox you've told it to copy the message into. By giving it the name of a file that already exists, mutt is forced to assume that it's saving the message into an mbox-style mailbox, and so must append the message to the end of that file. As best I can make out, that is done with save-hook, I suppose, but not sure how to call that function. I think you're confused; save-hook has nothing to do with this. What are you trying to accomplish by saving messages as text files? And why are you trying to tell mutt to save them all with the same name? It sounds like you have some rather unusual backup or archive scheme that you're trying to adhere to, and my bet is that there is a MUCH easier way to do the same thing. If you explain what it is that you're trying to accomplish with this default folder of text files, maybe we can help. ~Kyle - -- I created a cron job to remind me of the Alamo. -- Arun Rodrigues -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkoDMCUACgkQBkIOoMqOI168+ACfQlcd65MHYUe6oyBz5srj03E/ uYQAoNlHfqW8BVPrYZcGl2OdjY9sTSUW =CDMj -END PGP SIGNATURE-
Re: Sorting incoming mail by domain
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, May 7 at 05:00 PM, quoth Haines Brown: So, either put mutt in a room with a corner (e.g. set up gpg correctly) OR don't tell mutt to stand in a corner whenever messages with signatures show up (e.g. set crypt_verify_sig=no). Does that make sense? Yes, it sure does! Had no idea. :) For what it's worth, I think mutt's default setting for crypt_verify_sig is yes, and that's probably not a great default, for precisely the reason that it can end up confusing people who didn't expect mutt to verify PGP signatures. However I'm used to saving messages as a plain text that I can name and put into a default directory, Why would you do that? Good question. Perhaps if I try an answer, you might tell me I'm just making things unecessarly difficult for myself. Keep in mind I still have habits left over from VAX and DOS. With any luck, things have gotten easier since then! I use email primarily to obtain text and documents from one source that I store in a very large and complex directory tree (perhaps several thousand directories) by using a file manager to move them where they are dumpted to their ultimate location. These documents need a unique name to identify their location for sorting, to give some idea of their content, and a date (other than the date the file created). Hmm. Okay, I have a better idea of *what* you're doing, but still not *why* you're doing it. Is this large and complex directory tree convenient for some important piece of software? I mean, based on what you've said so far, I can only assume that your real goal here is that you want to be able to search and find your email quickly, right? And then, once you've found them, you want to read them with some piece of software... perhaps a text editor, perhaps something like mutt (I assume that mutt's display of email is sufficient for your needs?). The way this is *usually* done is to keep all your messages in a single mailbox (or divided among several, if that's more convenient), and then use search functions to find what you want. For example, in mutt, if all my messages are in a single mailbox, I can easily and quickly show only those messages that contain the word foo in the subject by using the limit command (which is, by default, triggered by pressing esc-L) with a so-called simple pattern that looks like this: ~s foo Or, if I want to see a list of messages received the day before Christmas in the year 2000, I use a pattern like this: ~r 24/12/2000. It's actually quite fast, even with very large collections of messages. What are you trying to accomplish by saving messages as text files? And why are you trying to tell mutt to save them all with the same name? Actually, I may simply be confused The s command prompts me for a mailbox: Save to mailbox=name of sender. However, I find this does not create a folder name of sender, but instead a file with that name. So I may not have a problem after all. What's happening there is that mutt guesses a default mailbox name to use based on the sender (you can change how mutt guesses by using save-hooks (that's what they're for)). Once you hit return to accept the name (or once you type in your own file name) mutt checks to see whether a mailbox by that name exists yet or not. If a mailbox by that name does not yet exist (which is what's happening), mutt creates the mailbox. It creates a mailbox based on the $mbox_type setting... which is a poorly named setting, but essentially it tells mutt what type of mailbox to create here. The default type is an mbox mailbox. An mbox mailbox is, simply, a text file containing a bunch of messages one after another. (There are subtle details that make it a bit more complicated, because mbox needs to be able to store multiple messages in a single file, but that's the central idea.) If there's only one message in the mbox file, it looks like it's just the raw text version of that message. There are several other types of mailbox formats that mutt supports, including MMDF, MH, and Maildir. Maildir is the most common alternative to mbox---the other two seem to be on the way out in terms of popularity. All three of these others are *folders* that have an internal structure specific to holding mail files. For example, a Maildir file contains three subfolders: cur, new, and tmp. Most of the time, all the actual messages in a Maildir mailbox are stored as individual files within the cur subfolder (the new and tmp folders are primarily used for delivering new messages to the Maildir quickly and safely). That's probably more information than you needed, but maybe that helps you understand why mutt is doing what it's doing. My original question was how to handle mail from one server with rmail and mail from another with mutt, and I gather procmail is my friend here. Yup - sorry to go too far off topic... but
Re: Sorting incoming mail by domain
So, either put mutt in a room with a corner (e.g. set up gpg correctly) OR don't tell mutt to stand in a corner whenever messages with signatures show up (e.g. set crypt_verify_sig=no). Does that make sense? Yes, it sure does! Had no idea. However I'm used to saving messages as a plain text that I can name and put into a default directory, Why would you do that? Good question. Perhaps if I try an answer, you might tell me I'm just making things unecessarly difficult for myself. Keep in mind I still have habits left over from VAX and DOS. I use email primarily to obtain text and documents from one source that I store in a very large and complex directory tree (perhaps several thousand directories) by using a file manager to move them where they are dumpted to their ultimate location. These documents need a unique name to identify their location for sorting, to give some idea of their content, and a date (other than the date the file created). What are you trying to accomplish by saving messages as text files? And why are you trying to tell mutt to save them all with the same name? Actually, I may simply be confused The s command prompts me for a mailbox: Save to mailbox=name of sender. However, I find this does not create a folder name of sender, but instead a file with that name. So I may not have a problem after all. My original question was how to handle mail from one server with rmail and mail from another with mutt, and I gather procmail is my friend here. Haines Brown
Re: Set separate colors within mini-index
* On Thu, May 07, 2009 02:49PM -0300 Eric Patton (epat...@nrcan.gc.ca) muttered: Mutt doesn't do default colors. If you have those they come from your distro. /etc/Muttrc et al. uncolor index * in your own ~/.muttrc will get rid of those. But will I still be able to maintain colors within the pager? To be clear, I was looking for a colored index, colored pager, but colorless (monochrome) mini-index. If by mini-index you mean pager_index_lines. Then no, the mini-index is what you see in the index. No way to get different colors for that. HTH, Michael -- * gb notes that fdisk thinks his cdrom can store one terabyte -- Seen on #Linux PGP-Key-ID: 0xDC1A44DD Jabber: init...@amessage.de
Re: Sorting incoming mail by domain
On Thu, May 7, 2009 at 10:31, Haines Brown To save a message in mutt, if I hit the s key I'm prompted for a mailbox. However I'm used to saving messages as a plain text I was super confused on this same issue for a while. Every so often i need a plain text copy of an email with headers and everything. Just hit s, and give a path. It'll save just fine. It says it's saving as a mailbox, because it is. Just so happens mbox format mailbox is a bunch of plain text emails appended in a single file. Also, you'll note the default behaviour of s is more like moving, so it'll mark the message for deletion. Just remove the delete flag. I'm sure you can macro s to behave more like a copy command. -- jake
Re: wrong charset
Hi, Sorry for the delay, but for some reason I didn't get the answer to my post in my email. On Monday, May 4 at 05:05 PM, quoth Luis A. Florit: I use a ISO-8859-1 encoded xterm in maemo, but :set ?charset gives me charset=utf-8. Are you setting it in your config somewhere? (test it my running `mutt - -F /dev/null` and seeing what the value of $charset is there) utf-8. No mater what I do... But I have three charsets: $charset=//TRANSLIT ?charset=utf-8 In fact, it seems that I am not able to change that ?charset variable to ISO-8859-1. I tried setting by hand LANG, LC_ALL, LC_CTYPE to pt_BR and such, but no luck. No, pt_BR.ISO-8859-1 is not among the xterm locales. Okay, I think the first thing you need to do here (aside from ensure that you're not setting $charset manually somewhere) is to find out what locales your machine supports. Something like this will probably work: locale -a | grep '^pt_BR' Just pt_BR. But I don't want to change the default language, just the encoding. Whatever it outputs, those are the values your computer (currently) understands, and so those are the values that LANG or the LC_* variables can be set to. I see. But even if I set LC_ALL=pt_BR, I get the messages in Portuguese but the encoding in UTF-8. Exactly the opposite that I want. It's possible that if you really want your xterm to only display ISO-8859-1 characters, you may have to install the right character sets (how to do this is often distro-dependent). But my xterm works perfectly with ISO-8859-1, for example, vim does. That is not the problem, but that mutt just does not want to understand the encoding. On the other hand, if your machine ALREADY correctly understands UTF8... go with it! UTF8 is far more capable than ISO-8859-1 or any other ISO charset. Several years ago I tried UTF-8, but the vast majority (I mean, almost 100%) of the emails/texts/etc I read/save are ISO-8859-1 (that are not correctly displayed in a UTF8 console). I don't need any of the non-ISO characters in UTF-8. I also tried setting charset, config_charset and assumed_charset to ISO-8859-1, in the beginning and end of .muttrc, with no luck... What do you mean no luck? Did mutt refuse to allow you to set an alternate $charset value? If the value of $charset got reset, then either the value is being reset by some other part of your configuration, or your mutt is broken. I can change at will the $charset, but that makes tésté yá appear as t\351st\351 y\341 instead of the correct tésté yá. The problem is that I cannot change the ?charset variable, that is fixed in utf-8. How can I change that? I think I can resume in two questions: 1) why ?charset=utf-8 if I am working in a ISO-8859-1 xterm? 2) why I am not able to change the ?charset by hand in .muttrc or manually with a :set command? Thanks a lot for your efforts (and Derek's)!!
Re: wrong charset
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, May 7 at 09:40 PM, quoth Luis A. Florit: On Monday, May 4 at 05:05 PM, quoth Luis A. Florit: I use a ISO-8859-1 encoded xterm in maemo, but :set ?charset gives me charset=utf-8. Are you setting it in your config somewhere? (test it my running `mutt - -F /dev/null` and seeing what the value of $charset is there) utf-8. No mater what I do... But I have three charsets: $charset=//TRANSLIT ?charset=utf-8 What? That doesn't make any sense. Are those two lines actually in your muttrc? I think at least part of the problem here is that you aren't understanding what ?charset means. The charset variable is almost always referred to as $charset, with the dollar sign. If you swap the dollar sign for a question mark, that's a way of telling mutt you want it to display the value of the variable. It's NOT a way to set the variable. In other words, set ?charset=us-ascii is completely bogus, and meaningless. In fact, it seems that I am not able to change that ?charset variable to ISO-8859-1. So, if, while running mutt, you execute the command: :set charset=iso-8859-1 What happens? Does an error get displayed? I tried setting by hand LANG, LC_ALL, LC_CTYPE to pt_BR and such, but no luck. No, pt_BR.ISO-8859-1 is not among the xterm locales. Okay, I think the first thing you need to do here (aside from ensure that you're not setting $charset manually somewhere) is to find out what locales your machine supports. Something like this will probably work: locale -a | grep '^pt_BR' Just pt_BR. But I don't want to change the default language, just the encoding. If pt_BR is the only pt_BR-related locale you have installed, then you're stuck with the default charset, whatever that happens to be. If you want access to other charsets (such as utf-8), you'll have to install additional locales (e.g. the locale named pt_BR.utf8). On debian, this can be done by using `dpkg-reconfigure locale`. I'm sure other distributions have similar means of installing/enabling additional locales. Whatever it outputs, those are the values your computer (currently) understands, and so those are the values that LANG or the LC_* variables can be set to. I see. But even if I set LC_ALL=pt_BR, I get the messages in Portuguese but the encoding in UTF-8. Exactly the opposite that I want. What do you mean the encoding in UTF-8? You mean the messages you receive are encoded in UTF-8? That's fine; it doesn't matter what the messages are encoded in, as long as mutt (and all the supporting libraries it uses) know what characters can be displayed, so that it can convert from the message's encoding to the correct encoding for display on your terminal. It's possible that if you really want your xterm to only display ISO-8859-1 characters, you may have to install the right character sets (how to do this is often distro-dependent). But my xterm works perfectly with ISO-8859-1, for example, vim does. That is not the problem, but that mutt just does not want to understand the encoding. Okay, we're over-using the term encoding here. Let's try and be clear about what's going on: 1. When you run mutt, it reports that the charset it thinks is appropriate is utf-8 2. Nothing you seem to do can convince mutt to avoid utf-8 It sounds like somewhere in your mutt config, you're setting $charset to be utf-8, and then attempting (perhaps with the wrong syntax) to set it to be something else. Mutt's generally pretty good at figuring out the right $charset value to use, if you leave it to its own devices. On the other hand, if your machine ALREADY correctly understands UTF8... go with it! UTF8 is far more capable than ISO-8859-1 or any other ISO charset. Several years ago I tried UTF-8, but the vast majority (I mean, almost 100%) of the emails/texts/etc I read/save are ISO-8859-1 (that are not correctly displayed in a UTF8 console). I don't need any of the non-ISO characters in UTF-8. This is probably not worth arguing about... BUT - ISO-8859-1 files *should* display properly on a UTF8 console. If it doesn't, then something (your terminal, your text reader, whatever) is broken. I think I can resume in two questions: 1) why ?charset=utf-8 if I am working in a ISO-8859-1 xterm? *Probably* because somewhere in your muttrc, you're setting $charset to utf-8. 2) why I am not able to change the ?charset by hand in .muttrc or manually with a :set command? Because ?charset isn't a variable you can set. Now, I admit, mutt isn't very clear in this respect, because it's unlike anything else. But charset is the name of the variable. $charset is usually the way it's referred to. However, since mutt doesn't have an echo command or anything similar, one of the developers (I don't know who) thought that a convenient way of displaying the current value of a variable would be to refer to it with a question mark. In other words
