MUTT Setup - Configuration Hints

This page gives you an abstract view of my setup for mutt. It also has some notes on basic use of commands which can not be found in the manual. But maybe they'll find their way in a Mutt User Manual...

NOTE: This assumes that your email setup is already working, that is the MTA (mail transfer agent) and MDA (mail delivery agent) can already exchange emails and deliver them to your mailbox.

[Note to Netscape people: From Mozilla to Mutt

Setup from scratch

OK, let's just start mutt on the command line (aka "shell"):
    $ mutt

Non-existing $maildir

The first kind of message you will see when starting mutt may be this one:
    /home/USER/Mail does not exist. Create it? ([y]/n):
This happens when your account "USER" is still quite new. Just answer with 'y' - and mutt will create the subdirectory "Mail" in your home directory.

Comment ["prompts"]: Mutt prompts you with "([y]/n)" - this means that the letter or string in square brackets (here: 'y') is the "default" answer; this answer will be accepted when you give an "empty" answer, ie when you ende the input by typing the ENTER or RETURN key.

All messages will now be stored in "folders" within this directory. (A "folder" can either be a file or a directory - but more about those formats later). By the way, the name of this directory can be changed in the setup file later using the "variable" "maildir". It's value is denoted in shell style as "$maildir".

Non-existing Mailbox ($MAIL)

After the initial startup, mutt tries to read in the mailbox. This file is indocated by the shell variable MAIL, and it's value is $MAIL.

If the mailbox does not exist yet then you may this error:

  /var/spool/mail/USER: No such file or directory (errno = 2
As mutt is a Mail User Agent it is not allowed to create the maibox, so let#s create one by sending yourself a mail. But first exit mutt using the "quit" command which should be bound to the key 'q'. (All commands can later be bound to other key if you like. But more about this later.)

Let's create the mailbox by sending yourself a mail:

    echo this is some text | mail $USER
Problems: The command "mail" might be an alias. If it is bound to, say, "pine" then this won't work as pine does not accept text from standard input ("stdin"). Also, the variable USER might not be set at all. Solution: Tell the admin to set USER for all default shell setups. And if mail is aliased, well, try /bin/mail instead. (And if /bin/mail does not exist on your system - tough luck. ;-)

If this went well then /var/spool/mail/USER should exist now. Start mutt again (from the shell). Both the $maildir and $MAIL should exist now - and you should have at least one mail in your mailbox.

Before we do *anything* yet, exist mutt again, BUT this time with command 'x' ("exit"). The "exit" command leaves mutt directly and without saving any changes at all.


Sven's Setup - Overview

My setup consists in these files: Why so many files? Well, I could put all files into one file, of course. But here at the university there are some people who share the setup with me. Their muttrc reads my muttrc.forall. (My own muttrc is a basic muttrc for all of them.)

As everyone is needs a setup for himself I let the muttrc sources (ie reads in using the command "source") the files ~/.muttrc.aliases and ~/.mutt.personal.

Comment ["source file"]: Mutt will complain when its executes a source command when the given file cannot be found. So when you use my setup and you have no mutt.aliases or .mutt.personal then mutt will complain on startup. But it is easy to create these files in your home directory with the UNIX command touch filename. Now that the files exist (though empty), mutt should startup without errors.

Would be nice, though, if mut had a command "source!" (note the '!') that does not complain if the given file does not exist.

Sysadmin Setup

If you are the admin of a system then you can arrange the files differently, of course. In this case you would install something like my muttrc.forall as the global setup file as /etc/Muttrc.

If the /etc/Muttrc exists then it will be read by mutt when it starts; your own ~/.muttrc will be read after that.

User Setup

As a user you might want to keep all files in a subdirectory of its own, I suggest ~/.mutt. Then your ~/.mutt/muttrc will have to "source" All you need to adjust


The "attribution line" (or "attribution" for short) is the line that gives information about the author of the cited text.

My preferred attribution gives info about the NAME+ADRESS of the author and (if there is still some space left n the line) info about the date+time of the preceding message:

* FirstName LastName <Address> [yymmdd hh:mm]: > quoted text quoted text quoted text > quoted text quoted text quoted text > quoted text quoted text quoted text As this text has become a little longer I have made it an extra page:

    Miscellaneous Hints

    doc/manual.txt aka "The Manual": Read the chapter on regular expressions carefully! It pays off to know these. Also, print out the section on "Patterns". This is very useful for use with the "limit" command.

    "New Mail?" see multiple inboxes

    Reorder Mails in folder: Q: Can you save the messages of the current folder in the current order?
    A: No - mutt does not write back the messages to the current folder in the order you have selected. However, it can write them in the current order to a *new* folder. So, tag all messages (tag + "all"), and then write them to a new folder (tag-prefix ';', "save" 's', ""). After you exit mutt you can rename the new folder to the old one, thus overwriting the old one with the new one.

    Double Mails, Mailbox Speedup:

    Reading/Sending News/Usenet:
    Those who have used Pine to send messages are probably also used to the medium Usenet. Before you ask - Mutt is *not* a newsreader. It was not meant to be a newsreader at all. We highly suggest that you use slrn as a newsreader. It is also text based, can be quite colorful, and does real threading. Many mutt users use slrn for Usenet, too, so there's a lot of support there. And many have extended mutt/slrn with features from the other program. That said, there is a patch for mutt that allows dealing with Usenet. But you have to apply this patch yourself. The patch was made by Vsevolod Volkov and is called "NNTP patch" as NNTP (Net News Transfer Protocol) is the protocol for exchanging messages on Usenet. The patch is available at and after you have applied the patch you need to recompile mutt with the option "--enable-nntp". And you should "set allow_8bit=yes" to your muttrc to prevent mutt from encoding text as quoted-printable as other newsreader do not have support for decoding such text.

    Viewing HTML attachments: Some mails come with "attachments", ie the mail is structured into several parts. Each part can be an encoded file (texts such as "README.txt" or "foo.doc", or pictures like "screenshot.gif", "photo.jpg", or "button.png"). The files in attachments usually have been created other programs and therefore need special programs to show them. The file $HOME/.mailcap tells mutt which program to use.

    Some attachments are a copy of webpage (written in HTML or XML), so it is only natural to use a (text) web browser to show them to you. You could save the attachment to a file, say "foo.html" (but mutt should know which filename to use if the encoding was done properly), and then run your browser on it (let's pretend you are using the text browser "links"):

        links foo.html
    There is a simpler way, however: *Pipe* the attachment to the program: First use the command "pipe-message" ('|') and you'll get the prompt "Pipe to:"; now enter the program name, "links"
    Some parts of email can be HTML data; if the whole body of the email is text/html then you'll see such a line in the header:
    .. for muttrc:
      auto_view text/html
    Attachments (and mail bodies ind Add these lines to your $HOME/.mailcap file:
      # use "lynx" to render HTML files:
      # text/html; w3m -dump %s; nametemplate=%s.html; copiousoutput
      text/html       ; lynx -dump -force_html %s ; copiousoutput
      text/htm        ; lynx -dump -force_html %s ; copiousoutput
      message/html    ; lynx -dump -force_html %s ; copiousoutput
      message/htm     ; lynx -dump -force_html %s ; copiousoutput
    Or use "mutt_netscape":
      text/html; mutt_netscape %s; test=RunningX

    the script "mutt_netscape" tries to connect to an existing netscape instance and if that fails it starts a new netscape instance. The script was written by Gary Johnson and is available from:

    Administrators might add these lines to one of the system mailcap files; those files are given by the manual:


    From Mozilla to Mutt

    Mutt for Netscape users

    This is for Netscape users on Unix systems.

    Switching from Mozilla to mutt means to switch from a web browser who also understands email to a an emailer which does not understand the web at all. So say goodbye to viewing all those colorful ads in GIF - adn say hello to reading the *text* in emails.

    What do you gain from that switch? Well, the biggest gain is SPEED. (On my machine mutt opens a flder with 40,000+ messages and sorts them for threading in less than a minute.) With Mutt you can "limit" the view of the index to a subset of messages using patterns with regular expressions; searches in the body are also possible. You can jump to messages by index number which is easy for those who know how to type numbers. ;-) There are commands to jump to the first/last messages on the current windows, and jum to the middle one; this makes movements to messages a lot faster. You can also tag messages by patterns and apply commands to all tagged mails; deleting a bunch of messages is easy with that method. Mutt offers all commands via keys and allows you to bind any command to the key that you prefer to use. You can also define command sequences (macros) and bind them to a single key. With mutt you can also define the header lines you want to see and their order, too. You can colorize mails in the index and the text in the mail body. Selection is mails uses regex and is really powerful. Mutt can answer by the address you were addressed by and it will show the name of senders as you prefer it - even when no name is given in the sender's From: line. And apart from replying to the sendenr or all recipients you can alsofinally reply to the mailing list address. Mutt can do a lot more - and it does not crash as often as Mozilla. ;-)

    Also, mutt can be used over a terminal connection. it's just text, right? and as someone said on the mutt mailing list: "Ever tried running Netscape on a remote machine displaying on the local machine? I've seen paint dry faster." hehe :-)

    Now, this might not look like a serious issue - but imagine yourself being elsewhere at a computer which does not have Netscape installed. What then? Can you log in to a remote machine and start from there? If you can then, well, you're in for s slow mail experience.

    One more thing: Mutt supports standards properly. Talk about digital signature (MIME/PGP - RFC2015).

    But switching will take some work. Mutt will not read in Mozilla's address book, display your folders as a tree, or import some addresses from within a message by a mouse click.

    But does this make mutt a bad program? - No.

    Think about it: Would you want mutt to be able to import addresses from arbitrary mailers with different formats? If mutt did this then its code would certainly grow and its maintenance would depend on other mailers. the developers would have to keep updating mutt's code to keep up with their changes, rather than improving its speed and its mailing features.

    That's why mutt leaves some tasks to external programs, eg the editing is done with your favorite editor, the conversion of aliases sis done by a script, the extraction of URLs is done with the utility "urlview", and the retrieval of addresses from an LDAP server can be done with any kind of tool you prefer. Remember the Unix concept: one job, one tool.

    And some people simply prefer FREE SOFTWARE. :-)

    "But with GUI Mailers you can open several messages in different windows at the same time and then read or reply to them." "Well, you can start mutt on the same mailbox many times and in each windows write a reply to different messages."

    "With GUI Mailer I can split the window and look at different parts of the same message." "Use an editor like Vim and you'll have split windows, too."

    Here we go... When Netscape "takes your mailbox" then it creates the directory $HOME/nsmail/ and it creates these files within:
    $ ls -l ~/nsmail
    total 0
    -rw-------   1 guckes   emailer         0 Feb  9  1999 Drafts
    -rw-------   1 guckes   emailer         0 Feb  9  1999 Inbox
    -rw-------   1 guckes   emailer         0 Feb  9  1999 Sent
    -rw-------   1 guckes   emailer         0 Aug  5  1999 Templates
    -rw-------   1 guckes   emailer         0 Feb  9  1999 Trash
    -rw-------   1 guckes   emailer         0 Feb  9  1999 Unsent Messages
    Mutt will look at the directory $HOME/Mail by default when you use the "change-folder" command. But if this directory does not exist yet then you can create a symbolic link from Mail to nsmail with this:
        $ ln -s $HOME/nsmail $HOME/Mail
    If your shell understands the abbreviation ~ for $HOME then this command gets as simple as that:
        $ ln -s ~/nsmail ~/Mail
    You can start mutt directly on some folder by setting the MAIL variable to that file (or directory in the case of Maildir folders).

    Here is an example on starting mutt on the "Inbox" created by Netscape:

      $ MAIL=~/nsmail/Inbox mutt
    This is more or less the same as this:
      $ mutt -f ~/nsmail/Inbox
    Mutt look at ~/Mail by default; with the symbolic link this is the same as ~/nsmail. So when you look at the folders in "$folder" then you'll see the files in ~/nsmail.


    Converts a mutt setup file to HTML.
    Author: Dave Pearson


    The idea about "limiting" is to look at a subset of the current index, ie to select a bunch of messages which "match" a given "pattern".

    You basically type 'l' ("ell") to invoke the "limit" command, type in some "pattern" - and, presto, less messages in the index. This makes finding messages much faster. Let mutt do the searching for you!

    Example: "limit" by pattern "~N".

    When looking at "mailboxes" (folders which receive incoming mail automatically) I usually want to look at the new stuff first. Typing in the pattern "~N" and typing ENTER, too, takes too much time. So I have made this a macro and bound it to ",n":

    macro index ,n <limit>~N\n Why ",n"? Well, I can use this on both Krautboards (keyboards with German layout) and QWERTYs (US type keyboards). Only two keystrokes - and no SHIFT required. :-)

    Anyway, look at the section about "Patterns" (currently with mutt-1.2.5 this is the section "4.2"), and print out the list of patterns. Keep it handy - you maybe need it to get used to its language.

    More Examples:

      ~N ! ~p
    Read this pattern like this: "New mails which are not personal", Non-personal mails are those which do not contain *any* of your email addresses in either TO: or CC: lines.

    But how does mutt know which addresses are yours? Well, this requires configuration of the variable "alternates" (dont ask - it's a historic variable name from ELM).

    Now, this pattern will select two kinds of messages:

    1. Mails to mailinglists. Your addresses is known by the maillist software and is this *not* shown in the header.
    2. SPAM. Your address was probably used on some BCC line.
    In case your mail filter was set up properly then all the maillist messages should have been filtered out already. Which leaves *possible* spam.

    I usually delete the SPAM form my mailbox first. Then I look at the new mails. After reading a new mail I type 'N' to mark it as new again, and possibly with 'F' which sets a "flag" on it (shown as '!' in the index); this will remind me to reply to these mails first.

    After reading the new mails I reply to the flagged mails first. I therefore select thes mails only by "limiting the lindex" to the pattern "~F". Again, I use a macro for that:

    macro index ,f <limit>~F\n Quite easy, isn't it?

    Moving old messages

    You can also "remove" old messages from a folder using the "limit":

    Here's an abstract on how to proceed: To select the messages use "limit" (l) and enter a "pattern". After selecting the messages simply use "tag-prefix" (;) and "delete-message" (d) to set the delete flag on them; after that you can "sync-mailbox" (^X) to get rid of them.

    If you are sure about the pattern you type in then you can use "delete-pattern" (D) right away to do this in one command.

    Caveat: I have seen quite some mails being sent with a false date on them - usually from DOS and Windows machines with a false date. So I suggest you simply "tag-pattern" (T) the messages and then "move" ("save", actually) them, using "tag-prefix" (;) and "save-message" (s), to some other folder first (eg "+trashcan" or "+DEVNULL") before deleting them from your disk.

    Format of a day:  DD/MM/YY --
    Example:          22/11/2001  22nd November 2001
    --- Absolute Dates
    "Date (exact)":
    Select all messages *on*      Jan 1st 2001:
      ~d 01/01/2001
    "From Date":
    Select all messages *since*   Jan 1st 2001:
      ~d 01/01/2001-
    "Unto Date":
    Select all messages *before*  Jan 1st 2001:
      ~d -01/01/2001
    "Date Range":
    Select all messages *between* (and including)
    Jan 1st 2001 and Apr 6th 2001:
      ~d 01/01/2001-06/04/2001
    "Date Range" *without* centuries:
    Select all messages *between* (and including)
    Dec 31st 2000 and Jan 1st 2001:
      ~d 31/12/00-01/01/01
    --- Relative Dates
    Use of "offsets" (years, months, weeks, days):
    Select all messages *within* the previous *year*:
      ~d <1y
    Select all messages *within* the previous nine *month*:
      ~d <9m
    Select all messages *within* the previous six *week*:
      ~d <6w
    Select all messages *within* the previous seven *days*:
      ~d <7d
    Note: You cannot do arithmetic with dates, ie you cannot mix absolute with relative dates. Would be nice though. Imagine:

      ~d (24/12/2000 + 1w)
    This will give you the message of last Xmas and the week after that. Nice, eh? Patch, anyone?

    Limit FAQs

    FAQ: Is there a simple way to refresh the index after a limit command? A: Yes - "limit" by pattern ".", "all", or "~A". Or use a pattern which no match. ;-) Then mutt will show all messages again.


      ~A              All       all messages
      ~b EXPR         body      messages which contain EXPR in the message body
      ~B EXPR                   messages which contain EXPR in the whole message
      ~c USER         cc:       messages carbon-copied to USER
      ~C EXPR         CC/TO     message is either to: or cc: EXPR
      ~D              Deleted   deleted messages
      ~d [MIN]-[MAX]  date:     messages with ``date-sent'' in a Date range
      ~E              expired
      ~e EXPR         emitter   ("Sender:")
      ~F              flagged
      ~f USER         From:     USER
      ~g                        PGP signed messages
      ~G                        PGP encrypted messages
      ~h EXPR         header    arbitrary header line!
      ~k              key       contains a PGP key
      ~i ID           id        Message-ID: ID
      ~L EXPR               message is either originated or received by EXPR
      ~l              list      "CC: list-address"
      ~m RANGE        ...
      ~n RANGE        number    "score" within given RANGE
      ~N              NEW       Flag 'N'
      ~O              OLD       "Status: O"
      ~p              private   "From: myself" (-> "alternates")
      ~P              Private   "TO:   myself" (-> "alternates")
      ~Q              replied   Flag 'r' is set
      ~r RANGE        received
      ~R              Read      (neither New nor Old)
      ~S              Superseded
      ~s SUBJECT      Subject   "Subject: SUBJECT"
      ~T              tagged    Flag 't' is set
      ~t USER         To:       "To: USER"
      ~U              unread    (either New or Old)
      ~v              "versteckt"  (within collapsed thread)
      ~x EXPR         ...       ("References:")
      ~z RANGE        siZe      size in bytes within RANGE
    Private messages: [...]

    "RANGE" is a range with a minimum and maximum number; either can be optional, and you can use it with

      ~m RANGE              message in the range MIN to MAX *)
      ~n RANGE              messages with a score in the range MIN to MAX *)
      ~r RANGE              messages with ``date-received'' in a Date range
      ~z RANGE              messages with a size in the range MIN to MAX *)
      10-20         10 to 20     (both values *included*)
      10-           at  least 10 (10 and up)
      10>           more than 10 (does not include 10)
        -20         up to 20     (includes 20)
        <20         at most 20   (does not include 20)

    list vs subscribe

    Many users did not understand the difference between the setup commands "list" and "subscribe". I cannot blame them - the description in the manual was not very clear (see the section on "Mailing Liste").

    Both commands tell mutt that an address is the address of a mailing list. This allows that you can reply to the *list* (instead to the sender of of the message) with the command "list-reply".

    Also, mutt will show an 'L' in in the folder index to indicate that the mail was sent via a mailing list (see variable "to_chars"):

       1234 N L 020406 Sven Guckes (42) why mailers need a list-reply command

    Both "lists listaddress" and "subscribe listaddress" give info on your subscription status. "subscribe listaddress" tells mutt that you *are* subscribed to the list.

    So the command "lists listaddress" means "listaddress is the address of a list and I am *not* subscribed to the list" - implicity asking for copies of messages.

    And "subscribe listaddress" means "listaddress is the address of a list and I *am* subscribed to the list" - thus asking to *not* send any copies of followups.

    Now, if "followup_to" is set (and it is set by default) mutt will add the header line "Mail-Followup-To:" on followups:

      Mail-Followup-To: Listaddress
    This tells other mutts that it is only required to send a mail to the *list* to tell you about it.

    But in the case of "lists Listaddress" mutt will add the line

      Mail-Followup-To: Listaddress, myself
    Other mutts will then automatically send both to the Listaddress *and* the address "myself".

    So when you send to a list you are not subscribed to then configure mutt with "lists Listaddress" to tell others about non-subscription status and to make them send a followup to both the list *and* yourself.

    Those who follow up to your mail (using either group-reply or list-reply) will send *both* to the list *and* to you - because you are not subscribed to the list and therefore will not get a copy of the followup via the list's distribution. Note that this requires "honor_followup_to" to be set.

    whew. i hope i have made this really clear by now.

    FAQ: Can I requests followups of followups on a mailing list to be sent to me, too? A: No. This would require that your address is also in the header of further followups. Let's assume that somebody else follows up to your message and requests followups to be sent to his personal address, too. Then both his and your address must be in the header. With further requests this would accumulate more and more address in the header. this could grow to an arbitrarily large number of addresses in the header - and would defeat the purpose of a mailing list: Distribution to many address - but only one address required to send to.

    Automatic Actions

    FAQ: Can mutt do this-or-that for me automatically? A: "No." Please think about it: Whenever you want mutt to do anything "automatically" then you are basically saying "I dont want mutt to be a 'user agent' - but I want mutt to be a 'daemon' or a 'filter'." Mutt is neither a daemon or a filter. It is a user agent. So it should do what *you* tell it to do - and interactively. Actions happen when *you* type commands on the keyboard.

    Think of it like this: Mutt is a dog which responds to your commands. When it "hears" a command it will do something. When you dont "give commands" then it will do nothing.

    You just dont expect a dog to fetch your mail automatically at night and also automatically eat the spam, now, do you? (Now, those of you who have a dog like this, would you please stop mailing me about it and rather let me know how I can teach my cats to clean the kitchen sink at night? thanks.)

    I hope you understand this little analogy. Then you will understand that mutt does not send away mails automatically, either. [Then again, I do wonder about some replies I get... has my cat been walking on the keyboard again?] Anyway, On the internet nobody knows you're a dog.

    My point is this: Use the right tool for the automatic jobs. You can use "cron" (crond+crontab) to execute (Unix) commands at some certain date/time. You can use a mail filter to handle *incoming* mail (distribute,change/filter,save,delete, or send it on).

    But please don't teach this little doggie tricks which you might regret. You can, of course, let mutt execute arbitrary commands on startup - but you may find that it deletes too many of your mails or saves them to folders in wrong places/directories.

    Furthermore, even if mutt did know how to do your stuff automatically it would have to be (re)started ("kicked") in some way. This would require some use of "cron", anyway. But that's where daemons come in. Let them handle your (incoming) mail - and give the dog a rest. (woof!)

    Redo? Reuse!

    using previous input

    Mutt does not have a "redo" command. So you cannot apply the last delete or save command to the current message. (Users of Vi might try the "dot command" in Mutt - no way. Sorry.)

    However, when using "change-folder" you can "reuse" the last used foldername by entering a dot (".") as the name. Therefore, when you get a prompt for a foldername the '.' stands for the previously used one.

    Pet peeve: Mutt does not show you the value of the previously used foldername; not even when you enter the dot. :-( Patch, anyone?

    MUTT also keep in mind the commands you have used on the command line. After switching to the command line (with ':') you can call back these commands with the arrows keys. Note that every entered command will be added to the "command line history" - even if it was pure nonsense. Unlike with shells you cannot delete mistyped commands from the command line history. And on exit from MUTT the history does not get saved in a file as with "bash" or "vim".



    You can't just background the viewer with adding an & in the mailcap entry: the process gives an exit value of 0 then and mutt deletes the temporary file before your viewer can read it (thus resulting in an error in the viewer).

    When viewing an attachment, mutt save the file into /tmp, then spawns the external viewer, and then when it gets control again, deletes the file from /tmp. A simplistic change to the mailcap like backgrounding the viewer with & will not work, cos what will happen is:

      mutt saves temp file
      mutt starts viewer in background and immediately gets control again
      mutt deletes temp file
      viewer tries to open file, fails badly

    So how about (viewer "%s"; sleep 1)& then? Or for the more creative..

        (mv "%s" $HOME/tmp/;
         viewer  $HOME/tmp/`basename %s`;
         rm      $HOME/tmp/`basename %s`)
        & while [ -f "%s" ] ;
        do cat /dev/null;

    Fetching Mails from a POP server

    Mutt understands the POP (Post Office Protocol) to fetch mail off a POP server - iff configured to do so (it's not the default).

    Check the mutt version info see whether your mutt binary was configured to "enable POP support":

    $ mutt -v | grep POP

    A plus sign means "configured *with* that code".

    If your mutt shows "-USE_POP" ("*without* POP support") then you must install a new version - or your own version.

    $ ./configure --enable-pop --prefix=$HOME

    Now, to get mails off a POP server you must at least specify the hostname of that server ("pop_host") and your username ("pop_user"), for example:

      set pop_host=""
      set pop_user=""

    Now press 'G' which issues the internal command "fetch-mail". Mutt will connect the pop server and "log in" as the specified user.

    Note that GMX requires you to specify your username with the full address as they offer free addresses for more than the domain, eg So there's and which just *might* be different persons. (but these addresses happen to belong to the same person ;-). Other POP servers might just require a user name like "joe", though.

    After Mutt has contacted the POP server it will ask Mutt for the password. If you have not supplied a password yet then Mutt will prompt you for it:

    If you find this prompt annoying then you can specify the password in your setup file, too:

      set pop_pass="DaS3kr1t"

    But I chose to not add my pop password into my setup files as they are on public display. And I dont want anyone elese to download the spam that gets sent to me. It's *my* spam. So there.

    Anyway, I suppose not everyone makes his setup files public. But if you think that your setup file is not public because it is not distributed via a web server then think again! If you forget about your "umask" then the permissions of your setup file just might be set so it is readable by others. And don't forget that it is readable by "root" anyway. So you might prefer entering the password only when it is requested by the pop server. It all depends on your grade of paranoia. ;-)

    Talking of paranoia - there are people who attack servers some servers define a different port for POP. Therefore the POP service *might* have been installed by the sysadmin on another port number - but that's quite rare. But if this is the case then you can set a different one with eg "set pop_port=1234". (is port 1234 taken by anything? gotta check that..) Again, you can adjust mutt to such a situation. Try this with other mailers! ;-)

    The variable "pop_last" supposedly makes mutt retrieve only the new mails since you last accessed the server. However, this does not seem to work with my pop server. If this does nto work for you, either, then I recommend you install the program "fetchmail" to retrieve mails.

    Note that "fetchmail" does not replace the internal "fetch-mail" command, but is a completely independent and *external* program. If you don't want to exit or suspend mutt for using "fetchmail" then you can make 'G' a macro which invokes the external fetchmail:

        macro index G "!fetchmail\n"
        macro pager G "!fetchmail\n"

    The '!' calls a subshell which simply starts fetchmail. (Yes, this is a really simply macro, isn't it?) However, mutt does not pass any of the pop variables to the external fetchmail, so you need a config file for fetchmail:

      poll proto pop3 username password DaS3kr1t

    This setup translates to: Poll the server "" using the protocoll "pop3", login in with username "" and identify with the password "DaS3kr1t".

    Mind you, mails retrieved from within mutt are placed into the $spoolfile directly and therefore do *not* get filtered by your mail filter. So if you want your mail filter to be applied then it is a good idea to use fetchmail because it allows you to specify, say, procmail as the MDA (mail delivery agent):

    You can also start up mutt and fetch mails off a POP server diretcly like this:

      mutt -f pop://user@host

    This should connect you to a POP server directly. Apparently, this works, but I have not tried this yet.


    "Hooks" are "setup rules" which allow mutt to execute commands ie change settings.


    The "send-hook" is triggered when you send a mail. You can use it for these things:

    Set the signature when you send to "Dr Hook":
        send-hook 'set signature="~/.sig.drhook"'
    Note that the command is given in "ticks" as it has to be *one* part of the command. if the ticks were missing then mutt would parse the hook such that it sees "seT' as the command - and the rest is just additional stuff which does not fit the definition of the hook - and mutt would give you an error.

    OK, another example for you you here: The pattern "~l" stands for "(mailing) list"; use this and the send-hook to tell mutt to issue a command only when sending to a "known list".

        send-hook ~l  'set signature="~/.sig.infotage"'

    Hook Defaults

    However, when a hook is issued then the change will not be changed back when you finish sending to some address or when changing the folder. The change *will* remain!

    Therefore you will need an extra rule which gets triggered *every* time. And the pattern that matches always is "." - as in "any character". Such an extra rule is called a "default rule".

    Putting these two together you'll get:

        send-hook .   'set signature=""'
        send-hook ~l  'set signature="~/.sig.infotage"'
    The pattern could also simply match some email address, eg:
        send-hook    'set signature="~/.sig.guckes"'

    Mind you, order counts! All rules are being checked. So the last rule that matches "wins". Actually, it issues the last command; and its effect obviously "overrides" previous changes which have been made.

    Let's consider another example with signatures:
        send-hook .          'set signature="~/.signature"'
        send-hook @ldomain   'set signature="~/.sig.localsig"'
        send-hook foo@bar    'set signature="~/"'

    The first rule *always* matches, so the variable signature gets set the standard signature in file $HOME/.signature. Now, if you send your mail to someone in your own local domain ldomain. This gets overridden when your are sending your message to foo@bar - whether this address is in the local domain or not does not matter, of course.

    General Default Hook Setup

    You can remove hooks with "unhook" commands. But then you need to remember all the hooks you have set - and you must not miss any! This can quickly become too much to remember - especially when you have added hook "on the fly" (using the command line); remember: there is no command which shows all active hooks. one of these might change a setting which you simply forgot.

    Luckily, mutt has a command which removes all hooks: unhook * It is generally a good idea to start off the setup file with this.

      # remove all hooks:
      unhook *

    so all following hooks will be added anew. this is good when you want to change all settings when entering a new folder, eg a folder for sending to a mailing lists. (it can be quite embarrassing to leave a "funny" signature in mails to other lists or business partners..) it also helps when source muttrc from within mutt to test new settings.

    to be continued...

    Mutt and Procmail

    Let procmail generate correct "Lines:" header for use with Maildir format:

    :0 Bfh
    * H ?? !^Lines:
    * -1^0
    *  1^1 ^.*$
    | formail -A "Lines: $="

    This is just one "rule for procmail. of course there is more to setting up procmail - but this is described on other pages, eg Sven's procmail page.

    Maildir Support

    Sample setup for use with Maildir format:
    set    folder="~/Maildir"
    set      mbox="~/Maildir/read-mails/"
    set mbox_type="Maildir"
    set spoolfile=~/Maildir/inbox/

    When the MDA (eg procmail) delivers your mail to the directory/folder ~/Maildir then set MAIL=$HOME/Maildir/ in your shell setup. Then mutt will not attempt to use the default setting on most systems which usually points to /var/spool/mail/username.

    Advantages of Maildir

    i do not use Maildir, so as for experience with it I have to rely on other people who do use it.

    Someone I know uses Maildir to store mails as Listname/Number.$UID.$HOSTNAME, that is the file name includes his user id number and the name of the host. the advantage is that he can easily exchange mails between hosts using rsync that way. the disadvantage however is that he might get the same messages on different hosts and thus get duplicates.

    Maildir stores each mail in a separate file with a filename of unixtime.processid.hostname. Initially the mail goes eg. to listname/tmp/$filename, and if delivery was successful it goes to listname/new/$filename. As soon as the mailreader reads the file it goes to listname/new/$filename and $info is appended, where $info consists of R(eplied), S(een), T(rashed), D(rafted), F(lagged)."

    $PAGER - "builtin" vs external

    configuration of the builtin pager

    Mutt shows messages with the builtin pager by default. You can customize it to show header lines in their own color and also show text in the body in color.

    NOTE: header lines can only be shown in *one* color combination. while clored texts in the body can have an arbitrary length and therefore there can be more than one color combination in the same line. Colored text cannot span more than one line, however.

       color header red      black    date:
       color header white    red      from:
       color header white    blue     subject:
       color header green    black    cc:
       color header green    black    to:

    Technically, the colon in header lines must follow whitespace. Use quotes to add this space:

       color header red      black    "date: "
       color header white    red      "from: "
       color header white    blue     "subject: "
       color header green    black    "cc: "
       color header green    black    "to: "

    Some header lines *contain* "date" and "to:", eg "delivered-to:" and "resent-date:". so if you do not want to colorize those special lines then I suggest you "anchor" these strings at the beginning of the line:

       color header red      black    "^date: "
       color header white    red      "^from: "
       color header white    blue     "^subject: "
       color header green    black    "^cc: "
       color header green    black    "^to: "

    NOTE: I have set the background color explicitly here. However, you can also use "default" as a color name to make mutt use the default background/foreground color.

    paging around

    When you are reading a message with the builtin pager you eventually get to the last page of the message. Using the next-page command then makes MUTT skip to the first page of the next message. Some people dont like this however - so they'll have to set pager_stop to make the builtin pager stop and not proceed to the next message.

    key bindings and macros

    Many users find it annoying that you have to change back to the index to issue some commands. Well, many "index commands" are available in the pager, too, eg "bounce-message", "forward-message", "resend-message", starting a new "mail", sending on the current mail ("bounce/forward-message") and standard actions on the current mail such as "copy/delete/pipe/print/save-message" as well as updating the current folder ("sync-mailbox)" And you can jump to other messages relative to the current one using "next-new" and "parent-message". It's all there - just bind it to the key you want. NOTE: Not all commands are bound to a key by default - even though they are available!

    With the power of the macro command you can bind a sequence of commands to a single key. The commands are not restricted to the current menu. When you use the "exit" command then the macro can leave the current menu and continue in other menus. This gives access to all of MUTT's commands.

    Example: You want the key 'd' to set the delete flag on the current message but also to jump to the next message which still has the "New" flag. And you want this both for the 'd' key in the index as well as in the pager. This is how it will work:

      macro pager d '<exit><delete-message><next-new>'
      macro index d       '<delete-message><next-new>'

    Note that these definitions makes use of the command *names* rather than using a sequence of keys. This makes the definition independent of the current binding. When passing on macros *please* use this form of definition as otherwise a binding can interfere with other bindings and maybe even trigger an unconditional deletion of messages. :-(

    header lines - ignore and unignore

    You can choose the header lines you want to see - and the header lines you *dont* want to see.

    To select only the lines you want to see have the all ignored - and just let MUTT *unignore* the ones you are interested in:

      ignore *
      unignore from date subject to cc

    Mind you - the check is done by *substring* - so any header line containing "date" or "cc" will be shown with this kind of setting.

    So I suggest you add the final colon, too:

      ignore *
      unignore from: date: subject: to: cc:

    But this will still show lines like "resent-date:" and "apparently-to:". then again - maybe you want just that.

    So you might want to make sure by "anchoring" these lines to the start of the line, too:

      ignore *
      unignore ^from: ^date: ^subject: ^to: ^cc:

    OK, that's just a minimal example. But I'm sure you will want to see more headers. Personally, I suggest making the Reply-To header visible to see whether the sender requests the reply to be sent elsewhere. Now, you might think that you'll get to see this address anyway as soon as you will reply to the message - ok. However, some people might be sending from an unfamiliar address and you might know them by their address in the Reply-To line.

    Other header lines to show are for example "User-Agent" and "X-Mailer" which show the client program used to compose the mail. (mind you, not "sending" mail - that's the MTA!) so by unignoring these lines you'll know the fellow dog-owners. showing the "Message-ID" is required because some of those "other" mailers still cannot afford to identify with "X-Mailer". (ehem)

    sometimes you might want to see all header lines. use the command 'display-toggle-weed' ('h') to toggle between display of all header lines and the "weeded view".

    use of an external pager

    But you can choose a different pager, of course:

       set pager=less
       set pager=more
       set pager=most
       set pager=vim

    The advantage of the builtin pager is that it shows colored text (emails and URLs, quoted text and the signature) and that you can toggle the display of quoted text. And you can switch to other messages directly, issue mail commands (bounce+forward and reply/group-reply/list-reply) as well as extracting pgp keys to your keyring.

    However, handing on the data (copying, saving, piping) is possible with *all* those pagers. Isn't Unix great? (Eat your heart out, Windows users!)

    You might also find it an advantage that you cannot reply from within the pager. This somewhat avoids that newbies send replies accidentally.

    An advantage of Using "vim" as the pager is that you can select the text and write it to some temporary file. You can also filter the text internally or using the programs "fmt" and "par".

    The pager "most" allows coloring of predefined attributes, but you don't get to configure colors for arbitrary texts.

    Vim, however, allows colorization of arbitrary texts. In fast this is even mroe versatile than mutt's coloring as Vim allows recognition of texts spanning several lines. And hiding of quoted text should be possible with folding, too.

    Anyway, when using an external pager then mutt will prompt you after you have quit from that pager. If you don't like this prompting then you can turn it off:

       set prompt_after=no
    (to be continued..)


    When there is something wrong with your setup then you should first make sure which setup file is reponsible for the weird behaviour.

    First - test your mutt *without* *any* setup files. For this, use the startup option -n to prevent mutt from reading the /etc/Muttrc; and use the startup option -F to specify only /dev/null as the setup file; this file should certainly be empty and should add nothing to the default setup:

      echo "look, Ma - not setups files!"
      mutt -n -F /dev/null

    Leave out the -n if you want to test mutt only with /etc/Muttrc:

      mutt -F /dev/null
    If you need to test something on a special folder then specify that one with the startup option -f;
      mutt -F /dev/null   -f ~/strange_folder
      mutt -F /dev/null   -f ~/Mail/empty
      mutt -F /dev/null   -f /tmp/mutt.testfolder

    Remember that '+' is the abbreviation for $folder (by default that would be "~/Mail") so you can use this abbreviation on the command line, too:

      mutt -F /dev/null   -f +guckes


    Some problems with errors in the configuration files trigger error messages. Error messages are your friends! (well, sorta..) They can help you find an error in the sources.

    When reporting a problem then don't forget to capture all error messages and include them in your report. (-> use "script" or "screen" or copy&paste).

    Also, test your personal setup file on its own:

      mutt -F $HOME/.muttrc

    As for problems with viewing messges or their attachments - there might just be a problem with the mcailcap files, ie usually /etc/mailcap or $HOME/.mailcap. (There might be more mcailcap files involved - see the FILES section in the manual to mailcap.)

    Adding header lines with 'my_hdr'

    my_hdr Organization: Freie Universitaet Berlin

    No special characters (high-bit, eg umlauts) in headers! Only ASCII!

    A header which gets added frequently is the Reply-To header. Its purpose to redirect the reply to a *different* address.

    Some people however think it is cool to add a Reply-To all the time - even when it contains the same address as the the one in the From: line. this, of course, is completely redundant and just shows that the user did not understand its purpose.


      From: Chris Green <chris(at)>

    this is even worse than a redundant Reply-To: as the reply address does not contain the name. this result in the reply which contains *no* name in the address line - and that's an indication for spam usually. so the sender of this mail (hello, chris!) is *asking* for replies which look like spam. his mail filter then cannot know whether the sender is a spammer or a regular replier. he is thus limiting the ability of his filter to recognize spam. his fault. all his.

    the remedy, of course, is to remove redundant Reply-To headers. so easy.

    PGP and all that

    just some notes...

    Removing digital signatures from messages: In general, MUTT does *not* allow to remove the digital signature from messages. When you change to the attachment menu and use "delete-entry" ('d') on a PGP signature then you'll get the error message Deletion of attachments from PGP messages is unsupported. However, this is only the case for PGP signatures. An S/MIME signature *can* be removed that way. A future version of MUTT probably has to have a check for 'smime sigs", too.

    MUA or MTA problem?

    When sending of email fails then often it is not a problem with MUTT (the Mail User Agent aka MUA) but with the Mail *Transport* Agent (MTA).

    But how can you make sure whether it is an MTA problem?

    Configuring the MTA may require a lot of knowledge - and some more books. when you do not have the time to install an MTA on your machine or learn about configuring it then you can use a simple MTA to simply forward mails to an already configured system with a proper MTA.

    There are several reasons why you may not want to install or configure your MTA:

    so - which MTAs can you use?

    nullmailer and ssmtp.

    Now, if you do use an MTA like exim, postfix, qmail or sendmail then there are mailing lists to ask of course. and then there are these Usenet newsgroups:

    there are even special groups available in other languages:
    cz.comp.mail.sendmail   Diskuse o programu sendmail
    fr.comp.mail            Logiciels de messagerie electronique.
    han.comp.mail           E-mail system, config and reader issues.
    pl.comp.mail.mta        Mail Transfer Agents - konfigurowanie i administracja.
    si.comp.mail            ---

    Configuring the From: Line

    # Configuration of the From: line:
    set realname="Sven Guckes"
    set from=""
    set use_from  # create From: Header
    set envelope_from

    you can selectively adjust your From: line by using hooks. you can change it when you enter a new folder (folder-hook) or when sending to special addresses (send-hook), eg when sending to mailing lists or when sending to an official person or to a friend. (see Hooks)

    Aliases and all that

    When MUTT prompts you with "To:" to enter addresses then you can also enter aliases. On the input line you can also type TAB to call the alias menu. From the Alias Menu you can select addresses by tagging them with 't' (tag-entry) and when you leave the menu with 'q' (exit) then the tagged aliases will be added to the address line. Note that this applies to all address lines TO/CC/BCC/REPLY-TO!

    The Alias Menu also gives access to the command line so theoretically you can still ":source aliasfile" if your current setup does not give access to the aliases defined in the additional "aliasfile".

    Navigation in the Alias Menu allows to jump to an index number (just enter the number by typing digits) You can jump to the "first-entry" (=) or to the "last-entry" (*), scroll the list using '<' (previous-line) and '>' (next-line) and scroll by half a page with "half-up" ([) and "half-down" (]). And you can "search" within the list with '/'.

    Remember: Every menu has a help command which shows you all the current keybindings - usually with '?'.

    You can also delete entries from within the Alias Menu. So when you exit the menu and re-enter it (yes, just type TAB again) then they will be gone. But these entries won't be deleted from your setup file, of course. So next time you start up MUTT again you they will still be there.

    But if you don't want to leave your editor to make changes to your header lines then "set edit_hdrs" and MUTT will add the header to the temporary file for you to edit. You can then add the aliases to the address lines - and once you exit the editor mutt will reparse the header and expand the aliases it will find.


    Managing addresses is one of those things which are left to external programs. this saves space in mutt code and thus avoids bloat. and you'll get to choose your favourite management tool. just like chosing your favourite editor. fetaure! :-)

    there are several address management tools about. two of these are "addressbook" and "lbdb":

    addressbook aka abook

    big brother database (bbdb)

    little brother data base (lbdb)

    I'd write more about these - but I just cannot be bothered. after all i use my editor to add aliases to some file which is then sourced from my muttrc:

      source ~/.mutt.aliases

    As simple as that.

    BINDing Keys

    "Free Key Binding" is one of the most powerful features with all text based programs. It means that you can "bind" key (sequences) to command sequences. And you can finally "have it your way".

    MailLists without the Filter

    Not everyone who has a mail filter installed on his system will make use of it. The configuration for good filters usually requires the knowledge of regular expressions - and this can be a huge hindrance (if you *don't* know , that is ;-).

    So how can you follow your mailing list from your mailbox - without a filter sorting them into separate folders first?

    First off, it makes sense to "limit" the display to mails sent via a single mailing list. This is quite easy:

    Let's assume that one mailing list distributes the messages via "address1". So in the header you should see the line "To: address1" and/or "Cc: address1". Both cases can be caught with the pattern "~C address1". So that's what you should use as the "limit pattern". You can bind this to the sequence "#1" like this:

      macro index #1 "<limit>~C address1\n"

    Side question: "But what if the messages were BCCed to the list?" Well, a good list will never distribute messages that way but bounce them back to the sender. There are many good reasons why this is ok.

    You will then have to have a "selection macro" for each mailing list:

      macro index #1 "<limit>~C mutt-users\n"
      macro index #2 "<limit>~C mutt-dev\n"

    And after some reading you probably want to save the read mails to a mail folder. Again, a macro can help you here. First it "tags" all *read* mails sent via the maillist address - and then it will save all tagged mails to the special folder:

      macro index #s1 "<tag-pattern>~C mutt-users ! ~N\n<tag-prefix>"
      macro index #s2 "<tag-pattern>~C mutt-dev   ! ~N\n"lt;tag-prefix>

    "Do I have to set up a selection pattern and a save macro for each list?"
    No. But the alternative is always to type it in yourself - each time. ;-)

    "OK, but - that's such a lot of things to do.. Can't mutt *know* which mails belong to a mailing list and distribute them automatically?"
    No. There is a standard for identifying mails from a mailing list - but hardly any maillist makes use of it. And even if it did - you'll have to chose a mail folder yourself. (automizing this for everyone cannot be done.) You will have to do your own organizing here. This is your freedom of choice. Use it! If you want a company to make the decisions for you, well, then "mutt is not for you".

    "But there's got to be a simpler way!"
    Yes - use a mail filter to distribute the incoming mails into different folders (mailboxes) right away. Start up mutt with "mutt -y" to see the list of mailboxes. Use the "change-folder" command to switch between the folders. No need for selection or save macros at all.

    "But - can't it be made even *simpler*?

    Internal Language

    "MUTT needs an internal language!" That's the claim of many users. And, yes, "it would be nice". However, there are also some reasons against such an addition.

    Code bloat: The additional code makes mutt even bigger.

    Complete code change: An internal language would also require to change the parsing of setup files.

    Complexity: This adds to the complexity of the program and makes it even more difficult to use.

    Support: This needs more documentation and support. The mailing lists will get even more messages - especially from people who cannot or don't want to code themselves.

    Reordering a Folder/Mailbox

    > .. how can I re-order an existing mailbox file by date so that
    > the file itself changes, rather than doing it dynamically (and
    > slowly on a large mailbox) every time the mailbox is opened?
    Tag all messages and the save them to a new file (folder).
      T     tag-pattern
      .     all ("contains at least some character")
      ;     tag-prefix  (applies following command to all tagges messages)
      C     copy-message
      +NEW  foldername "NEW"
    The folder "NEW" (usually ~/Mail/NEW) should now
    contain all the messages in the current order.
    To change the order use 'o' ("sort-mailbox") -
    before copying/saving the messages to a new folder.


    Sick of signatures? Use a "display filter"!

    Mutt allows to insert an arbitrary filter program to change and delete text before the builtin pager shows you the messages. This allows to make changes which will please your eye.

    I am using the stream editor "sed" to make those changes.

       set display_filter="/bin/sed -f /path/file"

    Note: Both the program to be used as well as the file used by the filter program get explicit paths!

    MUTT will hand over the message to the display_filter and will display the output of the filter with the builtin pager:

      mutt          -> display_filter -> mutt pager
      sends message    makes changes     shows output

    The display_filter in this case is "sed". It makes use of the commands in "/path/file".

    I will only use just two kinds of commands here: substitution (aka "search&replace") and deletion.

    display_filter "sed" - substitutions

    The substitution works very much like in vi: the 's' at the beginning denotes a substitution; the following slashes delimit the search pattern ("foo") and the substitution pattern ("bar"); and the 'g' at the end says to replace *every* occurrence of foo with bar ("global substitution").


    You can easily come up with very simple substitutions which replace one word for another, for example:

    But that's not always useful.
    And the real power of substitutions
    lies in the *patterns*.
    Let me give you some other examples:
      s/^[%|] /> /

    This substitution fixes broken citation. Cited text should be quoted with ">_" - not because there is a law for it but because most programs do this and almost all program expect it for recognizing quoted text.

    The search pattern starts off with a '^' which "anchors" the search at the beginning of the line - and therefore no 'g' at the end is needed as there can be only one (maximum) match at most. The square brackets surround a list of characters which *can* be next - so it is *either* a '%' ("percent") *or* a '|' ("bar"). Following that is a space. So the search pattern looks for "%_" or "|_" (where '_' denotes a space) at the beginning of all lines. The replacement is ">_" - the standard quote indent string by which mutt (and many other programs) recognize quoted text.

    So this substitution fixes "broken" quoting. You do not have to change messages to fix the quoting. Instead, the display_filter fixes it for you on a copy - each time you view the message.

    Note that the command "toggle-quoting" ('T') will now recognize quoted text properly. But you could also adjust the variable "quote_regexp" as an alternative, of course.

    display_filter "sed" - Deletions

    One way to delete text is to substitute it by nothing:


    You can use this to delete complete lines containing some word "foo", too:


    However, this will merely *blank* delete - not delete it. This will just leave an empty line.

    SED also offers an easy way to *delete* lines containing "foo":


    Note: *All* lines that contain "foo" get deleted. Of course foo can be a pattern, for example:


    The '^' again is the anchor for the start of line - and the '$' denotes the end of the line. A line which has the end right after the start is, of course, an empty line. So in effect sed delete all empty line here.

    But this also deletes all empty lines between paragraphs - thus removing the distinction in paragraphs. And you might not want this at all.

    It is much more useful to delete a *block* of empty lines and just leave one of them. this, too, is easy - but more about this later.

    SED also offers to delete a *sequence* of lines easily:


    Both "firstline" and "lastline" can be regular expressions again.

      /^# /,/^$/d

    This will delete from some commented line (lines starts with a '#' ("hash")) unto the next empty line (start-of-line followed directly ny end-of-line). Note: The lines containing the patterns are deleted, too.

    Another command construct of SED is this:


    Here the exlamation mark means "do not delete the lines matching the first pattern", ie the lines containing "foo".


    Let's take a look at this command step-by-step:

    The dot ('.') is yet another "meta character", denoting *any* character - but exactly one character. Thus the pattern '.' represents every line which contains one character - whatever this character is. So would this match any line? No - this does not match an empty line. So "/./" matches all non-empty lines.

    And the pattern "/^$/" denotes all empty lines.

    When we put this together then the command reads thus:

    "Find non-empty lines followed by empty lines -
     and delete all but the non-empty lines."
    This means to delete only the empty lines.
    However, this leaves one empty line.


    Standards are wonderful. Everyone should have one!

    Every once in a while there is some talks about the "standards". This happens when people debate the use of "traditional pgp style" versus "MIME/PGP" as described with RFC2015. Or when people get fancy with the settings of attribution, indent_prefix, and sigdashes.

    A standard, however, is something you *must* follow - especially when you are the programmer of an email client which simply has to obey some of the standards such as RFCs.

    Not following the standards will inevitably lead to problems. Disobeying the rules of a protocol will most certainly lead to loss of data. Most of these problem can simply be avoided by simply following the rules as given with the standard.

    But what if you have better ideas? Well, please remember that computers do give you the freedom to write and use your own programs. If you can come up with something that is better than before then you can create your own protocols and use with your own creations. You can make the sources public and let other people participate. You can set up a website and write documentation about why your product is superior. And then you might create a new standard.

    But remember:
    Be liberal in what you accept - and conservative in what you send.

    This means that whenever you send

    You can send text without any line breaks, making each paragraph a very long line. You can use whatever technique to quote text that can be understood by other humans. And you can put your quoted text above, below and inside your own text. And still it is nice if other folks mailers can recognize the attribution, the quoted text, and your signature automatically as this helps them to colorize text, hide or even delete it. Therefore those "standards" should be obeyed whenever possible - to speed up reading and saving time.

    For those of you who prefer to give each message an "individual" feel rather than helping others for speedy reading of your message's content, well, you will be ignored.

    MIME Security with Pretty Good Privacy (PGP)
    Status of this Memo:
    This document specifies an Internet standards track protocol for the
    Internet community, and requests discussion and suggestions for improvements.

    bounce vs forward

    There are two different methods to send on a message: "bounce" and "forward". These two are different in concept - and many mailers only offer "forward". So please make use of "bounce" when this is all you need.

    Multiple Inboxes

    You already know that the value of the shell variable MAIL points to your mailbox.

       $ echo $MAIL

    So when you start mutt on the command line it will open $MAIL (usually that's /var/mail/$USERNAME).

    However, when you also make use of a mail filter which automatically distributes incoming mail to other folders then you want to check these from time to time, too. NOTE: These folder might reside in the same directory with the rest of the folders which do *not* receive mail via the filter - but only when you save mails to them. That's why there is a special name for folders which receive new mails automatically: inboxes or mailboxes.

    So $MAIL is *the* most special "inbox" there is. But there may be more - depending on your use of a mail filter.

    Mutt can check those mailboxes for you - but you have to tell mutt which mailboxes to check. There is an extra configuration command for this: mailboxes.


       mailboxes  ! +IN.MUTT +IN.SED +IN.VIM

    This tells mutt about four mailboxes:

    Here the '+' sign is the abbreviation for the directory which contains all your folders (this value is given by $folder, ie the value of the mutt variable "folder").

    Please note that $MAIL is the value of the *shell* variable MAIL while $folder is the value of *mutt's* internal variable "folder".

    Checking for New Mail

    OK, now that you have told mutt to watch some folders you may want to check those folders. Mutt can show in the status line you how many of your inboxes (ie folders which are used for incoming mail) have new mail. And it will show you

    [TODO: info on status line configuration with example]

    Use the command "change-folder" ('c') for this; mutt will prompt you for the first folder that contains new mail. Use the space key to choose the next one and accept the current one with RETURN.

    Mailboxes configuration Tips

    Give your mailboxes a prefix which indicates that they are inboxes. I use "IN." as the prefix so I can easily list them with ls ~/Mail/IN.*.

    If you don't like the prefix method then you could tell your filter to save all mail in folders which are stored in an extra directory, eg ~/Mail/Lists/.

    Anyway, in both cases (filename prefix or extra directory) you can use the backtick evaluation to read in all (or some) inboxes with a single command:

      mailboxes  `echo ~/Mail/IN.*`
      mailboxes  `echo ~/Mail/Lists/*`

    "Why can't I use 'mailboxes +*'?" Well, the mailboxes command does not expand parameters. So you will have to use the backtick expansion and the shell's parameter expansion to do this.

    Mutt Startup on Inbox Browser

    Once you have all inboxes declared to mutt you can switch to the "Mailboxes Browser" which shows all the "watched inboxes" in a nice menu. this menu can be sorted by date of last change, alphabetically ("by name"), by size of the folder - or "unsorted" in which trhe order is given by the order of the mailboxes commands in your setup files.

    You can also make mutt check all mailboxes for changes (it looks at the timestamp) by using the check-new command. This command does exist, however, it is not bound to any key by default. So you may want to do that:

      bind browser $ check-new

    This binding is similar to the binding of the sync-ailbox command in the index menu - it is bound to the dollar key. (we are all quite lazy in remembering key bindings in a way, aren't we? ;-)

    The list of mailboxes might become longer than your terminal has lines. And even though there are nice commands to jump around the menu (eg by index number etc) you might want to get rid of some mailboxes in the list. but here's the bad news now: there is no "unmailboxes" command to take away any entries from the list. sorry. if you feel bored then you can change the source, of course. don't forget to send in the patch to mutt-dev - thankyou!


    And for those of you who cannot remember the "-y" switch:

      $ alias M='mutt -y'

    Expire and Supercedes

    Getting tired of deleting the mail from the nightly cron-job? Do you want to save the daily joke automatically to an archive folder?

      Expires: 20 Nov 2000 00:00:00 +0000
    FAQ: Can you set an expiration date from within mutt?
    A: No.

    You would have to add the Expires: header lines yourself.

    BIND and MACRO

    Seems like you cannot bind commands to high-bit keys. Only keys with values between 0 and 127 are allowed.

    Which keys are good for creating macros? Only the underscore (_) and the hash mark (#) seem to be unbound by default. As the '#' is used in the setup file commenting lines it needs to be escaped within commands. So the '_' seems a good choice.

    What's free? Looking at Mutt 1.4i (2002-05-29) with no setup file you'll get to see the default bindings. unfortunately, the generic bindings are kept separate from the bound keys, so here's a key overview:

      CTRL    A C   GH J    O Q S  VWXYZ
      upper   AB  E   I         S    XY
      lower           i               y
      alpha   abcdefghijklmnopqrstuvwxyz

    So the keys ABEISXY can be used to bind some macros. However, there are ten commands which are *not* bound by default. That's why I bind three of these to a two-key sequence:

       bind index zt current-top
       bind index zz current-middle
       bind index zb current-bottom

    Now these keys are bound just like they are with the editor "vim". :-)

    Theoretically, the remaining seven unbound commands can then be bound to ABEISXY respectively - but I do not use all of these commands, anyway.

    I do use the commands next-unread and previous-unread, though. I have bound them to the TAB key and "comma TAB", respectively:

       bind index   \t          next-unread
       bind index  ,\t      previous-unread

    Besides, I have bound them for the use with the pager, too, so I can use them when I read messages; that way I don't have to go back to the index to select the next message:

       bind index   \t          next-unread
       bind index  ,\t      previous-unread


    display-toggle-weed + ignore
    Q: When I use display-toggle-weed in the pager then there is *no* change to the display. Mutt still shows the same header lines.
    A: Mutt probably does not have any lines to ignore. So there is nothing to hide/show - and the display won't change. You should change the setup by uisng the commands ignore and unignore .

    Mutt and Usenet (aka NEWS aka NNTP)

    Mutt does not speak NNTP by default - so you cannot use it for Usenet (News).

    So if you need to send on some mail to a newsgroup then you should consider using a mail2news gateway. for example (Don't forget to add a Newsgroups header line!)

    Aside from using mail2news gateways there are patches which add support for NNTP. you can download one of them at named "patch-${VERSION}.vvv.nntp.gz" after applying the patches you then need to recompile mutt with the option "--enable-nntp".

    Fighting Spam

    "Can't mutt automatically delete my spam?" No. mutt is not doing anything automatically. Use a mail filter!

    "But I don't know how to set up a mail filter. It is all so complicated!" Well, use somethjing like spam assassin:



    exim: when you use the MTA exim then you will find that setting the hostname to only the domain won't have the desired effect of hiding the name of the current host. The solution is to add "set use_from" to the setupfile since Debian's package has that unset by default.


    6.3.20.  bounce_delivered - Type: boolean - Default: yes
    When this variable is set, mutt will include
    Delivered-To headers when bouncing messages.
    Postfix users may wish to unset this variable.


    macro pager r "\
        set display_filter = \"tr a-zA-Zn-za-mN-ZA-M\"\
        unset display_filter"\
    macro pager R "" "re-display message"

    but if the "tr" command is available as a script in your shell's $PATH then you can cut this down, of course, to:

    macro pager r "\
        set display_filter=rot13\
        unset display_filter"\

    see also:

    Internal Language

    Every program with lots of options is asking for an internal language at some point. There is a simple reaon for this: conditions.

    Mutt does not have an internal language. Why is this? the reason is quite simple: Mutt was not designed to be "scriptable".

    Does mutt need an internal language? Or can you make use of an external language to simply start up mutt according to conditions?

    condition in a shell script:
    if [ condition ]
    then mutt -F setupfile1
    else mutt -F setupfile2
    use of environment variables:
    source ~/.mutt-$TERM
    conditions in a FIFO:
    source ~/.mutt/foo|

    Language design: How shall the language look like? What are the purposes of this language? Shall mutt make use of a language which can be added at compile time? Which language exist and what are their features? Which language is suited best for the purpose of mutt as a mail reader?

    File permissions

    When mutt creates files tehn the file permissions are "600", ie readable and writable by the owner - and no permissions to the group or others. feature.

    some people use the trick to save attachments like webpages and pictures onto their webserver and then view them with a webbrowser.


    Header Config

    Here is an example email:
    From: Patrick 
    Subject: Re: File sizes in kilobytes
    Date: Thu, 25 Jul 2002 06:21:59 -0500
    User-Agent: Mutt/1.4i
    Message-ID: <>
    [quoted text]
    [additional text]
    Patrick Shanahan
    Registered Linux User #207535

    The From: line only has the first name. It is not complete. Most spams have no or just one "comment" apart from the address. so any anti-spam tool would add a score here for a possible spam. The Reply-To: line only contains an address; so when you reply to this message then you will lose the name in the header. Furthermore, the attribution to the quoted text will only show the first name as there is no more than than. (unless you have an alias on that address with the complete and and using reverse_alias).

    his full name is in the signature, however. but when your mailer/editor is configured to automatically kill signatures then the information about his name is lost yet again. unless, of course, you quote signatures. but i do not encourage that. after all this part is not supposed to be part of the actual text in the body.




    FAQ:  Howto attach multiple files?
    A:    use option "-a" multiple times:
          mutt -a file1 -a file2 address
          or put all file names into a file "mutt.files"
          and use the backtick evaluation of your shell
          as well as "sed" to prepend "-a" to each filename:
          mutt `sed 's/^/-a /' mutt.files` address


    reading and understanding the manual is not trivial because of several inconsistencies in variable naming, and missing examples.

    for example, you have to "set copy" to make mutt "save" messages so you might expect its name to be something like "save_messages". there "set save_name" makes it save mails from username@domain by *username* - so how about "save_by_username"?

    so you "set copy save_name" - and none of your mails to foo@bar get saved at all. why? well, if +foo does not exist then mutt won't save anything. feature. it requires "set force_name" to make mutt create non-existing foldername...

    maybe it is easier to understand when you describe it like this:

    copy:       save outbound mails (on/off toggle).
    save_name:  save mails "From: user@domain" in folder "+user"
                if +user does not exist then do *not* save.
    force_name: save mails "From: user@domain" in folder "+user"
                if +user does not exist then *create* "+user".

    so "set copy save_name force_name" to make mutt save all outbound mails and create new folders if necessary.

      fcc-save-hook . =outbox/%O


    Unicode Mutt [2002-07-26]
    how to set up mutt for Unicode using a suitable terminal and fonts.

    Using Mutt to send emails to mailing lists [010601]
    Author: Hugo Haas

    Mutt Bedienung (German) [010820]
    Two parts: (I) A short overview to default mutt commands. (II) Some configuration items with explanation.

    ?? (German) [010821]
    An intro to using mutt on Linux. Written by Wolfgang

    mutt kconfig [2003-05-04, 2004-01-04] [2003-05-04] 86KB
    A script form page which generates a setup file for mutt. requires kconfig. written by Jochen Striepe jochen(at)
    This work is based in the "small mutt configurator" ("Kleiner Mutt-Konfigurator") written by by Bjørn BÜrger mutt_config_feedback(at) :

    Setups Explained