GNU Mailutils provides a broad set of utilities for handling electronic mail.  These utilities address the needs of both system administrators and users.

All utilities are built around a single core subsystem and share many common aspects.  All of them are able to work with almost any existing mailbox formats.  They use a common configuration file syntax, and their configuration files are located in a single subdirectory.

In this chapter we will discuss each utility, and give some advices on how to use them in various real life situations.

First of all we will describe command line and configuration file syntax.

Command Line
============

Basic Notions About Command Line Options
----------------------------------------

Many command line options have two forms, called short and long forms.  Both forms are absolutely identical in function; they are interchangeable.

The short form is a traditional form for UNIX utilities. In this form, the option consists of a single dash, followed by a single letter, e.g.  -c.

Short options which require arguments take their arguments immediately following the option letter, optionally separated by white space.  For example, you might write -f name, or -fname. Here, -f is the option, and name is its argument.

Short options which allow optional arguments take their arguments immediately following the option letter, without any intervening white space characters.  This is important, so that the command line parser might discern that the text following option is its argument, not the next command line parameter.  For example, if option -d took an optional argument, then -dname would mean the option with its argument (name in this case), and -d name would mean the -d option without any argument, followed by command line argument name.

Short options' letters may be clumped together, but you are not required to do this.  When short options are clumped as a set, use one (single) dash for them all, e.g.  -cvl is equivalent to -c -v -l.  However, only options that do not take arguments may be clustered this way.  If an option takes an argument, it can only be the last option in such a cluster, otherwise it would be impossible to specify the argument for it.  Anyway, it is much more readable to specify such options separated.

The long option names are probably easier to memorize than their short counterparts.  They consist of two dashes, followed by a multi-letter option name, which is usually selected to be a mnemonics for the operation it requests.  For example, --verbose is a long option that increases the verbosity of a utility.  In addition, long option names can abbreviated, provided that such an abbreviation is unique among the options understood by a given utility.  For example, if a utility takes options --foreground and --forward, then the shortest possible abbreviations for these options are --fore and --forw, correspondingly.  If you try to use --for, the utility will abort and inform you that the abbreviation you use is ambiguous, so it is not clear which of the options you intended to use.

Long options which require arguments take those arguments following the option name.  There are two ways of specifying a mandatory argument.  It can be separated from the option name either by an equal sign, or by any amount of white space characters.  For example, if the --file option requires an argument, and you wish to supply name as its argument, then you can do so using any of the following notations: --file=name or --file name.

In contrast, optional arguments must always be introduced using an equal sign.

Options That are Common for All Utilities.
------------------------------------------

All GNU Mailutils programs understand a common subset of options.

--help
-?
     Display a short summary of the command line options understood by this utilities, along with a terse description of each.

     The output of this option consists of three major parts.  First, a usage synopsis is displayed.  For example:

          Usage: sieve [OPTION...] SCRIPT
          GNU sieve -- a mail filtering tool

     The first line tells that the sieve utility takes any number of options (brackets indicate optional part) and a single mandatory argument (SCRIPT).  The second lines summarizes the purpose of the utility.

     Following this header is an option summary.  It consists of two columns:

       -c, --compile-only         Compile script and exit
       -d, --debug[=FLAGS]        Debug flags
       -e, --email=ADDRESS        Override user email address

     The leftmost column contains a comma-separated list of option names.  Short options are listed first.  The options are ordered alphabetically.  Arguments, if any, are specified after the last option name in the list, so that, e.g. the option -e in the example above requires an argument: -e ADDRESS.  Optional arguments are enclosed in square brackets, as in --debug option in the example above.

     The rightmost column contains a short description of the option purpose.

     The last part of --help output contains some additional notices and lists the email address for reporting bugs.

--usage
     Display a short summary of options.  In the contrast to the --help option, only option names and arguments are printed, without any textual description.  For example:

          Usage: sieve [-cv?V] [--compile-only] [--debug[=FLAGS]]
                       [--email=ADDRESS] SCRIPT

The exact formatting of the output produced by these two options is configurable.  See Usage Vars, for a detailed descriptions of it.

--version
-V
     Print program version and exit.

--show-config-options
     Show configuration options used when compiling the package.  You can use this option to verify if support for a particular mailbox format or other functionality is compiled in the binary.  The output of this option is intended to be both machine-readable and understandable by humans.

The following command line options affect parsing of configuration files.  Here we provide a short summary, the next section will describe them in detail.

--config-file=FILE
     Load this configuration file, instead of the default.

--config-help
     Show configuration file summary.

--config-lint
     Check configuration file syntax and exit

--config-verbose
     Verbosely log parsing of the configuration files.

--no-site-config
     Do not load site-wide configuration file.

--no-user-config
     Do not load user configuration file.

--set=PATH
     Set configuration variable.

Mailutils Configuration File
============================

Configuration files are the principal means of configuring any GNU Mailutils component.  When started, each utility tries to load its configuration from the following locations, in that order:

 1. Main site-wide configuration file.

     It is named SYSCONFDIR/mailutils.rc, where SYSCONFDIR stands for the system configuration directory set when compiling the package. You can obtain the value of SYSCONFDIR by running

          $ mailutils-config --info sysconfdir

     or

          $ PROG --show-config-options | grep SYSCONFDIR

     where PROG stands for any GNU Mailutils utility.

     The site-wide configuration file is not read if the --no-site-config command line option was given.

 2. Per-user configuration file.

     A per user configuration file is located in the user home directory and is named .PROG, where PROG is the name of the utility.  For example, the per-user configuration file for sieve utility is named .sieve.

     This configuration file is not read if the --no-user-config command line option was given.

 3. Additional configuration file, if specified using the --config-file command line option.

The order in which configuration files are loaded defines the precedence of their settings.  Thus, the settings from additional configuration file override those set in per-user configuration file. The latter, in their turn, take precedence over the settings from the site-wide configuration file.

Neither site-wide nor user configuration files are required to exist.  If any or both of them are absent, GNU Mailutils does not complain, and the utility falls back to its default settings.  To make configuration processing more verbose, use the --config-verbose command line option.  Here is an example of what you might get using this option:

     imap4d: Info: parsing file `/etc/mailutils.rc'
     imap4d: Info: finished parsing file `/etc/mailutils.rc'

Specifying this option more than once adds more verbosity to this output.  If this option is given two times, GNU Mailutils will print any configuration file statement it parsed, along with the exact location where it occurred (the exact meaning of each statement will be described later in this chapter):

     imap4d: Info: parsing file `/etc/mailutils.rc'
     # 1 "/etc/mailutils.rc"
     mailbox {
     # 2 "/etc/mailutils.rc"
       mailbox-pattern maildir:/var/spool/mail;type=index;param=2;user=${user};
     # 3 "/etc/mailutils.rc"
       mailbox-type maildir;
     };
     # 6 "/etc/mailutils.rc"
     include /etc/mailutils.d;
     imap4d: Info: parsing file `/etc/mailutils.d/imap4d'
     ...

To test configuration file without actually starting the utility, use the --config-lint command line option.  With this option, any Mailutils utility exits after finishing parsing of the configuration files.  Any errors occurred during parsing are displayed on the standard error output.  This option can be combined with --config-verbose to obtain more detailed output.

The --config-help command line option produces on the standard output the summary of all configuration statements understood by the utility, with detailed comments and in the form suitable for configuration file.  For example, the simplest way to write a configuration file for, say, imap4d is to run

     $ imap4d --config-help > imap4d.rc

and to edit the imap4d.rc file with your editor of choice.

It is also possible to set or override arbitrary configuration variables in the command line.  It can be done via the --set option.  Its argument is a pathname of the variable to be set. For example, to define the variable syslog in section logging to no, do the following:

     $ imap4d --set .logging.syslog=no

Configuration pathnames are discussed in detail in Paths.

Configuration File Syntax
-------------------------

The configuration file consists of statements and comments.

There are three classes of lexical tokens: keywords, values, and separators.  Blanks, tabs, newlines and comments, collectively called white space are ignored except as they serve to separate tokens.  Some white space is required to separate otherwise adjacent keywords and values.

Comments
........

Comments may appear anywhere where white space may appear in the configuration file.  There are two kinds of comments: single-line and multi-line comments.  Single-line comments start with # or // and continue to the end of the line:

     # This is a comment
     // This too is a comment

Multi-line or C-style comments start with the two characters /* (slash, star) and continue until the first occurrence of */ (star, slash).

Multi-line comments cannot be nested.  However, single-line comments may well appear within multi-line ones.

Statements
..........

A simple statement consists of a keyword and value separated by any amount of whitespace.  Simple statement is terminated with a semicolon (;).

The following is a simple statement:

     standalone yes;
     pidfile /var/run/pop3d.pid;

A keyword begins with a letter and may contain letters, decimal digits, underscores (_) and dashes (-). Examples of keywords are: expression, output-file.

A value can be one of the following:

number
     A number is a sequence of decimal digits.

boolean
     A boolean value is one of the following: yes, true, t or 1, meaning true, and no, false, nil, 0 meaning false.

unquoted string
     An unquoted string may contain letters, digits, and any of the following characters: _, -, ., /, @, *, :.

quoted string
     A quoted string is any sequence of characters enclosed in double-quotes (").  A backslash appearing within a quoted string introduces an escape sequence, which is replaced with a single character according to the following rules:

     Table: Backslash escapes

     Sequence   Replaced with
     \a   Audible bell character (ASCII 7)
     \b   Backspace character (ASCII 8)
     \f   Form-feed character (ASCII 12)
     \n   Newline character (ASCII 10)
     \r   Carriage return character (ASCII 13)
     \t   Horizontal tabulation character (ASCII 9)
     \v   Vertical tabulation character (ASCII 11)
     \\   A single backslash (\)
     \"   A double-quote.

     In addition, the sequence \NEWLINE is removed from the string.  This allows to split long strings over several physical lines, e.g.:

          "a long string may be\
           split over several lines"

     If the character following a backslash is not one of those specified above, the backslash is ignored and a warning is issued.

     Two or more adjacent quoted strings are concatenated, which gives another way to split long strings over several lines to improve readability.  The following fragment produces the same result as the example above:

          "a long string may be"
          " split over several lines"

Here-document
     A here-document is a special construct that allows to introduce strings of text containing embedded newlines.

     The <<WORD construct instructs the parser to read all the following lines up to the line containing only WORD, with possible trailing blanks.  Any lines thus read are concatenated together into a single string.  For example:

          <<EOT
          A multiline
          string
          EOT

     The body of a here-document is interpreted the same way as a double-quoted string, unless WORD is preceded by a backslash (e.g.  <<\EOT) or enclosed in double-quotes, in which case the text is read as is, without interpretation of escape sequences.

     If WORD is prefixed with - (a dash), then all leading tab characters are stripped from input lines and the line containing WORD.  Furthermore, if - is followed by a single space, all leading whitespace is stripped from them.  This allows to indent here-documents in a natural fashion.  For example:

          <<- TEXT
              The leading whitespace will be
              ignored when reading these lines.
          TEXT

     It is important that the terminating delimiter be the only token on its line.  The only exception to this rule is allowed if a here-document appears as the last element of a statement.  In this case a semicolon can be placed on the same line with its terminating delimiter, as in:

          help-text <<-EOT
                  A sample help text.
          EOT;

list
     A list is a comma-separated list of values.  Lists are enclosed in parentheses.  The following example shows a statement whose value is a list of strings:

          alias (test,null);

     In any case where a list is appropriate, a single value is allowed without being a member of a list: it is equivalent to a list with a single member.  This means that, e.g.

          alias test;

     is equivalent to

          alias (test);

A block statement introduces a logical group of statements.  It consists of a keyword, followed by an optional value, and a sequence of statements enclosed in curly braces, as shown in the example below:

     server srv1 {
       host 10.0.0.1;
       community "foo";
     }

The closing curly brace may be followed by a semicolon, although this is not required.

Statement Path
..............

Mailutils configuration files have a distinct hierarchical structure.  Each statement in such files can therefore be identified by its name and the names of block statements containing it.  Such names form this statement pathname, similar to that used, e.g. by UNIX file system.

For example, consider the following file:

     foo {
       bar {
         baz 45;   # A.
       }
       baz 98;     # B.
     }

The full pathname of the statement marked with A can be written as:

     .foo.bar.baz

Similarly, the statement marked with B has the following pathname:

     .foo.baz

The default path component separator is dot.  A pathname beginning with a component separator is called absolute pathname.  Absolute pathnames uniquely identify corresponding statements.  If the leading dot is omitted, the resulting pathname is called relative.  Relative pathnames identify statements in relation to the current point of reference in the configuration file.

Any other punctuation character can be used as a component separator, provided that it appears at the beginning of the pathname.  In other words, only absolute pathnames allow for a change in component separators.

A block statement that has a tag is referred to by its name, followed by an equals sign, followed by the tag value.  For example, the statement A in the file below:

     program x {
       bar {
         baz 45;   # A.
       }
     }

is identified by the following pathname:

     .program=x.bar.baz

The tag can optionally be enclosed in a pair of double quotes.  Such a quoting becomes mandatory for tags that contain white space or path component separator, e.g.:

     .program="a.out".bar.baz

Include Statement
-----------------

The include statement is a special statement that causes inclusion of a named file.  It has the following syntax:

     include FILE;

If FILE names a regular file, the contents of this file is included in this point.  Otherwise, if FILE names a directory, Mailutils searches in that directory for a file whose name coincides with the name of utility being executed, and includes this file, if it exists.

It is a common approach to end the site-wide configuration file with an include statement, e.g.:

     include /etc/mailutils.d;

This allows each particular utility to have its own configuration file.  Thus.  imap4d will read /etc/mailutils.d/imap4d, etc.

Logging Statement
-----------------

Syntax
------

     logging {
       # Send diagnostics to syslog.
       syslog BOOLEAN;
       # Print message severity levels.
       print-severity BOOLEAN;
       # Output only messages with a severity equal to or
       # greater than this one.
       severity STRING;
       # Set syslog facility.
       facility NAME;
       # Tag syslog messages with this string.
       tag TEXT;
     }

Description
-----------

The logging block statement configures where the diagnostic output goes and how verbose it is.

 -- Configuration: syslog bool
     If syslog is set to yes, the diagnostics will go to syslog.  Otherwise, it goes to the standard error.

The default syslog facility is determined at compile time, it can be inspected using the following command (see mu info):

     $ mu info log_facility

 -- Configuration: facility name
     Use syslog facility NAME.  Valid argument values are: user, daemon, auth, authpriv, mail, cron, local0 through local7 (all names case-insensitive), or a facility number.

 -- Configuration: tag text
     Tag syslog messages with TEXT.  By default, program name is used as syslog tag.

 -- Configuration: print-severity bool
     Print Mailutils severity name before each message.

 -- Configuration: severity name
     Output only messages with a severity equal to or greater than this one.  Valid arguments are: debug, info, notice, warning, error, crit, alert, emerg,

Debug Statement
---------------

Syntax
------

     debug {
       # Set Mailutils debugging level.
       level SPEC;
       # Prefix debug messages with Mailutils source locations.
       line-info BOOL;
     }

Description
-----------

The debug statement controls the amount of additional debugging information output by Mailutils programs.  The level statement enables additional debugging information.  Its argument (SPEC) is a Mailutils debugging specification as described in debugging.

The line-info statement, when set to true causes debugging messages to be prefixed with locations in Mailutils source files where they appear.  Normally, only Mailutils developers need this option.

Mailbox Statement
-----------------

Syntax
------

     mailbox {
       # Use specified URL as a mailspool.
       mail-spool URL;
       # Create mailbox URL using PATTERN.
       mailbox-pattern PATTERN;
       # Default mailbox type.
       mailbox-type TYPE;
       # Default user mail folder.
       folder DIR;
     }

Description
-----------

The mailbox statement configures the location, name and type of user mailboxes.

The mailbox location can be specified using mail-spool or mail-pattern statements.

 -- Configuration: mail-spool PATH
     The mail-spool statement specifies directory that holds user mailboxes.  Once this statement is given, the libmailutils library will assume that the mailbox of user LOGIN is kept in file PATH/LOGIN.

     Historically, PATH can contain mailbox type prefix, e.g.: maildir:///var/spool/mail, but such usage is discouraged in favor of mailbox-pattern statement.

 -- Configuration: mailbox-pattern PATTERN
     The mailbox-pattern statement is a modern way of configuring mailbox locations.  It supersedes mail-spool statement.

     The PATTERN is valid mailbox URL, which may contain references to user macro-variable (-pxrefmacro-variables).  This macro-variable will be expanded to the actual user name.  The full syntax for PATTERN is:

            [TYPE://]PATH[;ARGS]

     where:

     type
          Specifies the mailbox type.  It must be one of mailbox types, supported by Mailutils. -xrefMailbox URLs.  By default, local is assumed.  Verify this.

     path
          The path pattern.

     args
          A semicolon-separated list of optional arguments, configuring indexed directory structure.

          An indexed directory structure is a special way of storing mailboxes, which allows for faster access in case of very large number of users.

          By default, all user mailboxes are stored in a single directory and are named after user login names.  To find the mailbox for a given user, the system scans the directory for the corresponding file.  This usually implies linear search, so the time needed to locate a mailbox is directly proportional to the ordinal number of the mailbox in the directory.

          GNU Mailutils supports three types of indexed directories: direct, reverse, and hashed.

          In direct indexed directory structure, PATH contains 26 subdirectories named with lower-case letters of Latin alphabet.  The location of the user mailbox is determined using the following algorithm:

           1. Take the first letter of the user name.

           2. Map it to a lower-case letter using index mapping table.  The result gives sub-directory name.

           3. Descend into this directory.

          For example, using this algorithm, the mailbox of the user smith is stored in file PATH/s/smith.

          If each of single-letter subdirectories contains the indexed directory structure, we have second level of indexing.  In this case the file name of smith's mailbox is PATH/s/m/smith.

          The reverse indexed structure uses the same principles, but the indexing letters are taken from the end of the user name, instead of from the beginning.  For example, in the 2nd level reverse indexed structure, the smith's mailbox is located in PATH/h/t/smith.

          Finally, the hashed structure consists of 256 subdirectories under PATH, named by 2-letter hex codes from 00 to FF.  Mailboxes are stored in these subdirectories.  The name of the subdirectory is computed by hashing first LEVEL letters of the user name.  The hashing algorithm is:

           1. Take next letter from the user name

           2. Add its ASCII value to the hash sum.

           3. Continue (1-2) until LEVEL letters are processed, or all letters from the file name are used, whichever occurs first.

           4. Convert the computed sum modulo 256 to a hex code.

          Indexed directory structures are configured using the following arguments:

          type=VALUE
               Specifies type of indexing.  Valid values are index, for direct indexed structure, rev-index for reverse indexing, and hash for hashed structure.

          param=NUMBER
               Specifies indexing level.

          user=STRING
               Specifies indexing key.  The only meaningful value, as of Mailutils version VERSION is user=${user}.

          Let's assume the traditional mail layout, in which user incoming mails are stored in UNIX mailbox format in /var/mail directory. The mailbox-pattern for this case is:

                 mailbox-pattern "/var/mail/${user}";

          It is entirely equivalent to specifying mail-spool "/var/mail".

          Now, if the layout is the same, but mailboxes are kept in maildir format, then the corresponding statement is:

                 mailbox-pattern "maildir:///var/mail/${user}";

          Finally, if the mailboxes are stored in a directly-indexed directory with two levels of indexing, than:

                 mailbox-pattern "maildir:///var/mail;type=index;param=2;user=${user}";

If neither mailbox-pattern nor mail-spool are given, the mailbox names are determined using the following algorithm:

 1. If environment variable FOLDER its value is used.

 2. Otherwise, if environment variable MAIL is set, its value is used.

 3. If neither of these is set, the mailbox name is constructed by concatenating the built-in mail spool directory name, a directory separator, and the user name.

     The built-in mail spool directory name is determined at compile time, using _PATH_MAILDIR define from the include file paths.h.  If this value is not defined, /var/mail or /usr/spool/mail is used.

 -- Configuration: mailbox-type TYPE
     Specifies type of mailboxes.  By default, mbox (UNIX mailbox) is assumed.  This can be changed while configuring the package by setting MU_DEFAULT_SCHEME configuration variable.  The default value can be verified by running mailutils-config --info scheme.

 -- Configuration: folder DIR
     Sets user mail folder directory.  Its value is using when expanding plus-notation, i.e. such mailbox names as +inbox.  The + sign is replaced by DIR, followed by a directory separator (/).

     The DIR argument can contain mailbox type prefix, e.g mh://Mail.

     The default folder name is Mail/.

Locking Statement
-----------------

Syntax
------

     locking {
       # Default locker flags.
       flags ARG;
       # Set timeout for acquiring the lock.
       retry-timeout ARG;
       # Set the maximum number of times to retry acquiring the lock.
       retry-count NUMBER;
       # Expire locks older than this amount of time.
       expire-timeout NUMBER;
       # Use PROG as external locker program.
       external-locker PROG;
     }

Description
-----------

This block statement configures various parameters used when locking UNIX mailboxes in order to prevent simultaneous writes.

It is important to note, that locking applies only to maildrops in UNIX mailbox format.  All other mailbox types do not require locking.

 -- Configuration: flags STRING
     Set locking flags.  Argument is a string consisting of one or more of the following letters:

     E
          Use an external program to manage locks.  The program is given by external-locker statement (see below).

     R
          If the locking attempt failed, retry it.  This is the default.  The number of retries, and time interval between the two successive attempts is given by retry-count and retry-timeout statements, correspondingly.

     T
          If a lock file exists, check its modification time and, if it is older than a predefined amount of time, remove the lock.  The amount of time is specified by expire-timeout statement.

     P
          Store the PID of the locking process in a lock file.

 -- Configuration: retry-count NUMBER
     Number of locking attempts.  The P flag must be set for this to take effect.

 -- Configuration: retry-timeout SECONDS
     Time interval, in seconds, between the two successive locking attempts.  The P flag must be set for this to take effect.

 -- Configuration: expire-timeout SECONDS
     Remove existing lock file, if it is created more than this number of seconds ago.  The T flag must be set for this to take effect.

 -- Configuration: external-locker STRING
     Set command line of an external locker program.  The E flag must be set for this to take effect.

Mailer Statement
----------------

Syntax
------

     mailer {
       url URL;
     }

Description
-----------

A mailer is a special logical entity GNU Mailutils uses for sending messages.  Its internal representation is discussed in -refMailer.  The mailer statement configures it.

The mailer statement contains a single sub-statement:

 -- Configuration: url STR
     Set the mailer URL.

GNU Mailutils supports two types of mailer URLs, described in the table below.  As usual, square brackets indicate optional parts:

smtp://HOST[:PORT]
     Use an SMTP server HOST to send messages.  Optional PORT specifies port number or symbolic name (as defined in /etc/services).  It defaults to 25.  The HOST can be specified as either an IP address in dotted-quad notation or as a symbolic host name.  In the latter case, DNS system will be used to resolve it.

sendmail://PROGNAME
     Use sendmail-compatible program PROGNAME.  Sendmail-compatible means that the program must support following command line options:

     -oi
          Do not treat . as message terminator.

     -f ADDR
          Use ADDR as the sender address.

     -t
          Get recipient addresses from the message.

sendmail:
     This is a special form of the sendmail mailer.  It uses the sendmail binary from the _PATH_SENDMAIL macro in your /usr/include/paths.h.  It is the default mailer.

prog://PROGNAME?QUERY
     A prog mailer.  This is a generalization of sendmail mailer that allows to use arbitrary external programs as mailers.

     The PROGNAME must be a full pathname of the binary file.  When sending message, Mailutils will invoke this file with the arguments specified by QUERY and will pipe the message to be sent to its standard input.

     The QUERY part is a list of arguments, separated by & signs.  Arguments may contain the following macro-substitutions:

     ${sender}
          Expands to the sender email address.

     ${rcpt}
          Expands to the recipient email addresses.

ACL Statement
-------------

Syntax
------

     acl {
       # Allow connections from this IP address.
       allow [from] IP;
       # Deny connections from this IP address.
       deny [from] IP;
       # Log connections from this IP address.
       log [from] IP [STRING];
       /* Execute supplied program if a connection from this
          IP address is requested. */
       exec [from] IP PROGRAM;
       /* Use PROGRAM to decide whether to allow connection
          from IP. */
       ifexec [from] IP PROGRAM;
     }

Description
-----------

The ACL statement defines an Access Control List, a special structure that controls who can access the given Mailutils resource.

The acl block contains a list of access controls.  Each control can be regarded as a function that returns a tree-state value: True, False and Don't know.  When a remote party connects to the server, each of controls is tried in turn.  If a control returns False, access is denied.  If it returns True, access is allowed.  If it returns Don't know, then the next control is tried.  It is unclear whether to allow access if the last control in list returned Don't know.  GNU Mailutils VERSION issues a warning message and allows access. This default may change in future versions.  Users are advised to write their ACLs so that the last control returns a definitive answer (either True or False).

In the discussion below, wherever IP appears as an argument, it can be replaced by any of:

  * An IPv4 address in dotted-quad notation.

  * An IPv6 address in numeric notation

  * A CIDR in the form IP/MASK, where IP is an IP address (either IPv4 or IPv6), and MASK is the network mask.

  * A symbolic host name.

  * A word any, which matches any IP address.

The following controls are understood:

 -- Configuration: allow [from] CIDR
     Allow connections from IP addresses matching this CIDR block.

 -- Configuration: deny [from] CIDR
     Deny connections from IP addresses matching this CIDR block.

 -- Configuration: ifexec [from] CIDR PROGRAM
     When a connection from the CIDR block is requested, execute the program PROGRAM.  If its exit code is 0, then allow connection.  Otherwise, deny it.

The following two controls are provided for logging purposes and as a means of extensions.  They always return a Don't know answer, and therefore should not be used at the end of an ACL:

 -- Configuration: log [from] CIDR [STRING]
     Log connections from addresses in this CIDR.  The MU_DIAG_INFO channel is used.  If the logging goes to syslog, it is translated to the LOG_INFO priority.

     If STRING is not given, the format of the log entry depends on the connection family, as described in the table below:

     {AF_INET IP:PORT}
          For inet IPv4 connections.  The variables IP and PORT are replaced by the remote IP address and port number, correspondingly.

     {AF_UNIX}
          For connections over UNIX sockets.  The socket name, if available, may be printed before the closing curly brace.

     If the STRING is specified, it undergoes macro expansion and the result of it is used as the log entry.  The following macro variables are expanded:

     aclno
          Ordinal number of the control in the ACL.  Numbers begin from 0.

     family
          Connection family.  Mailutils version VERSION supports two families: AF_INET and AF_UNIX.

     address
          Remote IP address (for AF_INET) or socket name (for AF_UNIX).  Notice that most Unixes return empty string instead of the AF_UNIX socket name, so do not rely on it.

     port
          Remote port number (for AF_INET).

     For example, the following ACL makes a Mailutils server log every incoming connection:

            acl {
               log from any "Connect from ${address}";
               ...
            }

     This was the default behavior for the versions of Mailutils up to 1.2, so if you got used to its logs you might wish to add the above in your configuration files.

 -- Configuration: exec [from] CIDR PROGRAM
     If a connection from the CIDR block is requested, execute the given PROGRAM.  Do not wait for it to terminate, and ignore its exit code.

Tcp-wrappers Statement
----------------------

Syntax
------

     tcp-wrappers {
       # Enable TCP wrapper access control.
       enable BOOL;
       # Set daemon name for TCP wrapper lookups.
       daemon NAME;
       # Use FILE for positive client address access control.
       allow-table FILE;
       # Use file for negative client address access control.
       deny-table FILE;
       # Log allowed accesses at this syslog priority.
       allow-syslog-priority PRIO;
       # Log denied accesses at this syslog priority.
       deny-syslog-priority PRIO;
     }

Description
-----------

The tcp-wrappers statements provides an alternative way to control accesses to the resources served by GNU Mailutils.  This statement is enabled if Mailutils is compiled with TCP wrappers library libwrap.

Access control using TCP wrappers is based on two files, called tables, containing access rules.  There are two tables: the allow table, usually stored in file /etc/hosts.allow, and the deny table, kept in file /etc/hosts.deny.  The rules in each table begin with an identifier called daemon name.  Each utility wishing to verify a connection, select the entries having its daemon name from the allow table.  A connection is allowed if it matches any of these entries.  Otherwise, the utility retrieves all entries with its daemon name from the deny table.  If any of these matches the connection, then it is refused.  Otherwise, if neither table contains matching entries, the connection is allowed.

Description of a TCP wrapper table format lies outside the scope of this document.  Please, see ACCESS CONTROL FILES (hosts_access(5) man page), for details.

 -- Configuration: enable BOOL
     Enable access control using TCP wrappers.  It is on by default.

 -- Configuration: daemon NAME
     Set daemon name for TCP wrapper lookups.  By default, the name of the utility is used.  E.g.  imap4d uses imap4d as the daemon name.

 -- Configuration: allow-table FILE
     Use FILE as allow table.  By default, /etc/hosts.allow is used.

 -- Configuration: deny-table FILE
     Use FILE as negative table.  By default, /etc/hosts.deny is used.

 -- Configuration: allow-syslog-priority PRIO;
     Log allowed accesses using syslog priority PRIO.

 -- Configuration: deny-syslog-priority PRIO;
     Log denied accesses using syslog priority PRIO.

Server Settings
---------------

GNU Mailutils offers several server applications: pop3d, imap4d, comsatd, to name a few.  Being quite different in their purpose, they are very similar in some aspects of their architecture.  First of all, they all support two operating mode: a daemon mode, where a program disconnects from the controlling terminal and works in background, and an inetd mode, where it remains in foreground and communicates with the remote party via standard input and output streams.  Secondly, when operating as daemons, they listen to a preconfigured set of IP addresses and ports, reacting to requests that arrive.

To configure these aspects of functionality, GNU Mailutils provides Server Configuration Settings, which we will describe in this subsection.

General Server Configuration
............................

 Syntax:

     # Set daemon mode.
     mode inetd|daemon;
     # Run in foreground.
     foreground BOOL;
     # Maximum number of children processes to run simultaneously.
     max-children NUMBER;
     # Store PID of the master process in FILE.
     pidfile FILE;
     # Default port number.
     port PORTSPEC;
     # Set idle timeout.
     timeout TIME;

 Description: These statements configure general server-related issues.

 -- Configuration: mode STRING;
     Set operation mode of the server.  Two operation modes are supported:

     daemon
          Run as a standalone daemon, disconnecting from the controlling terminal and continuing to run in the background.  In this case, it is the server that controls what IP addresses and ports to listen on, who is allowed to connect and from where, how many clients are allowed to connect simultaneously, etc.  Most remaining configuration statements are valid only in the daemon mode.

          This is the preferred mode of operation for GNU Mailutils servers.

     inetd
          Operate as a subprocess of UNIX internet super-server program, inetd.  See Internet super-server (inetd(8) man page), for a detailed description of the operation of inetd and its configuration.  In this case it is inetd that controls all major connectivity aspects, the Mailutils server itself communicates with it via standard input and output streams.

          For historical reasons, this mode is the default, if no mode statement is specified.  This will change in the future.

 -- Configuration: foreground BOOL;

     [daemon mode only]

     Do not disconnect from the controlling terminal and remain in the foreground.

 -- Configuration: max-children NUMBER;

     [daemon mode only]

     Set maximum number of child processes allowed to run simultaneously. This equals the number of clients that can use the server simultaneously.

     The default is 20 clients.

 -- Configuration: pidfile FILE;
     After startup, store the PID of the main server process in FILE.  When the process terminates, the file is removed.  As of version VERSION, GNU Mailutils servers make no further use of this file.  It is intended for use by automated startup scripts and controlling programs (-pxrefmention pies).

 -- Configuration: port PORTSPEC;

     [daemon mode only]

     Set default port to listen to.  The PORTSPEC argument is either a port number in decimal, or a symbolic service name, as listed in /etc/services (see Internet network services list (services(5) man page)).

 -- Configuration: timeout TIME;
     Set maximum idle time out in seconds.  If a client does not send any requests during TIME seconds, the child process terminates.

Server Statement
................

 Syntax:

     server IPADDR[:PORT] {
       # Run this server as a single process.
       single-process BOOL;
       # Log the session transcript.
       transcript BOOL;
       # Set idle timeout.
       timeout TIME;
       # Set server specific ACLs.
       acl { /* See ACL Statement. */ };
     }

 Description: The server block statement configures a single TCP or UDP server.  It takes effect only in daemon mode (see server mode). The argument to this statement specifies the IP address, and, optionally, the port, to listen on for requests.  The IPADDR part is either an IPv4 address in dotted-quad form, or a symbolic host name which can be resolved to such an address via DNS.  Specifying 0.0.0.0 as the IPADDR means listen on all available network interfaces.  The PORT argument is either a port number in decimal, or a symbolic service name, as listed in /etc/services (see Internet network services list (services(5) man page)).  If PORT is omitted, Mailutils uses the port set by port statement (see port), or, in its absence, the default port number, which depends on a server being used (e.g. 110, for pop3d, 143, for imap4d, etc.).

Any number of server statements may be specified in a single configuration file, allowing to set up the same service on several IP addresses and/or port numbers, and with different configurations.

Statements within the server block statement configure this particular server.

 -- Configuration: single-process BOOL;
     If set to true, this server will operate in single-process mode.  This mode is intended for debugging only, do not use it on production servers.

 -- Configuration: transcript BOOL;
     Enable transcript of the client-server interaction.  This may generate excessive amounts of logging, which in turn may slow down the operation considerably.

     Session transcripts are useful in fine-tuning your configurations and in debugging.  They should be turned off on most production servers.

 -- Configuration: timeout TIME;
     Set idle timeout for this server.  This overrides global timeout settings (see timeout).

 -- Configuration: acl
     This statement defines a per-server Access Control List.  Its syntax is as described in ACL Statement.  Per-server ACLs complement, but not override, global ACLs, i.e. if both global ACL and per-server ACL are used, the connection is allowed only if both of them allow it, and is denied if any one of them denies it.

Auth Statement
--------------

Syntax
------

     auth {
       # Set a list of modules for authentication.
       authentication MODULE-LIST;
       # Set a list of modules for authorization.
       authorization MODULE-LIST;
     }

Description
-----------

Some mail utilities provide access to their services only after verifying that the user is actually the person he is claiming to be.  Such programs are, for example, pop3d and imap4d.  The process of the verification is broken down into two stages: authorization and authentication. In authorization stage the program retrieves the information about a particular user.  In authentication stage, this information is compared against the user-supplied credentials.  Only if both stages succeed is the user allowed to use the service.

A set of modules is involved in performing each stage.  For example, the authorization stage can retrieve the user description from various sources: system database, SQL database, virtual domain table, etc.  Each module is responsible for retrieving the description from a particular source of information.  The modules are arranged in a module list.  The modules from the list are invoked in turn, until one of them succeeds or the list is exhausted.  In the latter case the authorization fails.  Otherwise, the data returned by the succeeded module are used in authentication.

Similarly, authentication may be performed in several ways.  The authentication modules are also grouped in a list.  Each module is tried in turn until either a module succeeds, in which case the authentication succeeds, or the end of the list is reached.

For example, the authorization list

       (system, sql, virtdomains)

means that first the system user database (/etc/password) is searched for a description of a user in question.  If the search fails, the SQL database is searched.  Finally, if it also fails, the search is performed in the virtual domain database.

Note, that some authentication and/or authorization modules may be disabled when configuring the package before compilation.  The names of the disabled modules are nevertheless available for use in runtime configuration options, but they represent a ``fail-only'' functionality, e.g. if the package was compiled without SQL support then the module sql in the above example will always fail, thus passing the execution on to the next module.

The auth statement configures authentication and authorization.

 -- Configuration: authorization MODULE-LIST
     Define a sequence of modules to use for authorization.  Modules will be tried in the same order as listed in MODULE-LIST.

     The modules available for use in authorization list are:

     system
          User credentials are retrieved from the system user database (/etc/password).

     sql
          User credentials are retrieved from a SQL database. A separate configuration statement, sql, is used to configure it (see SQL Statement).

     virtdomain
          User credentials are retrieved from a ``virtual domain'' user database.  Virtual domains are configured using virtdomain statement (see Virtdomain Statement).

     radius
          User credentials are retrieved using RADIUS.  See Radius Statement, for a detailed description on how to configure it.

     ldap
          User credentials are retrieved from an LDAP database.  See LDAP Statement, for an information on how to configure it.

     This may be inaccurate: Unless overridden by authorization statement, the default list of authorization modules is:

            (system, sql, virtdomains)

 -- Configuration: authentication MODULE-LIST
     Define a sequence of modules to use for authentication.  Modules will be tried in the same order as listed in MODULE-LIST.

     The following table lists modules available for use in MODULE-LIST:

     generic
          The generic authentication type.  User password is hashed and compared against the hash value returned in authorization stage.

     system
          The hashed value of the user password is retrieved from /etc/shadow file on systems that support it.

     sql
          The hashed value of the user password is retrieved from a SQL database using query supplied by getpass statement (see getpass).

     pam
          The user is authenticated via pluggable authentication module (PAM).  The PAM service name to be used is configured in pam statement (see PAM Statement).

     radius
          The user is authenticated on a remote RADIUS server.  See Radius Statement.

     ldap
          The user is authenticated using LDAP.  See LDAP Statement.

     This list is inaccurate: Unless overridden by authentication statement, the list of authentication modules is:

            (generic, system, pam, sql)

PAM Statement
-------------

Syntax
------

     pam {
       # Set PAM service name.
       service TEXT;
     }

Description
-----------

The pam statement configures PAM authentication.  It contains a single sub-statement:

 -- Configuration: service TEXT
     Define service name to look for in PAM configuration.  By default, the base name of the Mailutils binary is used.

This statement takes effect only if pam is listed in authentication statement (see Auth Statement).

Virtdomain Statement
--------------------

Syntax
------

     virtdomain {
       # Name of the virtdomain password directory.
       passwd-dir DIR;
     }

Description
-----------

Virtual mail domains make it possible to handle several mail domains each having a separate set of users, on a single server. The domains are completely independent of each other, i.e. the same user name can be present in several domains and represent different users.

When authenticating to a server with virtual domain support enabled, users must supply their user names with domain parts.  The server strips off the domain part and uses it as a name of UNIX-format password database file, located in the domain password directory.  The latter is set using passwd-dir statement.

 -- Configuration: passwd-dir DIR
     Set virtual domain password directory.

For example, when authenticating user smith@domain.tld, the server will use password file named DIR/domain.tld. This file must be in UNIX passwd format (see password file (passwd(5) man page)), with encrypted passwords stored in it (as of GNU Mailutils version VERSION, there is no support for shadow files in virtual password directories, although this is planned for future versions).  Here is an example record from this file:

     smith:Wbld/G2Q2Le2w:1000:1000:Email Account:/var/mail/domain/smith:/dev/null

Notice, that it must contain user names without domain parts.

The pw_dir field (the 6th field) is used to determine the location of the maildrop for this user.  It is defined as PW_DIR/INBOX.  In our example, the maildrop for user smith will be located in file /var/mail/domain/smith.

If user did not supply his domain name, or if no matching record was found in the password file, or if the file matching the domain name does not exist, then GNU Mailutils falls back to alternative method. First, it tries to determine the IP address of the remote party.  Then the domain name corresponding to that address is looked up in the DNS system.  Finally, this domain name is used as a name of the password file.

Radius Statement
----------------

Syntax
------

     radius {
       # Set radius configuration directory.
       directory DIR;
       # Radius request for authorization.
       auth REQUEST;
       # Radius request for getpwnam.
       getpwnam REQUEST;
       # Radius request for getpwuid.
       getpwuid REQUEST;
     }

Description
-----------

The radius block statement configures RADIUS authentication and authorization.

Mailutils uses GNU Radius library, which is configured via raddb/client.conf file (see Client Configuration (GNU Radius Reference Manual)).  Its exact location depends on configuration settings that were used while compiling GNU Radius.  Usually it is /usr/local/etc, or /etc.  This default can also be changed at run time using directory statement:

 -- Configuration: directory DIR
     Set full path name to the GNU Radius configuration directory.

It authorization is used, the Radius dictionary file must declare the the following attributes:

Attribute      Type      Description
GNU-MU-User-Name   string    User login name
GNU-MU-UID         integer   UID
GNU-MU-GID         integer   GID
GNU-MU-GECOS       string    GECOS
GNU-MU-Dir         string    Home directory
GNU-MU-Shell       string    User shell
GNU-MU-Mailbox     string    User mailbox
GNU-MU-Quota       integer   Mail quota (in bytes)

A dictionary file with appropriate definitions is included in the Mailutils distribution: examples/config/mailutils.dict.  This file is not installed by default, you will have to manually copy it to the GNU Radius raddb/dict directory and include it in the main dictionary file raddb/dictionary by adding the following statement:

     $INCLUDE dict/mailutils.dict

Requests to use for authentication and authorization are configured using three statements: auth, getpwnam and getpwuid.  Each statement takes a single argument: a string, containing a comma-separated list of assignments.  An assignment specifies a particular attribute-value pair (see RADIUS Attributes (GNU Radius Reference Manual)) to send to the server.  The left-hand side of the assignment is a symbolic attribute name, as defined in one of Radius dictionaries (see Dictionary of Attributes (GNU Radius Reference Manual)).  The value is specified by the right-hand side of assignment.  For example:

     "Service-Type = Authenticate-Only, NAS-Identifier = \"mail\""

An assignment may contain references to the following macro-variables (-pxrefmacro-variables):

user
     The actual user name (for auth and getpwnam), or user ID (for getpwuid).  For example:

          User-Name = ${user}

passwd
     User password.  For examples:

          User-Password = ${passwd}

 -- Configuration: auth PAIRLIST
     Specifies the request to be sent to authenticate the user.  For example:

          auth "User-Name = ${user}, User-Password = ${passwd}";

     The user is authenticated only if this request returns Access-Accept (see Access-Accept (GNU Radius Reference Manual)).  Any returned attribute-value pairs are ignored.

 -- Configuration: getpwnam PAIRLIST
     Specifies the request that returns user information for the given user name.  For example:

          getpwnam "User-Name = ${user}, State = getpwnam, "
                   "Service-Type = Authenticate-Only";

     If the requested user account exists, the Radius server must return Access-Accept packet with the following attributes: GNU-MU-User-Name, GNU-MU-UID, GNU-MU-GID, GNU-MU-GECOS, GNU-MU-Dir, GNU-MU-Shell.

     The attributes GNU-MU-Mailbox and GNU-MU-Quota are optional.

     If GNU-MU-Mailbox is present, it must contain a valid mailbox URL (-pxrefurls).  If GNU-MU-Mailbox is not present, Mailutils constructs the mailbox name using the settings from the mailbox configuration statement (see Mailbox Statement), or built-in defaults, if it is not present.

     If GNU-MU-Quota is present, it specifies the maximum mailbox size for this user, in bytes.  In the absence of this attribute, mailbox size is unlimited.

 -- Configuration: getpwuid PAIRLIST
     Specifies the request that returns user information for the given user ID.  In PAIRLIST, the user macro-variable is expanded to the numeric value of ID.  For example:

          getpwuid "User-Name = ${user}, State = getpwuid, "
                   "Service-Type = Authenticate-Only";

     The reply to getpwuid request is the same as to getpwnam request (see above).

SQL Statement
-------------

Syntax
------

     sql {
       # Set SQL interface to use.
       interface mysql|odbc|postgres;
       # SQL server host name.
       host ARG;
       # SQL user name.
       user ARG;
       # Password for the SQL user.
       passwd ARG;
       # SQL server port.
       port ARG;
       # Database name.
       db ARG;
       # Type of password returned by getpass query.
       password-type plain | hash | scrambled;
       # Set a field-map for parsing SQL replies.
       field-map MAP;
       # SQL query returning the user's password.
       getpass QUERY;
       # SQL query to use for getpwnam requests.
       getpwnam QUERY;
       # SQL query to use for getpwuid requests.
       getpwuid QUERY;
     }

Description
-----------

The sql statement configures access credentials to SQL database and the queries for authentication and authorization.

GNU Mailutils supports three types of SQL interfaces: MySQL, PostgreSQL and ODBC.  The latter is a standard API for using database management systems, which can be used to communicate with a wide variety of DBMS.

 -- Configuration: interface TYPE
     Configures type of DBMS interface.  Allowed values for TYPE are:

     mysql
          Interface with a MySQL server (http://www.mysql.org).

     odbc
          Use ODBC interface.  See http://www.unixodbc.org, for a detailed description of ODBC configuration.

     postgres
          Interface with a PostgreSQL server (http://www.postgres.org).

The database and database access credentials are configured using the following statements:

 -- Configuration: host ARG
     The host running the SQL server.  The value can be either a host name or an IP address in dotted-quad notation, in which case an INET connection is used, or a full pathname to a file, in which case a connection to UNIX socket is used.

 -- Configuration: port ARG
     TCP port the server is listening on (for INET connections).  This parameter is optional.  Its default value depends on the type of database being used.

 -- Configuration: db ARG;
     Name of the database.

 -- Configuration: user ARG
     SQL user name.

 -- Configuration: passwd ARG;
     Password to access the database.

LDAP Statement
--------------

Syntax
------

     ldap {
       # Enable LDAP lookups.
       enable BOOL;
       # Set URL of the LDAP server.
       url URL;
       # Base DN for LDAP lookups.
       base STRING;
       # DN for accessing LDAP database.
       binddn STRING;
       # Password for use with binddn.
       passwd STRING;
       # Use TLS encryption.
       tls BOOL;
       # Set LDAP debugging level.
       debug NUMBER;
       # Set a field-map for parsing LDAP replies.
       field-map MAP;
       # LDAP filter to use for getpwnam requests.
       getpwnam STRING;
       # LDAP filter to use for getpwuid requests.
       getpwuid FILTER;
     }

TLS Statement
-------------

Syntax
------

     tls {
       # Enable TLS support.
       enable BOOL;
       # Specify SSL certificate file.
       ssl-cert BOOL;
       # Specify SSL certificate key file.
       ssl-key FILE;
       # Specify trusted CAs file.
       ssl-cafile FILE;
     }

GSASL Statement
---------------

Syntax
------

     gsasl {
       # Name of GSASL password file.
       cram-passwd FILE;
       # SASL service name.
       service STRING;
       # SASL realm name.
       realm STRING;
       # SASL host name.
       hostname STRING;
       # Anonymous user name.
       anonymous-user STRING;
     }

Debugging
=========

Mailutils debugging output is controlled by a set of levels, each of which can be set independently of others.  Each debug level consists of a category name, which identifies the part of Mailutils for which additional debugging is desired, and a level number, which tells Mailutils how verbose should its output be.

Valid debug levels are:

error
     Displays error conditions which are normally not reported, but passed to the caller layers for handling.

trace0 through trace9
     Ten levels of verbosity, trace0 producing less output, trace9 producing the maximum amount of output.

prot
     Displays network protocol interaction, where applicable.

Implementation and applicability of each level differs between various categories.  The full list of categories is available in file libmailutils/diag/debcat in the Mailutils source tree. Most useful categories and levels implemented for them are discussed later in this article.

Level Syntax
------------

Debug levels can be set either from the command line, by using the --debug-level command line option, or from the configuration file, using the .debug.level statement.  In both cases, the level is specified as a list of individual levels, delimited with semicolons.  Each individual level can be specified as:

!CATEGORY
     Disables all levels for the specified CATEGORY.

CATEGORY
     Enables all levels for the specified CATEGORY.

CATEGORY.LEVEL
     For the given CATEGORY, enables all levels from error to LEVEL, inclusive.

CATEGORY.=LEVEL
     Enables only the given LEVEL for this CATEGORY.

CATEGORY.!LEVEL
     Disables all levels from error to LEVEL, inclusive, for this CATEGORY.

CATEGORY.!=LEVEL
     Disables only the given LEVEL in this CATEGORY.

CATEGORY.LEVELA-LEVELB
     Enables all levels in the range from LEVELA to LEVELB, inclusive.

CATEGORY.!LEVELA-LEVELB
     Disables all levels in the range from LEVELA to LEVELB, inclusive.

Additionally, a comma-separated list of level specifications is allowed after the dot.  For example, the following specification:

     acl.prot,!=trace9,!trace2

enables in category acl all levels, except trace9, trace0, trace1, and trace2.

BNF
---

The following specification in Backus-Naur form describes formally the Mailutils debug level:

     <debug-spec> ::= <level-spec> | <debug-level-list>
     <debug-level-list> ::= <debug-level> |
                            <debug-level-list> ";" <debug-level>
     <debug-level> ::= <category> | "!" <category> |
                       <category> "." <level-list>
     <level-list> ::= <level-spec> | <level-list> "," <level-spec>
     <level-spec> ::=  <level> | <negate-level>
     <negate-level> ::= "!" <level>
     <level> ::= <level-number> | "=" <level-number> |
                 <level-number> "-" <level-number>
     <level-number> ::= "error" | "trace0" | "trace1" | "trace2" | "trace3" |
                        "trace4" | "trace5" | "trace6" | "trace7" |
                        "trace8" | "trace9" | "prot"

Debugging Categories
--------------------

acl
     This category enables debugging of Access Control Lists.  Available levels are:

     error
          As usual, displays errors, not directly reported otherwise.

     trace0
          Basic tracing of ACL processing.

     trace9
          Traces the process of matching the ACL conditions.

config
     This category affects configuration parser and/or lexical analyzer.  The following levels are supported:

     trace0
          Minimal information about configuration statements.

     trace2
          Trace lexical structure of the configuration files.

     trace7
          Trace execution of the configuration parser.

     Due to its specific nature, this category cannot be enabled from the configuration file.  A special hook is provided to facilitate debugging the configuration parser, namely, a pragmatic comment in form:

          #debug=DEBUG-LEVEL-LIST

     causes DEBUG-LEVEL-LIST to be parsed as described above.  Thus, to force debugging of the configuration parser, one would add the following line at the very beginning of the configuration file:

          #debug=config.trace7

mailbox
     Operations over mailboxes.  This module supports the following levels: error, trace0, trace1, and prot.  The latter is used by remote mailbox support libraries.

auth
     Enables debugging information about authentication and authorization. This category supports the following levels: error, trace0, trace1, and trace2.

     In level trace0, user data are reported along with the data source they were obtained from.  The output may look like this:

          pop3d: source=system, name=gray, passwd=x, uid=120, gid=100,
          gecos=Sergey Poznyakoff, dir=/home/gray, shell=/bin/bash,
          mailbox=/var/mail/gray, quota=0, change_uid=1

     In the trace1 level, additional flow traces are displayed.

     In the level trace2, a detailed flow trace is displayed, which looks like the following:

          pop3d: Trying generic...
          pop3d: generic yields 38=Function not implemented
          pop3d: Trying system...
          pop3d: system yields 0=Success
          pop3d: Trying generic...
          pop3d: generic yields 4135=Authentication failed
          pop3d: Trying system...
          pop3d: system yields 0=Success

mailer
     Debugs mailer operations.  The following levels are supported:

     error
          Displays mild error conditions.

     trace0
          Traces mailer operations in general: displays what part of the message is being sent, etc.

     trace6
          When used together with prot, displays security-sensitive information (such as passwords, user keys, etc). in plaintext.  By default, such information is replaced with asteriscs to reduce the possibility of security compromise.

     trace7
          When used together with prot, displays the payload information as it is being sent.  The payload is the actual message contents, i.e. the part of SMTP transaction that goes after the DATA command and which ends with a terminating dot line. Setting this level can generate huge amounts of information.

     prot
          For SMTP mailer: outputs transcripts of SMTP sessions.

     Note: Unless in a very secure environment, it is advised to avoid using level settings such as mailer.prot or mailer (without explicit level part), because the resulting output tends to be extremely copious and reveals sender private and security-sensitive data.  If you wish to trace SMTP session flow, use mailer.=prot or at least mailer.prot,!trace6.

serve
     This category provides debugging information for Mailutils IP server objects.  It supports the error and trace0 levels.

folder
     This category controls debugging information shown for operations related to Mailutils folders.

remote
     The remote category is used by imap4d and pop3d servers to request showing additional information in the session transcripts.  This category takes effect only when the transcript configuration variable is set.  Valid levels are:

     trace6
          Show security-sensitive information (user passwords, etc.)

     trace7
          Show payload information

frm and from --- List Headers from a Mailbox
============================================

GNU mailutils provides two commands for listing messages in a mailbox. These are from and frm.

The behavior of both programs is affected by the following configuration file statements:

Statement   Reference
debug     see Debug Statement.
tls       see TLS Statement.
mailbox   see Mailbox Statement.
locking   see Locking Statement.

frm
---

The frm utility outputs a header information of the selected messages in a mailbox.  By default, frm reads user's system mailbox and outputs the contents of From and Subject headers for each message.  If a folder is specified in the command line, the program reads that folder rather than the default mailbox.

The following command line options alter the behavior of the program:

-d
--debug
     Enable debugging output.

-f STRING
--field STRING
     Display the header named by STRING instead of From Subject pair.

-l
--to
     Include the contents of To header to the output.  The output field order is then: To From Subject.

-n
--number
     Prefix each line with corresponding message number.

-Q
--Quiet
     Be very quiet.  Nothing is output except error messages.  This is useful in shell scripts where only the return status of the program is important.

-q
--query
     Print a message only if there are unread messages in the mailbox.

-S
--summary
     Print a summary line.

-s ATTR
--status ATTR
     Only display headers from messages with the given status. ATTR may be one of the following: new, read, unread.  It is sufficient to specify only first letter of an ATTR.  Multiple -s options are allowed.

-t
--align
     Tidy mode.  In this mode frm tries to preserve the alignment of the output fields.  It also enables the use of BIDI algorithm for displaying subject lines that contain text in right-to-left orientation (such as Arabic or Hebrew).

from
----

The from utility displays sender and subject of each message in a mailbox.  By default, it reads the user's system mailbox.  If the program is given a single argument, it is interpreted as a name of the user whose mailbox is to be read.  Obviously, permissions are required to access that user's mailbox, so such invocations may be used only by superuser.

The option -f (--file) instructs from to read the given mailbox.

The full list of options, supported by from follows:

-c
--count
     Prints only a count of messages in the mailbox and exit.

-d
--debug
     Prints additional debugging output.

-s STRING
--sender=STRING
     Prints only mail whose From: headers contain the supplied string. Probably, this should test envelopes as well.

-f URL
--file=URL
     Examine mailbox from the given URL.

mail --- Send and Receive Mail
==============================

Mail is an enhanced version of standard /bin/mail program. As well as its predecessor, it can be used either in sending mode or in reading mode.  Mail enters sending mode when one or more email addresses were specified in this command line.  In this mode the program waits until user finishes composing the message, then attempts to send it to the specified addresses and exits. See Composing Mail, for a detailed description of this behavior.

If the command line contained no email addresses, mail switches to reading mode.  In this mode it allows to read and manipulate the contents of the user system mailbox.  The --file (-f) command line option allows to specify another mailbox name.  For more detail, see Reading Mail.

In contrast to other GNU Mailutils programs, mail does not use the Mailutils configuration file.  Instead, it uses the traditional mailrc-style configuration.  See Mail Configuration Files, for a detailed description of its format.

Invoking mail
-------------

General usage of mail program is:

           mail [OPTION...] [ADDRESS...]

If [ADDRESS...] part is present, mail switches to mail sending mode, otherwise it operates in mail reading mode.

The program uses following option groups: -xrefmailbox.

Mail understands following command line options:

-e
--exist
     Return true if the mailbox contains some messages.  Return false otherwise. This is useful for writing shell scripts.

-E COMMAND
--exec=COMMAND
     Execute COMMAND before opening the mailbox.  Any number of --exec options can be given.  The commands will be executed after sourcing configuration files (see Mail Configuration Files), but before opening the mailbox.

-f
--file
     Operate on the mailbox given by the first non-optional command line argument.  If there is no such argument, read messages from the user's mbox file.  See Reading Mail, for more details about using this option.

-F
--byname
     Record outgoing messages in a file named after the first recipient. The name is the login-name portion of the address found first on the To: line in the mail header.  This option sets the byname variable, which see (see byname).

-H
--headers
     Print header summary to stdout and exit.

-i
--ignore
     Ignore interrupts.

-m PATH
--mail-spool=PATH
     Set path to the mailspool directory

-n
--norc
     Do not read the system-wide mailrc file.  See Mail Configuration Files.

-N
--nosum
     Do not display initial header summary.

-p
--print
-r
--read
     Print all mail to standard output.  It is equivalent to issuing following commands after starting mail -N:

          print *
          quit

-q
--quit
     Cause interrupts to terminate program.

-s SUBJ
--subject=SUBJ
     Send a message with a Subject of SUBJ.  Valid only in sending mode.

-t
--to
     Switch to sending mode.

-u USER
--user=USER
     Operate on USER's mailbox.  This is equivalent to:

          mail -f/SPOOL_PATH/USER

     with SPOOL_PATH being the full path to your mailspool directory

     (/var/spool/mail or /var/mail on most systems).

-?
--help
     Display a help message.
--usage
     Display a short usage summary.

-V
--version
     Print program version and exit.

How to Specify Message Sets
---------------------------

Many mail commands such as print and delete can be given a message list to operate upon.  Wherever the message list is omitted, the command operates on the current message.

The message list in its simplest form is one of:

.
     Selects current message.  It is equivalent to empty message list.

*
     Selects all messages in the mailbox.

^
     Selects first non-deleted message.

$
     Selects last non-deleted message.

In its complex form, the message list is a comma or whitespace-separated list of message specifiers.  A message specifier is one of

Message Number
     This specifier addresses the message with the given ordinal number in the mailbox.

Message range
     Message range is specified as two message numbers separated by a dash.  It selects all messages with the number lying within that range.

Attribute specifier
     An Attribute specifier is a colon followed by a single letter.  The Attribute specifier addresses all messages in the mailbox that have the given attribute.  These are the valid attribute specifiers:

     :d
          Selects all deleted messages.

     :n
          Selects all recent messages, i.e. the messages that have not been neither read not seen so far.

     :o
          Selects all messages that have been seen.

     :r
          Selects all messages that have been read.

     :u
          Selects all messages that have not been read.

     :t
          Selects all tagged messages.

     :T
          Selects all untagged messages.

Header match
     The header match is a string in the form:

          [HEADER:]/STRING/

     It selects all messages that contain header field HEADER matching given REGEXP.  If the variable regexp is set, the STRING is assumed to be a POSIX regexp.  Otherwise, a header is considered to match STRING if the latter constitutes a substring of the former (comparison is case-insensitive).

     If HEADER: part is omitted, it is assumed to be Subject:.

Message body match
     The message body match is a string in the form:

          :/STRING/

     It selects all messages whose body matches the string.  The matching rules are the same as described under ``Header match''.

A message specifier can be followed by message part specifier, enclosed in a pair of brackets.  A message part specifier controls which part of a message should be operated upon. It is meaningful only for multipart messages.  A message part specifier is a comma or whitespace - separated list of part numbers or ranges.  Each part number can in turn be message part specifier, thus allowing for operating upon multiply-encoded messages.

The following are the examples of valid message lists:

Composing Mail
--------------

You can compose the message by simply typing the contents of it, line by line.  But usually this is not enough, you would need to edit your text, to quote some messages, etc.  Mail provides these capabilities through compose escapes.  The compose escapes are single-character commands, preceded by special escape character, which defaults to ~.  The combination escape character + command is recognized as a compose escape only if it occurs at the beginning of a line.  If the escape character must appear at the beginning of a line, enter it twice. The actual escape character may be changed by setting the value of escape mail variable (see Mail Variables).

Quitting Compose Mode
.....................

There are several commands allowing you to quit the compose mode.

Typing the end-of-file character (C-D) on a line alone finishes compose mode and sends the message to its destination.  The C-D character looses its special meaning if ignoreeof mail variable is set.

If mail variable dot is set, typing dot (.) on a line alone achieves the same effect as C-D above.

Finally, using ~. escape always quits compose mode and sends out the composed message.

To abort composing of a message without sending it, type interrupt character (by default, C-C) twice.  This behavior is disabled when mail variable ignore is set.  In this case, you can use ~x escape to achieve the same effect.

Getting Help on Compose Escapes: ~?
...................................

The ~? escape prints on screen a brief summary of the available compose escapes.  Please note, that ~h escape prompts for changing the header values, and does not give help.

Editing the Message: ~e and ~v
..............................

If you are not satisfied with the message as it is, you can edit it using a text editor specified either by EDITOR or by VISUAL environment variables.  The ~e uses the former, and ~v uses the latter.

By default both escapes allow you to edit only the body of the message.  However, if the editheaders variable is set, mail will load into the editor the complete text of the message with headers included, thus allowing you to change the headers as well.

Modifying the Headers: ~h, ~t, ~c, ~b, ~s
.........................................

To add new addresses to the list of message recipients, use ~t command, e.g.:

     ~t name1@domain.net name2

To add addresses to Cc or Bcc, use ~c or ~b escapes respectively.

To change the Subject header, use ~s escape, e.g.:

     ~s "Re: your message"

Finally, to edit all headers, type ~h escape.  This will present you with the values of To, Cc, Bcc, and Subject headers allowing to edit them with normal text editing commands.

Enclosing Another Message: ~m and ~M
....................................

If you are sending mail from within mail command mode, you can enclose the contents of any message sent to you by using ~m or ~M commands.  Typing ~m alone will enclose the contents of the current message, typing ~m 12 will enclose the contents of message #12 and so on.

The ~m uses retained and ignored lists when enclosing headers, the ~M encloses all header fields.

In both cases, the contents of indentprefix mail variable is prepended to each line enclosed.

Adding a File to the Message: ~r and ~d
.......................................

To append the contents of file FILENAME to the message, type

     ~r FILENAME

or

     ~< FILENAME

The ~d escape is a shorthand for

     ~r dead.letter

Printing And Saving the Message
...............................

The ~p escape types the contents of the message entered so far, including headers, on your terminal.  You can save the message to an arbitrary file using ~w escape.  It takes the filename as its argument.

Signing the Message: ~a and ~A
..............................

To save you the effort of typing your signature at the end of each message, you can use ~a or ~A escapes.  If your signature occupies one line only, save it to the variable sign and use ~a escape to insert it.  Otherwise, if it is longer than one line, save it to a file, store the name of this file in the variable Sign, and use ~A escape to insert it into the message.

Printing Another Message: ~f and ~F
...................................

Sometimes it is necessary to view the contents of another message, while composing.  These two escapes allow it.  Both take the message list as their argument.  If they are used without argument, the contents of the current message is printed.  The difference between ~f and ~F is that the former uses ignored and retained lists to select headers to be displayed, whereas the latter prints all headers.

Inserting Value of a Mail Variable: ~i
......................................

The ~i escape enters the value of the named mail variable into the body of the message being composed.

Executing Other Mail Commands: ~: and ~-
........................................

You can execute a mail command from within compose mode using ~: or ~- escapes.  For example, typing

     ~: from :t

will display the from lines of all tagged messages.  Note, that executing mail-sending commands from within the compose mode is not allowed. An attempt to execute such a command will result in diagnostic message ``Command not allowed in an escape sequence'' being displayed. Also, when starting compose mode immediately from the shell (e.g. running mail address@domain), most mail commands are meaningless, since there is no mailbox to operate upon.  In this case, the only commands that can reasonably be used are: alias, unalias, alternate, set, and unset.

Executing Shell Commands: ~! and ~|
...................................

The ~! escape executes specified command and returns you to mail compose mode without altering your message.  When used without arguments, it starts your login shell.  The ~| escape pipes the message composed so far through the given shell command and replaces the message with the output the command produced.  If the command produced no output, mail assumes that something went wrong and retains the old contents of your message.

Reading Mail
------------

To read messages from a given mailbox, use one of the following ways of invoking mail:

mail
     To read messages from your system mailbox.

mail -f
mail --file
     To read messages from your mailbox ($HOME/mbox).  If the --user option (see below) is also given, read messages from that user's mbox.

mail -f PATH_TO_MAILBOX
mail --file PATH_TO_MAILBOX
     To read messages from the specified mailbox.
mail -u USER

mail --user=USER
     To read messages from the system mailbox belonging to USER.

Please note, that usual mailbox permissions won't allow you to use the last variant of invocation, unless you are a super-user. Similarly, the last but one variant is also greatly affected by the permissions the target mailbox has.

Notice that PATH_TO_MAILBOX is not an argument to --file (-f) option, but rather the first non-optional argument on the command line.  Therefore, the following three invocations are equivalent:

     $ mail -fin mymbox
     $ mail -f mymbox -in
     $ mail --file -in mymbox
     $ mail --file -i mymbox -n

Additionally, for conformance to the GNU standards, the following form is also accepted:

     $ mail --file=mymbox -i -n

Unless you have started mail with --norc command line option, it will read the contents of the system-wide configuration file. Then it reads the contents of user configuration file, if any. For detailed description of these files, see Mail Configuration Files. After this initial setup, mail displays the first page of header lines and enters interactive mode.  In interactive mode, mail displays its prompt (?, if not set otherwise) and executes the commands the user enters.

Quitting the Program
....................

Following commands quit the program:

quit
     Terminates the session.  If mail was operating upon user's system mailbox, then all undeleted and unsaved messages that have been read and are not marked with hold flag are saved to the user's mbox file ($HOME/mbox).  The messages, marked with delete are removed. The program exits to the Shell, unless saving the mailbox fails, in which case user can escape with the exit command.

exit
ex
xit
     Program exits to the Shell without modifying the mailbox it operates upon.

Typing EOF (C-D) alone is equivalent to quit.

Obtaining Online Help
.....................

Following commands can be used during the session to request online help:

help [COMMAND]
hel [COMMAND]
? [COMMAND]
     Display detailed command synopsis.  If no COMMAND is given, help for all available commands is displayed.

list
*
     Print a list of available commands.

version
ve
     Display program version.

warranty
wa
     Display program warranty statement.

Moving Within a Mailbox
.......................

^
     Move to the first undeleted message.

$
     Move to the last undeleted message.

next
n
     Move to the next message.

previous
prev
     Move to the previous message.

Changing Mailbox/Directory
..........................

cd [DIR]
chdir [DIR]
ch [DIR]
     Change to the specified directory.  If DIR is omitted, $HOME is assumed.

file [MAILBOX]
fi [MAILBOX]
folder [MAILBOX]
fold [MAILBOX]
     Read in the contents of the specified MAILBOX.  The current mailbox is updated as if quit command has been issued. If MAILBOX is omitted, the command prints the current mailbox name followed by the summary information regarding it, e.g.:

          & fold
          "/var/spool/mail/gray": 23 messages 22 unread

Controlling Header Display
..........................

To control which headers in the message should be displayed, mail keeps two lists: a retained header list and an ignored header list.  If retained header list is not empty, only the header fields listed in it are displayed when printing the message. Otherwise, if ignored header list is not empty, only the headers not listed in this list are displayed.  The uppercase variants of message-displaying commands can be used to print all the headers.

The following commands modify and display the contents of both lists.

discard [HEADER-FIELD-LIST]
di [HEADER-FIELD-LIST]
ignore [HEADER-FIELD-LIST]
ig [HEADER-FIELD-LIST]
     Add HEADER-FIELD-LIST to the ignored list.  When used without arguments, this command prints the contents of ignored list.

retain [HEADER-FIELD-LIST]
ret [HEADER-FIELD-LIST]
     Add HEADER-FIELD-LIST to the retained list.  When used without arguments, this command prints the contents of retained list.

Displaying Information
......................

=
     Displays the current message number.

headers [MSGLIST]
h [MSGLIST]
     Lists the current pageful of headers.

from [MSGLIST]
f [MSGLIST]
     Lists the contents of From headers for a given set of messages.

z [ARG]
     Presents message headers in pagefuls as described for headers command.  When ARG is ., it is generally equivalent to headers.  When ARG is omitted or is +, the next pageful of headers is displayed.  If ARG is -, the previous pageful of headers is displayed.  The latter two forms of z command may also take a numerical argument meaning the number of pages to skip before displaying the headers.  For example:

          & z +2

     will skip two pages of messages before displaying the header summary.

size [MSGLIST]
si [MSGLIST]
     Lists the message number and message size in bytes for each message in MSGLIST.

folders
     Displays the value of folder variable.

summary
su
     Displays current mailbox summary.  E.g.:

          & summary
          "/var/spool/mail/gray": 23 messages 22 unread

Displaying Messages
...................

print [MSGLIST]
p [MSGLIST]

type [MSGLIST]
t [MSGLIST]
     Prints out the messages from MSGLIST.  The variable crt determines the minimum number of lines the body of the message must contain in order to be piped through pager command specified by environment variable PAGER.  If crt is set to a numeric value, this value is taken as the minimum number of lines.  Otherwise, if crt is set without a value then the height of the terminal screen is used to compute the threshold.  The number of lines on screen is controlled by screen variable.

Print [MSGLIST]
P [MSGLIST]
Type [MSGLIST]
T [MSGLIST]
     Like print but also prints out ignored header fields.

decode [MSGLIST]
dec [MSGLIST]
     Print a multipart message.  The decode command decodes and prints out specified message parts.  E.g.

          & decode 15[2]
          +---------------------------------------
          | Message=15[2]
          | Type=message/delivery-status
          | encoding=7bit
          +---------------------------------------
          Content-Type: message/delivery-status
          ...

top [MSGLIST]
to [MSGLIST]
     Prints the top few lines of each message in MSGLIST.  The number of lines printed is controlled by the variable toplines and defaults to five.

pipe [MSGLIST] [SHELL-COMMAND]
| [MSGLIST] [SHELL-COMMAND]
     Pipe the contents of specified messages through SHELL-COMMAND.  If SHELL-COMMAND is empty but the string variable cmd is set, the value of this variable is used as a command name.

struct [MSGLIST]
     Prints the MIME structure of each message from MSGLIST.  Empty MSGLIST means current message.

     Example:

          & struct 2
          2      multipart/mixed            14k
          2[1]   text/plain                 296
          2[2]   application/octet-stream    5k
          2[3]   text/x-diff                31k

Marking Messages
................

tag [MSGLIST]
ta [MSGLIST]
     Tag messages.  The tagged messages can be referred to in message list using :t notation.

untag [MSGLIST]
unt [MSGLIST]
     Clear tags from specified messages.  To untag all messages tagged so far type

          & untag :t

hold [MSGLIST]
ho [MSGLIST]
preserve [MSGLIST]
pre [MSGLIST]
     Marks each message to be held in user's system mailbox.  This command does not override the effect of delete command.

Disposing of Messages
.....................

delete [MSGLIST]
d [MSGLIST]
     Mark messages as deleted.  Upon exiting with quit command these messages will be deleted from the mailbox.  Until the end of current session the deleted messages can be referred to in message lists using :d notation.

undelete [MSGLIST]
u [MSGLIST]
     Clear delete mark from the specified messages.

dp [MSGLIST]
dt [MSGLIST]
     Deletes the current message and prints the next message.  If MSGLIST is specified, deletes all messages from the list and prints the message, immediately following last deleted one.

Saving Messages
...............

save [[MSGLIST] FILE]
s [[MSGLIST] FILE]
     Takes a message list and a file name and appends each message in turn to the end of the file.  The name of file and number of characters appended to it is echoed on the terminal.  Each saved message is marked for deletion as if with delete command, unless the variable keepsave is set.

Save [MSGLIST]
S [MSGLIST]
     Like save, but the file to append messages to is named after the sender of the first message in MSGLIST.  For example:

          & from 14 15
           U  14 smith@noldor.org Fri Jun 30 18:11  14/358   The Save c
           U  15 gray@noldor.org  Fri Jun 30 18:30  8/245    Re: The Sa
          & Save 14 15
          "smith" 22/603

     i.e., 22 lines (603 characters) have been appended to the file ``smith''. If the file does not exist, it is created.

write [[MSGLIST] FILE]
w [[MSGLIST] FILE]
     Similar to save, except that only message body (without the header) is saved.

Write [MSGLIST]
W [MSGLIST]
     Similar to Save, except that only message body (without the header) is saved.

mbox [MSGLIST]
mb [MSGLIST]
touch [MSGLIST]
tou [MSGLIST]
     Mark list of messages to be saved in the user's mailbox ($HOME/mbox) upon exiting via quit command.  This is the default action for all read messages, unless you have variable hold set.

copy [[MSGLIST] FILE]
c [[MSGLIST] FILE]
     Similar to save, except that saved messages are not marked for deletion.

Copy [MSGLIST]
C [MSGLIST]
     Similar to Save, except that saved messages are not marked for deletion.

Editing Messages
................

These command allow to edit messages in a mailbox.  Please note, that modified messages currently do not replace original ones. i.e. you have to save them explicitly using your editor's save command if you do not want the effects of your editing to be lost.

edit [MSGLIST]
e [MSGLIST]
     Edits each message in MSGLIST with the editor, specified in EDITOR environment variable.

visual [MSGLIST]
v [MSGLIST]
     Edits each message in MSGLIST with the editor, specified in VISUAL environment variable.

Aliasing
........

alias [alias [ADDRESS...]]
a [alias [ADDRESS...]]
group [alias [ADDRESS...]]
g [alias [ADDRESS...]]
     With no arguments, prints out all currently-defined aliases. With one argument, prints out that alias. With more than one argument, creates a new alias or changes an old one.

unalias [ALIAS...]
una [ALIAS...]
     Takes a list of names defined by alias commands and discards the remembered groups of users.  The alias names no longer have any significance.

alternates NAME...
alt NAME...
     The alternates command is useful if you have accounts on several machines.  It can be used to inform mail that the listed addresses are really you.  When you reply to messages, mail will not send a copy of the message to any of the addresses listed on the alternates list. If the alternates command is given with no argument, the current set of alternate names is displayed.

Replying
........

mail [ADDRESS...]
m [ADDRESS...]
     Switches to compose mode.  After composing the message, sends messages to the specified addresses.

reply [MSGLIST]
respond [MSGLIST]
r [MSGLIST]

     For each message in MSGLIST, switches to compose mode and sends the composed message to the sender and all recipients of the message.

Reply [MSGLIST]
Respond [MSGLIST]
R [MSGLIST]

     Like reply, except that the composed message is sent only to originators of the specified messages.

     Notice, that setting mail variable flipr (see Mail Variables) swaps the meanings of the two above commands, so that reply sends the message to the sender and all recipients of the message, whereas Reply sends it to originators only.

followup [MSGLIST]
fo [MSGLIST]

     Switches to compose mode.  After composing, sends the message to the originators and recipients of all messages in MSGLIST.

Followup [MSGLIST]
F [MSGLIST]

     Similar to followup, but reply message is sent only to originators of messages in MSGLIST.

To determine the sender of the message mail uses the list of sender fields (see Controlling Sender Fields).  The first field from this list is looked up in message headers.  If it is found and contains a valid email address, this address is used as the sender address.  If not, the second field is searched and so on.  This process continues until a field is found in the headers, or the sender field list is exhausted, whichever happens first.

If the previous step did not determine the sender address, the address from SMTP envelope is used.

Let's illustrate this.  Suppose your mailbox contains the following:

      U  1 block@helsingor.org  Fri Jun 30 18:30  8/245    Re: The Sa
     & Print 1
     From: Antonius Block <block@helsingor.org>
     To: Smeden Plog <plog@helsingor.org>
     Date: Tue, 27 Apr 2004 13:23:41 +0300
     Reply-To: <root@helsingor.org>
     Subject: News

     Hi

Now, you issue the following commands:

     & sender mail-followup-to reply-to from
     & reply
     To: <root@helsingor.org>
     Subject: Re: News

As you see, the value of Reply-To field was taken as the sender address.

Now, let's try the following command sequence:

     # Clear the sender list
     & nosender
     # Set new sender list
     & sender From

Now, the From address will be taken:

     & reply
     To: Antonius Block <block@helsingor.org>
     Subject: Re: News

Controlling Sender Fields
.........................

Commands sender and nosender are used to manipulate the contents of the sender field list.

If the command sender is used without arguments, it displays the contents of the sender field list.  If arguments are given, each argument is appended to the sender field list.  For example:

     & sender
     Sender address is obtained from the envelope
     & sender mail-followup-to reply-to
     & sender
     mail-followup-to
     reply-to
     & sender from
     & sender
     mail-followup-to
     reply-to
     from

Command nosender is used to remove items from the sender field list:

     & sender
     mail-followup-to
     reply-to
     from
     & nosender reply-to
     & sender
     mail-followup-to
     from

When used without arguments, this command clears the list:

     & nosender
     Sender address is obtained from the envelope

Incorporating New Mail
......................

The incorporate (inc) command incorporates newly arrived messages to the displayed list of messages.  This is done automatically before returning to mail command prompt if the variable autoinc is set.

Shell Escapes
.............

To run arbitrary shell command from mail command prompt, use shell (sh) command.  If no arguments are specified, the command starts the user login shell.  Otherwise, it uses its first argument as a file name to execute and all subsequent arguments are passed as positional parameters to this command.  The shell command can also be spelled as !.

Scripting
---------

Comments
........

The # character introduces an end-of-line comment.  All characters until and including the end of line are ignored.

Displaying Arbitrary Text
.........................

The echo (ec) command prints its arguments to stdout.

Sourcing External Command Files
...............................

The command source FILENAME reads commands from the named file.  Its minimal abbreviation is so.

Setting and Unsetting the Variables
...................................

The mail variables are set using set (se) command.  The command takes a list of assignments.  The syntax of an assignment is

NAME=STRING
     Assign a string value to the variable.  If STRING contains whitespace characters it must be enclosed in a pair of double-quote characters (")

NAME=NUMBER
     Assign a numeric value to the variable.

NAME
     Assign boolean True value.

noNAME
     Assign boolean False value.

Example:

     & set askcc nocrt indentprefix="> "

This statement sets askcc to True, crt to False, and indentprefix to ``> ''.

To unset mail variables use unset(uns) command.  The command takes a list of variable names to unset.

Example: To undo the effect of the previous example, do:

     & unset askcc crt indentprefix

When used without arguments, both set or unset list all currently defined variables.  The form of this listing is controlled by variable-pretty-print (varpp) variable.  If it is set, a description precedes each variable, e.g.:

     # prompt user for subject before composing the message
     ask
     # prompt user for cc before composing the message
     askcc
     # output character set for decoded header fields
     charset="auto"
     # number of columns on terminal screen
     columns=80

If variable-pretty-print is not set, only the settings are shown, e.g.:

     ask
     askcc
     charset="auto"
     columns=80

A special command is provided to list all internal mail variables:

     variable [NAMES...]

If used without arguments, it prints all known internal variables.  If arguments are given, it displays only those internal variables that are listed in command line.  For each variable, this command prints its name, data type, current value and a short description.  For example:

     & variable ask datefield
     ask, asksub
     Type: boolean
     Current value: yes
     prompt user for subject before composing the message

     datefield
     Type: boolean
     Current value: [not set]
     get date from the `Date:' header, instead of the envelope

Setting and Unsetting Shell Environment Variables
.................................................

Shell environment may be modified using setenv (sete) command.  The command takes a list of assignments.  The syntax of an assignment is:

NAME=VALUE
     If variable NAME does not already exist in the environment, then it is added to the environment with the value VALUE. If NAME does exist, then its value in the environment is changed to VALUE.

NAME
     Delete the variable NAME from the environment (``unset'' it).

Conditional Statements
......................

The conditional statement allows to execute a set of mail commands depending on the mode the mail program is in.  The conditional statement is:

     if COND
     ...
     else
     ...
     endif

where ... represents the set of commands to be executed in each branch of the statement.  COND can be one of the following:

s
     True if mail is operating in mail sending mode.

r
     True if mail is operating in mail reading mode.

t
     True if stdout is a terminal device (as opposed to a regular file).

The conditional statements can be nested to arbitrary depth.  The minimal abbreviations for if, else and endif commands are i, el and en.

Example:

     if t
     set crt prompt="& "
     else
     unset prompt
     endif
     if s
     alt gray@farlep.net gray@mirddin.farlep.net
     set

How to Alter the Behavior of mail
---------------------------------

Following variables control the behavior of GNU mail:

append

     Type: Boolean, Read-Only

     Default: True

     Messages saved in mbox are appended to the end rather than prepended. This is the default and cannot be changed.  This variable exists only for compatibility with other mailx implementations.

appenddeadletter

     Type: Boolean.

     Default: False.

     If this variable is True, the contents of canceled letter is appended to the user's dead.letter file.  Otherwise it overwrites its contents.

askbcc

     Type: Boolean.

     Default: False.

     When set to True the user will be prompted to enter Bcc field before composing the message.

askcc

     Type: Boolean.

     Default: True.

     When set to True the user will be prompted to enter Cc field before composing the message.

asksub

     Type: Boolean.

     Default: True in interactive mode, False otherwise.

     When set to True the user will be prompted to enter Subject field before composing the message.

autoinc

     Type: Boolean.

     Default: True.

     Automatically incorporate newly arrived messages.

autoprint

     Type: Boolean.

     Default: False.

     Causes the delete command to behave like dp - thus, after deleting a message, the next one will be typed automatically.

bang

     Type: Boolean.

     Default: False.

     When set, every occurrence of ! in arguments to ! command is replaced with the last executed command.

byname

     Type: Boolean

     Default: Unset

     Record outgoing messages in a file named after the first recipient. The name is the login-name portion of the address found first on the To: line in the mail header.  This variable overrides the record variable.

     It is set by the --byname (-F) command line option.

datefield

     Type: Boolean.

     Default: False.

     By default the date in a header summary is taken from the SMTP envelope of the message.  Setting this variable tells mail to use the date from Date: header field, converted to local time.  Notice, that for messages lacking this field mail will fall back to using SMTP envelope.

     See fromfield.

charset

     Type: string

     Default: auto

     The value of this variable controls the output character set for the header fields encoding using RFC 2047.  If the variable is unset, no decoding is performed and the fields are printed as they are.  If the variable is set to auto, mail tries to deduce the name of the character set from the value of LC_ALL environment variable.  Otherwise, its value is taken as the name of the charset.

cmd

     Type: String.

     Default: Unset.

     Contains default shell command for pipe.

columns

     Type: Numeric.

     Default: Detected at startup by querying the terminal device.  If this fails, the value of environment variable COLUMNS is used.

     This variable contains the number of columns on terminal screen.

crt

     Type: Boolean or Numeric

     Default: True in interactive mode, False otherwise.

     The variable crt determines the minimum number of lines the body of the message must contain in order to be piped through pager command specified by environment variable PAGER.  If crt is set to a numeric value, this value is taken as the threshold.  Otherwise, if crt is set without a value, then the height of the terminal screen is used to compute the threshold.  The number of lines on screen is controlled by screen variable.

debug

     Type: String to boolean

     Default: Not set

     Sets mailutils debug level.  If set to string, the value must be a valid Mailutils debugging specification.  See Debug Statement, for a description.

     If unset (i.e.  set nodebug), clears and disables all debugging information.  If set to true (i.e.  set debug), sets maximum debugging (<trace7) on mailbox and its underlying objects.

decode-fallback

     Type: String.

     Default: none.

     This variable controls the way to represent characters that cannot be rendered using current character set.  It can have three values:

     none
          Such characters are not printed at all.  The conversion process stops at the first character that cannot be rendered.

     copy-pass
          The characters are displayed as is.  Notice, that depending on your setup, this may screw-up your terminal settings.

     copy-octal
          Unprintable characters are represented by their octal codes.  Printable ones are printed as is.

debug

     Type: Boolean

     Default: Unset

     This variable is not used.  It exists for compatibility with other mailx implementations and for future use.

dot

     Type: Boolean.

     Default: False.

     If True, causes mail to interpret a period alone on a line as the terminator of a message you are sending.

emptystart

     Type: Boolean.

     Default: False.

     If the mailbox is empty, mail normally prints No mail for user and exits immediately.  If this option is set, mail will start no matter is the mailbox empty or not.

editheaders

     Type: Boolean.

     Default: False.

     When set, mail will include message headers in the text to be the ~e and ~v escapes, thus allowing you to customize the headers.

escape

     Type: String.

     Default: ~

     If defined, the first character of this option gives the character to denoting escapes.

flipr

     Type: Boolean

     Default: Unset

     If set, the variable flipr swaps the meanings of reply and Reply commands (see Replying).

folder

     Type: String.

     Default: Unset.

     The name of the directory to use for storing folders of messages.  If unset, $HOME is assumed.

fromfield

     Type: Boolean.

     Default: True.

     By default the sender address is taken from the From header. Unsetting this variable tells mail to obtain it from the SMTP envelope, instead.

     See datefield.

header

     Type: Boolean.

     Default: True, unless started with --nosum (-N) option.

     Whether to run headers command automatically after entering interactive mode.

headline

     Type: String

     Default: %>%a%4m %18f %16d %3l/%-5o %s

     A format string to use for the header summary.  The % character introduces a format specifier.  Valid format specifiers are:

     Letter   Meaning
     %a   Message attributes.
     %d   The date when the message was received.
     %f   The address of the message sender.
     %l   The number of lines of the message.
     %m   Message number.
     %o   The number of octets (bytes) in the message.
     %s   Message subject (if any).
     %S   Message subject (if any) in double quotes.
     %>   A > for the current message, otherwise a space.
     %<   A < for the current message, otherwise a space.
     %%   A `%' character.

     Some additional symbols are allowed between % and the specifier letter.  The - character immediately following % indicates that this field should be left aligned.  Similarly, the + character indicates right alignment.  Default alignment depends on the type of the specifier: the specifiers that produce numeric values (%l, %m, and %o) are aligned to the right, whereas the ones producing string values are aligned to the left.

     A number following % or the alignment flag, indicates the field width.  Consider, for example, the following specifiers:

     %m
          Print current message number.  Take as much screen columns as necessary to output it.

     %4m
     %+4m
          Print current message number.  Occupy 4 screen columns, truncate the output if it does not fit that width.  Align the output to the right.

     %-4m
          Same as above, but align to the left.

hold

     Type: Boolean.

     Default: False.

     When set to True, the read or saved messages will be stored in user's mailbox ($HOME/mbox).  Otherwise, they will be held in system mailbox also.  This option is in effect only when operating upon user's system mailbox.

ignore

     Type: Boolean.

     Default: False.

     When set to True, mail will ignore keyboard interrupts when composing messages.  Otherwise an interrupt will be taken as a signal to abort composing.

ignoreeof

     Type: Boolean.

     Default: False.

     Controls whether typing EOF character terminates the letter being composed.

indentprefix

     Type: String.

     Default: "\t" (a tab character).

     String used by the ~m tilde escape for indenting quoted messages.

inplacealiases

     Type: Boolean

     Default: False

     If set, mail will expand aliases in the address header field before entering send mode (see Composing Mail).  By default, the address header fields are left intact while composing, the alias expansion takes place immediately before sending message.

keep

     Type: Boolean, Read-Only

     Default: True

     Truncate the user's system mailbox when it is empty, instead of removing it.  This is the default and cannot be changed.  This variable exists only for compatibility with other mailx implementations.

keepsave

     Type: Boolean.

     Default: False.

     Controls whether saved messages should be kept in system mailbox too. This variable is in effect only when operating upon a user's system mailbox.

mailx

     Type: Boolean.

     Default: False.

     When set, enables mailx compatibility mode.  This mode has the following effects:

       * When composing a message mail will ask for Cc and Bcc addresses after composing the body. The default behavior is to ask for these values before composing the body.

       * In send mode, if the composition was interrupted, mail will exit with zero status.  By default it exits with zero status only if the message was sent successfully.

metamail

     Type: Boolean or String.

     Default: True.

     This variable controls operation of decode command.  If it is unset, decode will not attempt any interpretation of the content of message parts.  Otherwise, if metamail is set to true, decode will use internal metamail support to interpret message parts.  Finally, if metamail is assigned a string, this string is treated as command line of the external metamail command which will be used to display parts of a multipart message.  For example:

          # Disable MIME interpretation:
          set nometamail
          # Enable built-in MIME support:
          set metamail
          # Use external program to display MIME parts:
          set metamail="metamail -m mail -p"

mimenoask

     Type: String

     Default: Empty

     By default mail asks for confirmation before running interpreter to view a part of the multi-part message.  If this variable is set, its value is treated as a comma-separated list of MIME types for which no confirmation is needed.  Elements of this list may include shell-style globbing patterns, e.g. setting

          set mimenoask=text/*,image/jpeg

     will disable prompting before displaying any textual files, no matter what their subtype is, and before displaying files with type image/jpeg.

metoo

     Type: Boolean.

     Default: False.

     Usually, when an alias is expanded that contains the sender, the sender is removed from the expansion.  Setting this option causes the sender to be included in the group.

mode

     Type: String, Read-Only

     Default: The name of current operation mode.

     This variable keeps the name of the current operation mode.  Its possible values are:

     headers
          The program is started with the --headers (-H) command line option (see Invoking Mail).

     exist
          The program is started with the --exist (-e) command line option (see Invoking Mail).

     print
          The program is started with the --print (-p) command line option (see Invoking Mail).

     read
          The progran operates in read mode.  This is the default.

     send
          The program operates in send mode.  This means it was given one or more recipient addresses in the command line.

nullbody

      Type: Boolean

      Default: True

     Controls whether mail accepts messages with an empty body.  The default value, true, means such messages are sent, and a warning (traditionally saying Null message body; hope that's ok) is displayed.  The text of the warning can be set using nullbodymsg variable (see below).

     If nullbody is unset, mail will silently ignore such messages.  This can be useful in crontab files, to avoid sending mails when nothing important happens.  For example, the crontab entry below will send mail only if the utility some-prog outputs something on its standard output or error:

          */5 * * * * some-prog 2>&1 | \
             /bin/mail -E'set nonullbody' -s 'Periodic synchronization'

showenvelope

     Type: Boolean

     Default: Unset

     If this variable is set, the print command will include the STMP envelope in its output.

nullbodymsg

     Type: String

     Default: Null message body; hope that's ok

     Keeps the text of the warning, displayed by mail before sending an empty message.  When available, the translation of this text, in accordance with the current locale, is displayed.

     Unsetting this variable disables the warning.

onehop

     Type: Boolean

     Default: Unset

     This variable is not used.  It exists for compatibility with other mailx implementations and for future use.

outfolder

     Type: String.

     Default: Unset.

     Contains the directory in which files created by save, write, etc. commands will be stored.  When unset, current directory is assumed.

page

     Type: Boolean.

     Default: False.

     If set to True, the pipe command will emit a linefeed character after printing each message.

prompt

     Type: String.

     Default: "? "

     Contains the command prompt sequence.

quiet

     Type: Boolean

     Default: Unset

     This variable is not used.  It exists for compatibility with other mailx implementations and for future use.

quit

     Type: Boolean.

     Default: False, unless started with --quit (-q) option.

     When set, causes keyboard interrupts to terminate the program.

rc

     Type: Boolean.

     Default: True, unless started with --norc (-N) option.

     When this variable is set, mail will read the system-wide configuration file upon startup.  See Mail Configuration Files.

readonly

     Type: Boolean

     Default: False

     When set, mailboxes are opened in readonly mode.  In this mode, any mail commands that alter the contents of the mailbox are disabled.  These commands include, but are not limited to: delete, save and mbox.

record

     Type: String.

     Default: Unset.

     When set, any outgoing message will be saved to the named file.

recursivealiases

     Type: Boolean

     Default: True

     When set, mail will expand aliases recursively.

regex

     Type: Boolean.

     Default: True.

     Setting this to True enables use of regular expressions in /.../ message specifications.

replyprefix

     Type: String

     Default: Re:

     Sets the prefix that will be used when constructing the subject line of a reply message.

replyregex

     Type: String

     Default: ^re: *

     Sets the regular expression used to recognize subjects of reply messages.  If the Subject header of the message matches this expression, the value of replyprefix will not be prepended to it before replying.  The expression should be a POSIX extended regular expression.  The comparison is case-insensitive.

     For example, to recognize usual English, Polish, Norwegian and German reply subject styles, use:

          set replyregex="^(re|odp|aw|ang)(\\[[0-9]+\\])?:[[:blank:]]"

     (Notice the quoting of backslash characters).

save

     Type: Boolean.

     Default: True.

     When set, the aborted messages will be stored in the user's dead.file.  See also appenddeadletter.

screen

     Type: Numeric.

     Default: Detected at startup by querying the terminal device.  If this fails, the value of environment variable LINES is used.

     This variable contains the number of lines on terminal screen.

sendmail

     Type: String.

     Default: sendmail:/usr/lib/sendmail

     Contains URL of the mail transport agent.

sendwait

     Type: Boolean

     Default: Unset

     This variable is not used.  It exists for compatibility with other mailx implementations and for future use.

showto

     Type: Boolean

     Default: False

     If the message was sent by the user, print its recipient address in the header summary.

Sign

     Type: String.

     Default: Unset.

     Contains the filename holding users signature.  The contents of this file is appended to the end of a message being composed by ~A escape.

sign

     Type: String.

     Default: Unset.

     Contains the user's signature.  The contents of this variable is appended to the end of a message being composed by ~a escape.  Use Sign variable, if your signature occupies more than one line.

showto

     Type: Boolean

     Default: unset

     If this variable is set, mail will show To: addresses instead of From: for all messages that come from the user that invoked the program.

subject

     Type: String.

     Default: Unset.

     Contains default subject line.  This will be used when asksub is off.

toplines

     Type: Numeric.

     Default: 5

     Number of lines to be displayed by top and Top commands.

variable-strict
varstrict

     Type: Boolean.

     Default: False.

     Setting this variable enables strict control over variable settings.  In this mode, mail refuses to set read-only variables.  Also, if the user is trying to set an unknown variable, mail prints a warning.

     See Setting and Unsetting the Variables.

variable-pretty-print
varpp

     Type: Boolean.

     Default: False.

     If this variable is set, the listing ouput by set contains short descriptions before each variable.  See Setting and Unsetting the Variables.

verbose

     Type: Boolean.

     Default: False.

     When set, the actual delivery of messages is displayed on the user's terminal.

xmailer

     Type: Boolean.

     Default: Set.

     Controls whether the header X-Mailer should be added to outgoing messages.  The default value of this header is

          X-Mailer: mail (GNU Mailutils VERSION)

Personal and System-wide Configuration Files
--------------------------------------------

Upon startup, mail reads the contents of the two command files: the system-wide configuration file, and the user's configuration file.  Each line read from these files is processed like a usual mail command.

When run with --norc (-N) option, mail does not read the contents of system-wide configuration file.  The user's file, if it exists, is always processed.

The user's configuration file is located in the user's home directory and is named .mailrc.  The location and name of the system-wide configuration file is determined when configuring the package via --with-mail-rc option.  It defaults to SYSCONFDIR/mail.rc.

messages --- Count the Number of Messages in a Mailbox
======================================================

Messages prints on standard output the number of messages contained in each folder specified in command line.  If no folders are specified, it operates upon user's system mailbox.  For each folder, the following output line is produced:

     Number of messages in FOLDER: NUMBER

where FOLDER represents the folder name, NUMBER represents the number of messages.

Following configuration file statements affect the behaviour of messages:

Statement   Reference
debug           see Debug Statement.
tls             see TLS Statement.
mailbox         see Mailbox Statement.
locking         see Locking Statement.

The program accepts following command line options:

-q
--quiet
-s
--silent
     Be quiet.  Display only number of messages per mailbox, without leading text.

-?
--help
     Output help message and exit.

--usage
     Output short usage summary and exit.

-V
--version
     Output program version and exit.

movemail --- Moves Mail from the User Maildrop to the Local File
================================================================

The purpose of movemail, as its name implies, is to move mail from one location to another.  For example, the following invocation:

     movemail /var/mail/smith INBOX

moves messages from file /var/mail/smith to file INBOX.

You will probably never have to run this program manually.  It is intended as a replacement for movemail from GNU Emacs.  The movemail program is run by Emacs Rmail module.  See Rmail (Reading Mail with Rmail), for detailed description of Rmail interface.

Mailutils version of movemail is fully backward-compatible with its Emacs predecessor, so it should run flawlessly with older versions of Emacs.  Emacs versions starting from 22.1 contain improved Rmail interface and are able to take advantage of all new features mailutils movemail provides.

Movemail Configuration
----------------------

Following configuration file statements affect the behavior of movemail:

 -- Movemail Config: preserve BOOL
     If BOOL is true, do not remove messages from the source mailbox.

 -- Movemail Config: reverse BOOL
     If BOOL is true, reverse message sorting order.

 -- Movemail Config: emacs BOOL
     If BOOL is true, output information used by Emacs rmail interface.

 -- Movemail Config: ignore-erros BOOL
     Continue moving messages after errors.  By default, mailfromd exits immediately if it cannot copy a message.

 -- Movemail Config: program-id FMT
     Set program identifier, i.e. a string which will prefix all diagnostic messages issued by the program.  By default, program name is used.

     The FMT is a format string that may contain references to the following macro variables (-pxrefmacro-variables):

     progname
          The program name.

     source
          URL of the source mailbox.

     source:user
          User part of the source mailbox URL.

     source:host
          Host part of the source mailbox URL.

     source:path
          Path part of the source mailbox URL.

     dest
          URL of the destination mailbox

     dest:user
          User part of the destination mailbox URL.

     dest:host
          Host part of the destination mailbox URL.

     dest:path
          Path part of the destination mailbox URL.

     Setting program-id may be necessary if several movemail instances are run simultaneously (e.g. invoked from a script) to discern between the instances.  For example:

          program-id "${progname}: ${source} => ${dest}"

 -- Movemail Config: uidl BOOL
     Avoid copying the message if a message with the same UIDL already exists in the destination mailbox.

 -- Movemail Config: verbose LEVEL
     Set verbosity level.

 -- Movemail Config: mailbox-ownership METHOD-LIST
     Define list of methods for setting ownership of the destination mailbox.  The METHOD-LIST argument can contain the following elements:

     copy-id
          Copy owner UID and GID from the source mailbox.  This method works only with local mailboxes, i.e.: mbox (UNIX mailbox), maildir and mh.

     copy-name
          Get owner name from the source mailbox URL and obtain UID and GID for this user using mailutils authorization methods.

     set-id=UID[:GID]
          Set supplied UID and GID.  If GID is not supplied, it is read from the /etc/passwd record for this UID.

     set-name=USER
          Make destination mailbox owned by USER.

Statement   Reference
debug           see Debug Statement.
tls             see TLS Statement.
mailbox         see Mailbox Statement.
locking         see Locking Statement.
pam             see PAM Statement.
sql             see SQL Statement.
virtdomain      see Virtdomain Statement.
radius          see Radius Statement.
ldap            see LDAP Statement.
auth            see Auth Statement.

Movemail Options
----------------

This subsection discusses movemail options from the point of view of an Emacs Rmail user.

To set various options to movemail from Rmail, use rmail-movemail-flags variable, or Rmail Movemail Flags section from the menu.

Some POP servers return messages in reversed order.  To fix the order, use -p option or its synonym --reverse.

If the remote server supports TLS encryption, use --tls to instruct movemail to initiate encrypted connection.

Setting Destination Mailbox Ownership
-------------------------------------

Movemail Usage Summary
----------------------

     movemail [OPTION...] INBOX DESTFILE [REMOTE-PASSWORD]

The first argument, INBOX, is the url (-pxrefURL) of the source mailbox.  The second argument, DESTFILE, traditionally means destination file, i.e. the UNIX mailbox to copy messages to.  However, mailutils movemail extends the meaning of this parameter.  You may actually specify any valid URL as DESTFILE parameter. (Rmail does not use this feature).  Finally, optional third argument is a traditional way of specifying user passwords for remote (POP or IMAP) mailboxes.

Following is the summary of available command line options:

--emacs
     Output information used by Emacs rmail interface

--ignore-errors
     Continue moving messages after an error occurs.

-p
--preserve
--keep-messages
     Preserve the source mailbox

--program-id=FMT
     Set program identifier for diagnostic purposes.  See program-id, for a detailed discussion of this feature.

-r
--reverse
     Reverse the sorting order

--tls[=BOOL]
     Enable (default) or disable TLS support

-u

--uidl
     Use UIDLs to avoid downloading the same message twice.

-P METHOD-LIST
--owner=METHOD-LIST
     Define list of methods for setting ownership of the destination mailbox.  See mailbox-ownership-methods, for a description of METHOD-LIST.  This option is useful only when running movemail as root.

-v

--verbose
     Increase verbosity level.

readmsg --- Extract Messages from a Folder
==========================================

The readmsg utility extracts messages from a mailbox according to the criteria specified in the command line.  These criteria are:

 1. A lone * means ``select all messages in the mailbox''.

 2. A list of message numbers may be specified.  Values of  0  and $ in the list both mean the last message in the mailbox.  For example:

          readmsg 1 3 0

     extracts three messages from the folder: the first, the third, and the last.

 3. Finally, the selection may be some text to match.  This will select a mail message which exactly matches the specified text.  For example,

          readmsg staff meeting

     extracts the message which contains the words staff meeting. Note that it will not match a message containing Staff Meeting -- the matching is case sensitive.  Normally only the first message which matches the pattern is printed.

Invocation of readmsg.
----------------------

-a
--show-all
     If a pattern is use for selection show all messages that match pattern by default only the first one is presented.

-d
--debug
     Display mailbox debugging information.

-f MAILBOX
--folder=MAILBOX
     Specified the default mailbox.

-h
--header
     Show the entire header and ignore the weedlist.

-n
--no-header
     Do not print the message header.

-p
--form-feed
     Put form-feed (Control-L) between messages instead of newline.

-w WEEDLIST
--weedlist=WEEDLIST
     A whitespace or coma separated list of header names to show per message. Default is --weedlist="From Subject Date To CC Apparently-".

Configuration of readmsg.
-------------------------

Following configuration statements affect the behavior of readmsg:

 -- Readmsg Conf: header BOOL
     If BOOL is true, display entire headers.

 -- Readmsg Conf: weedlist STR
     Set the weedlist.  The STR argument is a string, containing a list of header names, separated by whitespace, commands or colons.  This corresponds to the --weedlist command line option (see --weedlist).

 -- Readmsg Conf: no-header BOOL
     If BOOL is true, exclude all headers.

 -- Readmsg Conf: form-feeds BOOL
     If BOOL is true, output formfeed character between messages.

 -- Readmsg Conf: folder URL
     Set the URL of the mailbox folder to read.

 -- Readmsg Conf: show-all-match BOOL
     If BOOL is true, print all messages matching pattern, not only the first.

Statement   Reference
debug           see Debug Statement.
tls             see TLS Statement.
mailbox         see Mailbox Statement.
locking         see Locking Statement.

sieve
=====

Sieve is a language for filtering e-mail messages at time of final delivery, described in RFC 3028.  GNU Mailutils provides two implementations of this language: a stand-alone sieve interpreter and a sieve translator and filter.  The following sections describe these utilities in detail.

A Sieve Interpreter
-------------------

Sieve interpreter sieve allows to apply Sieve scripts to an arbitrary number of mailboxes.  GNU sieve implements a superset of the Sieve language as described in RFC 3028.  See Sieve Language, for a description of the Sieve language.  See GNU Extensions, for a discussion of differences between the GNU implementation of Sieve and its standard.

Invoking sieve
..............

The sieve invocation syntax is:

     sieve [OPTIONS] SCRIPT

where SCRIPT denotes the filename of the sieve program to parse, and OPTIONS is one or more of the following:

-c
--compile-only
     Compile script and exit.

--clear-library-path
--clearpath
     Clear Sieve library path.  See also clear-library-path.

--clear-include-path
     Clear Sieve include path.  See also clear-include-path.

-d[FLAGS]
--debug[=FLAGS]
     Specify debug flags.  The FLAGS argument is a sequence of one or more of the following letters:

     g   Enable main parser traces
     T   Enable mailutils traces
     P   Trace network protocols
     t   Enable sieve trace
     i   Trace the program instructions

-D
--dump
     Compile the script, dump disassembled code on standard output and exit.

-e ADDRESS
--email ADDRESS
     Override the user email address.  This is useful for reject and redirect actions.  By default, the user email address is deduced from the user name and the full name of the machine where sieve is executed.  See also email.

-I DIR
--includedir=DIR
     Append directory DIR to the list of directories searched for include files.  See also include-path.

-f
--mbox-url=MBOX
     Mailbox to sieve (defaults to user's system mailbox).  See also mbox-url.

-k
--keep-going
     Keep on going if execution fails on a message.  See also keep-going.

-L DIR

--libdir=DIR
     Append directory DIR to the list of directories searched for library files.  See also library-path.

-n
--no-actions
     Dry run: do not execute any actions, just print what would be done.

-t TICKET
--ticket=TICKET
     Ticket file for mailbox authentication.  See also ticket.

-v
--verbose
     Log all actions executed.  See also verbose.

Sieve Configuration
...................

The behavior of sieve is affected by the following configuration statements:

Statement   Reference
debug           see Debug Statement.
tls             see TLS Statement.
mailbox         see Mailbox Statement.
locking         see Locking Statement.
logging         see Logging Statement.
mailer          see Mailer Statement.

The following statements configure sieve-specific features:

 -- Sieve Conf: sieve { ...  }
     This block statement configures search paths sieve uses to locate its loadable modules.  See Require Statement, for a detailed information of this feature.

     This statement may contain the following sub-statements: clear-library-path, clear-include-path, library-path, include-path, which are described below.

 -- Sieve Conf: clear-library-path BOOL
     Used within the sieve block statement.

     If BOOL is true, clear library search path.

 -- Sieve Conf: clear-include-path BOOL
     Used within the sieve block statement.

     If BOOL is true, clear include search path.

 -- Sieve Conf: library-path PATH
     Used within the sieve block statement.

     Add directories to sieve library search path.  Argument is a string containing a colon-separated list of directories.

 -- Sieve Conf: include-path PATH
     Used within the sieve block statement.

     Add directories to the include search path.  Argument is a string containing a colon-separated list of directories.

 -- Sieve Conf: keep-going BOOL
     If BOOL is true, do not abort if execution of a Sieve script fails on a particular message.

 -- Sieve Conf: mbox-url URL
     Sets URL of the mailbox to be processed.

 -- Sieve Conf: ticket FILE
     Sets the name of the ticket file for user authentication.

 -- Sieve Conf: debug FLAGS
     Sets Sieve debug flags.  See Logging and Debugging, for a detailed description.

 -- Sieve Conf: verbose BOOL
     If BOOL is true, log all executed actions.

 -- Sieve Conf: line-info BOOL
     If BOOL is true, print source locations along with action logs.  This statement takes effect only if verbose true is also set.

 -- Sieve Conf: email ADDR
     Set user e-mail address.  This is useful for reject and redirect actions.  By default, the user email address is deduced from the user name and the full name of the machine where sieve is executed.

Logging and debugging
.....................

The default behavior of sieve is to remain silent about anything except errors.  However, it is sometimes necessary to see which actions are executed and on which messages.  This is particularly useful when debugging the sieve scripts.  The --verbose (-v) option outputs log of every action executed.

Option --debug allows to produce even more detailed debugging information.  This option takes an argument specifying the debugging level to be enabled.  The argument can consist of the following letters:

t
     This flag enables sieve tracing.  It means that every test will be logged when executed.

T
     This flag enables debugging of underlying mailutils library.

P
     Trace network protocols: produces log of network transactions executed while running the script.

g
     Enable main parser traces.  This is useful for debugging the sieve grammar.

i
     Trace the program instructions.  It is the most extensive debugging level.  It produces the full execution log of a sieve program, showing each instruction and states of the sieve machine.  It is only useful for debugging the code generator.

Note, that there should be no whitespace between the short variant of the option (-d), and its argument.  Similarly, when using long option (--debug), its argument must be preceded by equal sign.

If the argument to --debug is omitted, it defaults to TPt.

Option --dump produces the disassembled dump of the compiled sieve program.

By default sieve output all diagnostics on standard error and verbose logs on standard output.  This behaviour is changed when --log-facility is given in the command line (-pxreflogging). This option causes sieve to output its diagnostics to the given syslog facility.

Extending sieve
...............

The basic set of sieve actions, tests and comparators may be extended using loadable extensions.  Usual require mechanism is used for that.

When processing arguments for require statement, sieve uses the following algorithm:

 1. Look up the name in a symbol table.  If the name begins with comparator- it is looked up in the comparator table.  If it begins with test-, the test table is used instead.  Otherwise the name is looked up in the action table.

 2. If the name is found, the search is terminated.

 3. Otherwise, transform the name.  First, any comparator- or test- prefix is stripped.  Then, any character other than alphanumeric characters, . and , is replaced with dash (-).  The name thus obtained is used as a file name of an external loadable module.

 4. Try to load the module.  The module is searched in the following search paths (in the order given):

      1. Mailutils module directory.  By default it is $prefix/lib/mailutils.

      2. The value of the environment variable LTDL_LIBRARY_PATH.

      3. Additional search directories specified with the library-path statement (see library-path) in Sieve configuration file.

      4. Additional search directories specified with the. --libdir command line option (-pxreflibdir).

      5. Additional search directories specified with the #searchpath Sieve directive (see #searchpath).

      6. System library search path: The system dependent library search path (e.g. on Linux it is set by the contents of the file /etc/ld.so.conf and the value of the environment variable LD_LIBRARY_PATH).

     The value of LTDL_LIBRARY_PATH and LD_LIBRARY_PATH must be a colon-separated list of absolute directories, for example, "/usr/lib/mypkg:/lib/foo".

     In any of these directories, sieve first attempts to find and load the given filename.  If this fails, it tries to append the following suffixes to the file name:

      1. the libtool archive extension .la

      2. the extension used for native dynamic libraries on the host platform, e.g., .so, .sl, etc.

 5. If the module is found, sieve executes its initialization function (see below) and again looks up the name in the symbol table.  If found, search terminates successfully.

 6. If either the module is not found, or the symbol wasn't found after execution of the module initialization function, search is terminated with an error status.  sieve then displays the following diagnostic message:

          source for the required action NAME is not available

A Sieve to Scheme Translator and Filter
---------------------------------------

A Sieve to Scheme Translator sieve.scm translates a given Sieve script into an equivalent Scheme program and optionally executes it.  The program itself is written in Scheme and requires presence of Guile version 1.8 or newer on the system.  For more information on Guile refer to Overview (The Guile Reference Manual).

-f FILENAME
--file FILENAME
     Set input file name.

-o FILENAME
--output FILENAME
     Set output file name

-L DIRNAME
--lib-dir DIRNAME
     Set sieve library directory name

-d LEVEL
--debug LEVEL
     Set debugging level

The Scheme programs produced by sieve.scm can be used with guimb or maidag.

guimb --- A Mailbox Scanning and Processing Language
====================================================

Guimb is for mailboxes what awk is for text files. It processes mailboxes, applying the user-supplied scheme procedures to each of them in turn and saves the resulting output in mailbox format.

The following configuration statements affect the behavior of guimb:

Statement   Reference
debug           see Debug Statement.
mailbox         see Mailbox Statement.
locking         see Locking Statement.

Specifying Scheme Program to Execute
------------------------------------

The Scheme program or expression to be executed is passed to guimb via the following options:

-s FILE
--source FILE
     Load Scheme source code from FILE.

-c EXPR
--code EXPR
     Execute given scheme expression.

The above switches stop further argument processing, and pass all remaining arguments as the value of (command-line).

If the remaining arguments must be processed by guimb itself, use following options:

-e EXPR
--expression EXPR
     Execute scheme expression.

-f FILE
--file FILE
     Load Scheme source code from FILE.

You can specify both of them.  In this case, the FILE is read first, then EXPR is executed.  You may still pass any additional arguments to the script using --guile-arg option.

Specifying Mailboxes to Operate Upon
------------------------------------

There are four basic ways of passing mailboxes to guimb.

guimb [OPTIONS] [MAILBOX...]
     The resulting mailbox is not saved, unless the user-supplied scheme program saves it.

guimb [OPTIONS] --mailbox DEFMBOX
     The contents of DEFMBOX is processed and is replaced with the resulting mailbox contents.  Useful for applying filters to user's mailbox.

guimb [OPTIONS] --mailbox DEFMBOX MAILBOX [MAILBOX...]
     The contents of specified mailboxes is processed, and the resulting mailbox contents is appended to DEFMBOX.

guimb [OPTIONS] --user USERNAME [MAILBOX...]
     The contents of specified mailboxes is processed, and the resulting mailbox contents is appended to the user's system mailbox.  This allows to use guimb as a mail delivery agent.

If no mailboxes are specified in the command line, guimb reads and processes the system mailbox of the current user.

Passing Options to Scheme
-------------------------

Sometimes it is necessary to pass some command line options to the scheme procedure.  There are three ways of doing so.

When using --source (-s) or --code (-c) options, all the rest of the command line following the option's argument is passed to Scheme program verbatim.  This allows for making guimb scripts executable by the shell.  If your system supports #! magic at the start of scripts, add the following two lines to the beginning of your script to allow for its immediate execution:

     #! /usr/local/bin/guimb -s
     !#

(replace /usr/local/bin/ with the actual path to the guimb).

Otherwise, if you use --file or --expression options, the additional arguments may be passed to the Scheme program -g (--guile-arg) command line option.  For example:

     guimb --guile-arg -opt --guile-arg 24 --file PROGFILE

In this example, the scheme procedure will see the following command line:

     PROGFILE -opt 24

Finally, if there are many arguments to be passed to Scheme, it is more convenient to enclose them in -{ and -} escapes:

     guimb -{ -opt 24 -} --file PROGFILE

Command Line Option Summary
---------------------------

This is a short summary of the command line options available to guimb.

-d
--debug
     Start with debugging evaluator and backtraces.

-e EXPR
--expression EXPR
     Execute given Scheme expression.

-m PATH
--mail-spool=PATH
     Set path to the mailspool directory

-f PROGFILE
--file PROGFILE
     Read Scheme program from PROGFILE.

-g ARG
--guile-command ARG
     Append ARG to the command line passed to Scheme program.

-{ ... -}
     Pass all command line options enclosed between -{ and -} to Scheme program.

-m
--mailbox MBOX
     Set default mailbox name.

-u
--user NAME
     Act as local MDA for user NAME.

-h
--help
     Display help message.

-v
--version
     Display program version.

maidag
======

The name maidag stands for Mail delivery agent.  It is a general-purpose MDA offering a rich set of features.  It can operate both in traditional mode, reading the message from its standard input, and in LMTP mode.  Maidag is able to deliver mail to any mailbox format, supported by GNU Mailutils.  These formats, among others, include remote+smtp, remote+prog and remote+sendmail which are equivalent to forwarding a message over SMTP to a remote node.  Thus, maidag supersedes both mail.local and mail.remote utilities from GNU Mailutils versions prior to 2.0.

Maidag is also able to process incoming messages using Sieve, Scheme or Python scripts and, based on results of this processing, to take a decision on whether to actually deliver and where to deliver them.  Due to its extensive scripting facilities, maidag offers much more flexibility than other popular MDAs, such as procmail.

Using maidag with Sendmail.
---------------------------

When used as a MDA with Sendmail, maidag must be invoked from the local mailer definition in the sendmail.cf file.  It must have the following flags set: lswS.  These mean: the mailer is local, quote characters should be stripped off the address before invoking the mailer, the user must have a valid account on this machine and the userid should not be reset before calling the mailer.  Additionally, the flags fn may be specified to allow maidag to generate the usual From  envelope instead of the one supplied by sendmail.

If you wish to use maidag with non-local authentication, such as SQL or LDAP, you also need to remove the w flag, since in that case the user is not required to have a valid account on the machine that runs sendmail.

Here is an example of mailer definition in sendmail.cf

     Mlocal, P=/usr/local/sbin/maidag,
             F=lsDFMAw5:/|@qSPfhn9,
             S=EnvFromL/HdrFromL, R=EnvToL/HdrToL,
             T=DNS/RFC822/X-Unix,
             A=mail $u

To define local mailer in mc source file, it will suffice to set:

     define(`LOCAL_MAILER_PATH', `/usr/local/sbin/maidag')
     define(`LOCAL_MAILER_ARGS', `mail $u')

Using maidag with Exim.
-----------------------

Using maidag with Exim is quite straightforward.  The following example illustrates the definition of the appropriate transport and director in exim.conf:

     # transport
     maidag_pipe:
       driver = pipe
       command = /usr/local/sbin/maidag $local_part
       return_path_add
       delivery_date_add
       envelope_to_add

     # director
     maidag:
       driver = localuser
       transport = maidag_pipe

Using maidag with MeTA1.
------------------------

MeTA1 (http://meta1.org) communicates with the delivery agent using LMTP.

LMTP mode is enabled in maidag by the lmpt yes statement.  The socket to listen on must be specified using server statement (see Server Settings).  For the purposes of this section, let's suppose maidag will listen on a UNIX socket /var/spool/meta1/lmtpsock.  Then, the following (minimal) maidag configuration will do the job:

     # Start in LMTP mode.
     lmtp yes;
     # Run as daemon.
     mode daemon;
     # Switch to this group after startup.
     group meta1c;
     # Configure server:
     server unix:///var/spool/meta1/lmtpsock {
       transcript no;
     };

To configure MeTA1 to use this socket, add the following statement to the smtpc section in /etc/meta1/meta1.conf:

       LMTP_socket="lmtpsock";

Mailbox Quotas
--------------

Mailbox quota is a limit on the size of the mailbox.  When a mailbox size reaches this limit, maidag stops accepting messages for this recipient and returns an error condition to the sender.  The error code is accompanied by the following error message:

     USER: mailbox quota exceeded for this recipient

Furthermore, if accepting the incoming message would make the mailbox size exceed the quota, such a message will be rejected as well.  In this case, the error message is:

     USER: message would exceed maximum mailbox size for this recipient

In both cases, the default return code will be service unavailable (corresponding to the SMTP return code 550), unless the following statement is present in the maidag configuration file:

     exit-quota-tempfail yes;

in which case a temporary error will be returned.

The mailbox quota can be retrieved from the following sources:

 1. Authentication method.

 2. DBM file.

 3. SQL database.

Keeping Quotas in DBM File
..........................

To use DBM quota database, GNU Mailutils must be compiled with one of the following command line options: --with-gdbm, --with-berkeley-db, --with-ndbm, --with-tokyocabinet, or --with-kyotocabinet. Examine the output of maidag --show-config-options, if not sure.

The quota database should have the following structure:

Key
     Key represents the user name.  Special key DEFAULT means default quota value, i.e. the one to be used if the user is not explicitly listed in the database.

Value
     Mailbox quota for this user.  If it is a number, it represents the maximum mailbox size in bytes.  A number may optionally be followed by kb or mb, meaning kilobytes and megabytes, respectively.

     A special value NONE means no mailbox size limit for this user.

Here is an example of a valid quota database

     # Default quota value:
     DEFAULT         5mb

     # Following users have unlimited mailbox size
     root            NONE
     smith           NONE

     # Rest of users
     plog            26214400
     karin           10mB

To use the DBM quota database, specify its absolute name using quota-db configuration statement, e.g.:

     quota-db /etc/mail/quota.db;

Keeping Quotas in SQL Database
..............................

Configuration statement quota-query allows to specify a special query to retrieve the quota from the database.  Currently (as of mailutils version VERSION) it is assumed that this table can be accessed using the credentials set in sql configuration statement (see SQL Statement).

For example, suppose you have the following quota table:

     create table mailbox_quota (
       user_name varchar(32) binary not null,
       quota int,
       unique (user_name)
     );

To retrieve user quota the following query can be used:

     SELECT quota FROM mailbox_quota WHERE user_name='${user}'

There are no special provisions for specifying group quotas, similar to DEFAULT in DBM databases.  This is because group quotas can easily be implemented using SQL language.  Maidag always uses the first tuple from the set returned by mailbox quota query.  So, you may add a special entry to the mailbox_quota table that would keep the group quota.  In the discussion below we assume that the user_name column for this entry is lexicographically less than any other user name in the table.  Let's suppose the group quota name is 00DEFAULT.  Then the following query:

     SELECT quota
     FROM mailbox_quota
     WHERE user_name IN ('${user}','00DEFAULT')
     ORDER BY user_name DESC

will return two tuples if the user is found in mailbox_quota.  Due to ORDER statement, the first tuple will contain the quota for the user, which will be used by maidag.  On the other hand, if the requested user name is not present in the table, the above query will return a single tuple containing the group quota.

The following configuration statement instructs maidag to use this query for retrieving the user quota:

     quota-query "SELECT quota "
                 "FROM mailbox_quota "
                 "WHERE user_name IN ('${user}','00DEFAULT') "
                 "ORDER BY user_name DESC";

Maidag Scripting
----------------

Maidag can use global or per-user mail filters to decide whether to deliver the message, and where to deliver it.  As of Mailutils version VERSION, such mail filters may be written in the following languages:

  * Sieve see Sieve Language.

  * Scheme

  * Python

Mail filters to use are specified using script configuration statement.  The following meta-symbols can be used in its argument:

~
%h
     Expands to the recipient home directory.

%u
     Expands to the recipient user name.

By default, a filename extension decide which scripting language will be used.  User can alter the choice using language configuration statement.  For example:

     language "python"
     script "~/.maidag-py-filter"

Sieve Maidag Filters
....................

The file name of the Sieve filter to use is specified using script configuration statement.  For example, the following configuration statement:

     script "~/.maidag.sv"

instructs maidag to use file .maidag.sv in the recipient home directory as a Sieve filter.

Normal message delivery is attempted if execution of the Sieve code ended with keep action (either implicit or explicit).

Other Sieve actions are executed as described in Actions.  For example, to deliver message to another mailbox, use the fileinto action.

Any modifications to headers or body of the message performed by the Sieve code will be visible in the delivered message.

Scheme Maidag Filters
.....................

The file name of the Scheme mail filter is specified using script configuration statement.  For example, the following configuration statement:

     script "~/.maidag.scm"

instructs `maidag' to use file `.maidag.scm' in the recipient home directory as a Scheme filter.

Python Maidag Filters
.....................

The file name of the Python mail filter is specified using script configuration statement.  For example, the following configuration statement:

     script "~/.maidag.py"

instructs `maidag' to use file `.maidag.py' in the recipient home directory as a Python filter.

A simple example of a mail filter written in Python:

     from mailutils import *
     import maidag
     import re

     msg = message.Message (maidag.message)
     hdr = msg.header

     try:
         if 'List-Post' in hdr and 'Received' in hdr \
            and hdr['Received'].find ('fencepost.gnu.org') != -1:

             # check envelope's sender address
             m = re.search (r'([\w\-]+)-bounces\+([\w]+)=.*',
                            msg.envelope.get_sender ())
             if m:
                 lbox = m.group (1)
                 user = m.group (2)
                 # open destination mailbox and append message
                 dst = mailbox.MailboxDefault ('~/Mail/%s' % lbox)
                 dst.open ('ac')
                 dst.append_message (msg)
                 dst.close ()
                 # set deleted flag so maidag will not deliver msg elsewhere
                 msg.attribute.set_deleted ()
     except Exception:
         pass

Forwarding
----------

Forward file is a special file in the user's home directory that contains the email address of the mailbox where the user wants to forward his mail.  Normally, forward files are processed by MTA.  However, there are some MTA that lack this feature.  One of them is MeTA1.

Maidag provides a forwarding feature that is useful to compensate the lack of it.

Name of the forward file is given using forward-file configuration statement.  A common usage is:

     forward-file .forward;

The forward file is always searched in the recipient home directory.

Before actually using the file, a number of safety checks are performed on it.  If the file fails to pass one of these checks, no forwarding is performed and the message is delivered as usual.  These checks can be configured using forward-file-checks statement. Its argument is a list of the following keywords:

groupwritablefile
file_iwgrp
     The file must not be group writable.

worldwritablefile
file_iwoth
     The file must not be world writable.

linkedfileinwritabledir
link
     The file cannot be a symlink in a writable directory.

fileingroupwritabledir
dir_iwgrp
     The file cannot reside in a group writable directory.

fileinworldwritabledir
dir_iwoth
     The file cannot reside in a world writable directory.

all
     All of the above checks.

The default is forward-file-checks all.

Each of these keywords may be prefixed by no to disable this particular check.  For example:

     forward-file-checks (nodir_iwoth, nodir_iwgrp);

Delivering Messages to a URL.
-----------------------------

When invoked with the --url command line option, maidag treats its arguments as a list of mailbox URLs and attempts to deliver the message to each of them.

For example:

     $ maidag --url maildir:///home/smith/Mail

Remote Mailbox Delivery
-----------------------

Maidag can be used to deliver mail to remote mailboxes, such as imap or remote+smtp.  If the mailbox URL is remote+smtp or remote+sendmail, the message is actually forwarded over SMTP to the remote node, so maidag acts as a message transfer agent.  For example:

     $ maidag --url remote+smtp://10.10.1.100:24

This command line will send the message to the machine 10.10.1.100 using port 24 (private mail system).

The remote+prog mailbox may be of special use.  Delivering to this mailbox results in invoking the specified command with the given arguments and passing the message to its standard input.  There are two ways to specify a remote+prog mailbox:

remote+prog://PROGRAM?ARGS
     Here, PROGRAM is the absolute pathname of the program binary, and ARGS are its arguments, separated by & signs.

|PROGRAM ARGS
     In this notation, ARGS are command line arguments separated by white space.

In both cases, ARGS do not include argv[0].

The remote+prog mailbox may be used, in particular, to implement mailing lists with MeTA1.

For example, suppose that the maidag configuration contains:

     auth {
       authorization sql:system;
       authentication generic:system;
     }

     sql {
       interface mysql;
       db mail;
       getpwnam "SELECT user as name, mailbox, "
                "'x' as passwd, 500 as uid, 2 as gid, "
                "'/nonexistent' as dir, '/sbin/nologin' as shell "
                "FROM userdb "
                "WHERE user='${user}'";
     }

Then, the following entries in the userdb table implement mailman@yourdomain mailing list:

     mysql> select * from userdb;
     +---------------------+---------------------------------------+
     | user                | mailbox                               |
     +---------------------+---------------------------------------+
     | mailman             | |/usr/bin/mailman post mailman        |
     | mailman-admin       | |/usr/bin/mailman admin mailman       |
     | mailman-bounces     | |/usr/bin/mailman bounces mailman     |
     | mailman-confirm     | |/usr/bin/mailman confirm mailman     |
     | mailman-join        | |/usr/bin/mailman join mailman        |
     | mailman-leave       | |/usr/bin/mailman leave mailman       |
     | mailman-owner       | |/usr/bin/mailman owner mailman       |
     | mailman-request     | |/usr/bin/mailman request mailman     |
     | mailman-subscribe   | |/usr/bin/mailman subscribe mailman   |
     | mailman-unsubscribe | |/usr/bin/mailman unsubscribe mailman |
     +---------------------+---------------------------------------+

Maidag Configuration File Summary
---------------------------------

The behavior of maidag is affected by the following configuration statements:

Statement   Reference
debug           see Debug Statement.
mailbox         see Mailbox Statement.
locking         see Locking Statement.
pam             see PAM Statement.
sql             see SQL Statement.
virtdomain      see Virtdomain Statement.
radius          see Radius Statement.
ldap            see LDAP Statement.
auth            see Auth Statement.
mailer          see Mailer Statement.
server          see Server Settings.  Used only in
LMTP mode.
acl             see ACL Statement.
tcp-wrappers    see Tcp-wrappers Statement.

 -- Maidag Config: ex-multiple-delivery-success BOOL
     In case of multiple delivery, exit with code 0 if at least one delivery has succeeded.

 -- Maidag Config: ex-quota-tempfail BOOL
     Indicate temporary failure if the recipient is over his mail quota. By default, permanent failure is returned.  See Mailbox Quotas.

 -- Maidag Config: quota-db FILE
     Set the name of DBM quota database file.  See DBM Quotas.

 -- Maidag Config: sieve-filter PATTERN
     Set file name or name pattern of the Sieve filter file. See Sieve Maidag Filters.

 -- Maidag Config: message-id-header NAME
     When logging Sieve actions, identify messages by the value of this header.

 -- Maidag Config: guile-filter PATTERN
     File name or name pattern for Guile filter file. See Scheme Maidag Filters.

 -- Maidag Config: debug FLAGS
     Set additional debugging flags.  Valid flags are:

     g
          Print guimb stack traces.

     t
          Enable sieve trace (MU_SIEVE_DEBUG_TRACE).

     i
          Enable sieve instructions trace (MU_SIEVE_DEBUG_INSTR).

     l
          Log executed Sieve actions.

 -- Maidag Config: stderr BOOL
     Log to stderr instead of syslog.

 -- Maidag Config: forward-file FILE
     Process forward file FILE.  See Forwarding.

 -- Maidag Config: forward-file-checks LIST
     Configure safety checks for the forward file. See forward-file-checks.

 -- Maidag Config: lmtp BOOL
     Run in LMTP mode.

 -- Maidag Config: group LIST
     In LMTP mode, retain supplementary groups from LIST.

 -- Maidag Config: listen URL
     In LMTP mode, listen on URL.  Valid URLs are: tcp://HOST:PORT (note that port is mandatory), file://SOCKET-FILE-NAME or socket://SOCKET-FILE-NAME.

 -- Maidag Config: reuse-address BOOL
     Reuse existing address (LMTP mode).  Default is yes.

mimeview
========

For each file given in its command line, mimeview attempts to autodetect its type and invoke an appropriate file viewer.

To detect the file type, mimeview uses mime.types file.  This file is a part of Common UNIX Printing System, mime.types (mime.types man page).  By default mimeview searches for mime.types in
$prefix/etc/cups/ (The exact location is determined at
configuration time by setting environment variable
DEFAULT_CUPS_CONFDIR.  On most sites running)

     ./configure DEFAULT_CUPS_CONFDIR=/etc/cups

should be recommended., however its exact location can be specified at runtime as well (see --mimetypes below).

Once file MIME type is successfully determined, mimeview consults mailcap files in order to determine how to display the file.  It does so essentially in the same manner as metamail utility, i.e., it scans all files specified in METAMAIL environment variable until it finds an entry describing the desired file format or until the list of files is exhausted.  If METAMAIL variable is not set, mimeview uses the following default path instead:

     $HOME/.mailcap:/usr/local/etc/mailcap:\
      /usr/etc/mailcap:/etc/mailcap:\
      /etc/mail/mailcap:/usr/public/lib/mailcap

Mimeview Invocation
-------------------

The following table summarizes options specific for mimeview:

-a[TYPE-LIST]
--no-ask[=TYPE-LIST]
     By default mimeview asks for confirmation before running interpreter to view a message.  If this option is used without argument, it disables the default behavior for all message types.  Otherwise, if argument TYPE-LIST is given, it specifies a comma-separated list of MIME types for which no questions should be asked.  Elements of this list may include shell-style globbing patterns, e.g. setting

          --no-ask='text/*,image/jpeg'

     will disable prompting before displaying any textual files, no matter what their subtype is, and before displaying files with type image/jpeg.

     Notice, that when the long form is used, its argument must be separated from the option by a single equal sign, as shown in the example above.  When the short form (-a) is used, its argument must follow the option immediately, without any intervening whitespace, e.g.  -a'text/*').

-d[FLAGS]
--debug[=FLAGS]
     Enables debugging output.  FLAGS is a sequence of characters specifying the desired debugging level.  Following characters are meaningful in FLAGS:

     g
          Enables debugging of mime.types parser

     l
          Enables debugging of mime.types lexical analyzer (warning: produces very copious output)

     1
          Prints basic information about actions to be executed and reports about exit status of executed commands.

     2
          Additionally displays each file name along with its MIME type

     3
          Additionally traces the process of looking up the matching entry in mailcap files.

     digits from 4 to 9
          The same as 3, currently.

     If FLAGS are not given, the default 9 is assumed.

--metamail[=FILE]
     Run metamail to display files, instead of using the internal mechanisms.  If FILE is specified, it is taken as metamail command line.

-h
--no-interactive
--print
     This options tells mimeview that it should run in non-interactive mode.  In this mode prompting is disabled, and the normal mailcap command field is not executed.  Instead mimeview will execute the command specified in the print field.  If there is nothing in the print field, the mailcap entry is ignored and the search continues for a matching mailcap entry that does have a print field.

     Notice, that unlike in metamail -h, this option does not force mimeview to send the output to the printer daemon.

     When used with --metamail option, this option passes -h flag to the invocation of metamail.

     By default mimeview behaves as if given --no-interactive option whenever its standard input is not a tty device.

-n
--dry-run
     Do not do anything, just print what would be done.  Implies --debug=1, unless the debugging level is set up explicitly.

-t FILE
--mimetypes FILE
     Use FILE as mime.types file.  If FILE is a directory, use FILE/mime.types

Mimeview Config
---------------

The following configuration statements affect the behavior of mimeview:

Statement   Reference
debug   see Debug Statement.

 -- Mimeview Config: debug NUMBER
     Set mimeview debug level.  See --debug, for a description of debug levels.

 -- Mimeview Config: mimetypes FILE
     Read FILE instead of the default mime.types.

 -- Mimeview Config: metamail PROGRAM
     Use PROGRAM to display files.

POP3 Daemon
===========

The pop3d daemon implements the Post Office Protocol Version 3 server.

pop3d has two operation modes:

Inetd
     The server is started from /etc/inetd.conf file:

          pop3  stream tcp nowait  root  /usr/local/sbin/pop3d pop3d

     This is the default operation mode.

Standalone
     The server runs as daemon, forking a child for each new connection.

The server operation mode is configured using mode statement (see mode).

Login delay
-----------

POP3 clients often login frequently to check for new mail.  Each new connection implies authenticating the user and opening his maildrop and can be very resource consuming.  To reduce server load, it is possible to impose a minimum delay between any two consecutive logins. This is called LOGIN-DELAY capability and is described in RFC 2449.

As of version VERSION, GNU Mailutils pop3d allows to set global login delay, i.e. such enforcement will affect all POP3 users.  If a user attempts to log in before the specified login delay expires, he will get the following error message:

     -ERR [LOGIN-DELAY] Attempt to log in within the minimum login delay interval

The message will be issued after a valid password is entered.  This prevents this feature from being used by malicious clients for account harvesting.

To enable the login delay capability, specify the minimum delay using login-delay configuration statement, e.g.:

     login-delay 60;

The pop3d utility keeps each user's last login time in a special DBM file, called login statistics database, so to be able to use this feature, Mailutils must be compiled with DBM support. By default, the login statistics database is called /var/run/pop3-login.db.  You can change its name using stat-file configuration statement:

     login-delay 60;
     stat-file /tmp/pop.login.db;

The login delay facility will be enabled only if pop3d is able to access the statistics database for both reading and writing.  If it is not, it will report this using syslog and start up without login delay restrictions.  A common error message looks like:

     Unable to open statistics db: Operation not permitted

You can check whether your pop3d uses login delays by connecting to it and issuing the CAPA command.  If login delays are in use, there response will contain the string LOGIN-DELAY N, where N is the actual login delay value.

Auto-expire
-----------

Automatic expiration of messages allows you to limit the period of time users are permitted to keep their messages on the server.  It is enabled by expire configuration statement:

expire N;
     Enable automatic expiration of messages after N days.

The current implementation works as follows.  When a message is downloaded by RETR or TOP command, it is marked with X-Expire-Timestamp: N header, where N is current value of UNIX timestamp.  The exact expiration mechanism depends on you.  Mailutils allows you two options:

 1. Expired messages are deleted by pop3d upon closing the mailbox.  You specify this mechanism using delete-expired configuration statement:

     delete-expired BOOL;
          If BOOL is true, delete expired messages after receiving the QUIT command.

 2. Expired messages remain in the mailbox after closing it.  The system administrator is supposed to run a cron job that purges the mailboxes. Such a cron job can be easily implemented using sieve from GNU Mailutils and the following script:

          require "timestamp";
          # Replace "5" with the desired expiration period
          if timestamp :before "X-Expire-Timestamp" "now - 5 days"
            {
              discard;
            }

     This script will remove expired messages 5 days after the retrieval.  Replace 5 with the desired expiration period and make sure it equals the argument to expire configuration keyword.

The statement expire 0 means the client is not permitted to leave mail on the server.  It always implies delete-expired true.

Bulletins
---------

The bulletin feature allows you to send important announcements to all POP3 users without mailing them.  It works by creating a bulletin source mailbox and sending the announcements to it.

After a user successfully authenticates, pop3d checks the last bulletin number the user receives.  The bulletin number refers to the number of the bulletin message in the bulletin source mailbox.  If the latter contains more messages, these are appended to the user mailbox.

The user last bulletin number can be kept in two places.  First, it can be stored in file .popbull in his home directory.  Secondly, if Mailutils is compiled with DBM support, the numbers can be kept in a DBM file, supplied via bulletin-db configuration statement.  If both the database and the .popbull file are present, the data from the database take precedence.

To enable this feature, use the following configuration statements:

bulletin-source MBOX
     Set the URL of the bulletin source mailbox.

bulletin-db FILE
     Set the name of the database file to keep last bulletin numbers in.

The following example instructs pop3d to look for the bulletin messages in MH folder /var/spool/bull/mbox and to keep the database of last delivered bulletin numbers in /var/spool/bull/numbers.db:

     bulletin-source mh:/var/spool/bull/mbox;
     bulletin-db /var/spool/bull/numbers.db;

Pop3d Configuration
-------------------

The following configuration file statements affect the behavior of pop3d.

Statement   Reference
debug           see Debug Statement.
tls             see TLS Statement.
mailbox         see Mailbox Statement.
locking         see Locking Statement.
logging         see Logging Statement.
pam             see PAM Statement.
sql             see SQL Statement.
virtdomain      see Virtdomain Statement.
radius          see Radius Statement.
ldap            see LDAP Statement.
auth            see Auth Statement.
server          see Server Settings.
acl             see ACL Statement.
tcp-wrappers    see Tcp-wrappers Statement.

 -- Pop3d Conf: undelete BOOL
     On startup, clear deletion marks from all the messages.

 -- Pop3d Conf: expire N
     Automatically expire read messages after N days.  See Auto-expire, for a detailed description.

 -- Pop3d Conf: delete-expired BOOL
     Delete expired messages upon closing the mailbox.  See Auto-expire, for a detailed description.

 -- Pop3d Conf: tls-required BOOL
     Always require STLS command before entering authentication phase.

 -- Pop3d Conf: login-delay DURATION
     Set the minimal allowed delay between two successive logins. See Login delay, for more information.

 -- Pop3d Conf: stat-file FILE
     Set the name of login statistics file for the login-delay facility.  See Login delay, for more information.

 -- Pop3d Conf: bulletin-source FILE
     Get bulletins from the specified mailbox.  See Bulletins, for a detailed description.

 -- Pop3d Conf: bulletin-db FILE
     Set bulletin database file name.  See Bulletins, for a detailed description.

Command line options
--------------------

The following table summarizes all pop3d command line options.

-d[NUMBER]
--daemon[=NUMBER]
     Run in standalone mode.  An optional NUMBER specifies the maximum number of child processes allowed to run simultaneously.  When it is omitted, it defaults to 10 processes. Please note, that there should be no whitespace between the -d and its parameter.

-i
--inetd
     Run in inetd mode.

-h
--help
     Display short help message and exit.

--foreground
     Remain in foreground.

--tls[=BOOL]
     Enable TLS.  If optional argument is supplied and is false, then disable it.

--debug-auth
     Enable debugging of authentication functions.

IMAP4 Daemon
============

GNU imap4d is a daemon implementing IMAP4 rev1 protocol for accessing and handling electronic mail messages on a server.  It can be run either as a standalone program or from inetd.conf file.

Namespace
---------

GNU imap4d supports a notion of namespaces defined in RFC 2342.  A namespace is a set of directories upon which the user has certain permissions.  It should be understood that these permissions apply only if the underlying filesystem allows them.

The three namespaces supported by imap4d are:

Personal Namespace
     A namespace that is within the personal scope of the authenticated user on a particular connection.  The user has all permissions on this namespace.

Other Users' Namespace
     A namespace that consists of mailboxes from the ``Personal Namespaces'' of other users.  The user can read and list mailboxes from this namespace.  However, he is not allowed to use % and * wildcards with LIST command, that is he can access a mailbox only if he knows exactly its location.

Shared Namespace
     A namespace that consists of mailboxes that are intended to be shared amongst users and do not exist within a user's Personal Namespace. The user has all permissions on this namespace.

By default, imap4d starts with the following namespaces:

Personal Namespace
     The home directory of the user, if exists.

Other Users' Namespace
     Empty

Shared Namespace
     Empty

Note, that this means that by default, a user won't be able to see or otherwise access mailboxes residing in the directories other than his own home.

To change these defaults, use shared-namespace and other-namespace configuration statements:

shared-namespace LIST
     Set shared namespace.

other-namespace LIST
     Set other users' namespace.

For both statements, the argument is a list of directories that belong to this namespace, e.g.:

     shared-namespace (/var/spool/mail,/var/mail);

If during the session the user creates a mailbox within either of these namespaces, the mode of the mailbox is determined by the following configuration statements:

shared-mailbox-mode MODE
     Set file mode for mailboxes created in shared namespace.

other-mailbox-mode MODE
     Set file mode for mailboxes created in other users' namespace.

In both cases, the argument, MODE is a list of symbolic mode settings, similar to that used by chmod.  It is a list of comma-separated mode change commands.  Each command begins with a letter g, which means set mode bits for file group, or o, which means set mode bits for other users (note, that there is no u specifier, since user ownership of his mailbox cannot be changed).  This letter is followed by an = (or +), and a list of modes to be set.  This list can contain only two letters: r to set read permission, and w to set write permission.

For example, the following statement sets read and write permissions for the group:

     shared-namespace-mode g=rw;

Configuration of imap4d.
------------------------

The behavior of imap4d is altered by the following configuration statements:

Statement   Reference
debug           see Debug Statement.
tls             see TLS Statement.
mailbox         see Mailbox Statement.
locking         see Locking Statement.
logging         see Logging Statement.
pam             see PAM Statement.
sql             see SQL Statement.
virtdomain      see Virtdomain Statement.
radius          see Radius Statement.
ldap            see LDAP Statement.
auth            see Auth Statement.
server          see Server Settings.
acl             see ACL Statement.
tcp-wrappers    see Tcp-wrappers Statement.

 -- Imap4d Conf: shared-namespace LIST
     Set shared namespace.  LIST is a list of strings.  See Namespace, for a detailed description.

 -- Imap4d Conf: other-namespace LIST
     Set other users' namespace.  LIST is a list of strings.  See Namespace, for a detailed description.

 -- Imap4d Conf: shared-mailbox-mode STR
     Set file mode for mailboxes created within shared namespace. See Namespace, for a detailed description.

 -- Imap4d Conf: other-mailbox-mode STR
     Set file mode for mailboxes created within other users' namespace. See Namespace, for a detailed description.

 -- Imap4d Conf: login-disabled BOOL
     Disable LOGIN command, if BOOL is true.

 -- Imap4d Conf: create-home-dir BOOL
     Create nonexistent user home directories.  See also home-dir-mode, below.

 -- Imap4d Conf: home-dir-mode MODE
     Set file mode for created user home directories.  Mode is specified in octal.

     The default value for MODE is 700 (drwx------ in ls terms).

 -- Imap4d Conf: tls-required BOOL
     Require successful STARTTLS command before entering authentication phase.

 -- Imap4d Conf: preauth MODE
     Configure PREAUTH mode.  Valid arguments are:

     prog:///PROGRAM-NAME
          Imap4d invokes an external program to authenticate the connection.  The command line is obtained from the supplied string, by expanding the following meta-variables:

          ${client_address}
               Remote IP address in dotted-quad notation;

          ${client_port}
               Remote port number;

          ${server_address}
               Local IP address;

          ${server_port}
               Local port number.

          If the connection is authenticated, the program should print the user name, followed by a newline character, on its standard output and exit with code 0.

          Otherwise, it should exit with a non-zero exit code.

     ident[://:PORT]
          The remote machine is asked about the requester identity using the identification protocol (RFC 1413).  Both plaintext and DES encrypted replies are understood.  Optional PORT specifies the port to use, if it differs from the default 113.  It can be either a decimal port number or a symbolic name of a service, listed in /etc/services.

     stdio
          PREAUTH mode is enabled automatically if imap4d is started from command line in interactive mode (-i command line option).  The current login name is used as the user name.

 -- Imap4d Conf: preauth-only BOOL
     If BOOL is true, use only preauth mode.  If unable to setup it, disconnect immediately.

 -- Imap4d Conf: ident-keyfile FILE
     Set DES keyfile for decoding encrypted ident responses.  Used with ident:// preauth mode.

 -- Imap4d Conf: ident-encrypt-only BOOL
     Use only encrypted IDENT responses.

 -- Imap4d Conf: id-fields LIST
     Set list of fields to return in response to ID command.

     Valid field names are:

     name
          Package name (GNU Mailutils).

     version
          Package version (VERSION).

     vendor
          Vendor name (GNU).

     support-url
          The string http://www.gnu.org/software/mailutils

     address
          The string 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

     os
          OS name.

     os-version
          OS version number.

     command
          Name of the imap4d binary.

     arguments
          Invocation command line.

     environment
          List of environment variables with their values.

Starting imap4d
---------------

imap4d may run either in standalone or in inetd operation modes.  When run in ``standalone'' mode, the server disconnects from the terminal and runs as a daemon, forking a child for each new connection.

The ``inetd'' mode allows to start the server from /etc/inetd.conf file.  This is the default operation mode.

     imap4  stream tcp nowait  root  /usr/local/sbin/imap4d imap4d

Command Line Options
--------------------

-d[NUMBER]
--daemon[=NUMBER]
     Run in standalone mode.  An optional NUMBER specifies the maximum number of child processes the daemon is allowed to fork.  When it is omitted, it defaults to 20 processes. Please note, that there should be no whitespace between the -d and its parameter.

-h
--help
     Display short help message and exit.

-i
--inetd
     Run in inetd mode.

--foreground
     Run in foreground.

--preauth
     Start in preauth mode

--tls[=BOOL]
     Enable TLS support

--debug-auth
     Debug authentication functions.

-v
--version
     Display program version and exit.

Comsat Daemon
=============

Comsatd is the server which receives reports of incoming mail and notifies users, wishing to get this service.  It can be started either from inetd.conf or as a standalone daemon.

Starting comsatd
----------------

Comsatd uses following option groups: -xrefmailbox, -xrefdaemon, -xreflogging.

-C FILE
--convert-config=FILE
     Convert the configuration file FILE to the new format.  FILE must be a comsatd configuration file in Mailutils v. 1.x format.  The converted file is printed on the standard output.  For example, the following command can be used to convert old comsatd configuration file to new format:

          $ comsatd --convert-config=/etc/comsatd.conf > /etc/mailutils.d/comsatd

-d
--daemon
     Run as a standalone daemon.

-i
--inetd
     The server is started from /etc/inetd.conf file:

          comsat dgram  udp wait  root  /usr/sbin/comsatd \
          comsatd -c /etc/comsat.conf

     This is the default operation mode.

-t
--test
     Test mode.  In this mode, comsatd takes two arguments: URL of a mailbox and QID of the message from that mailbox, e.g.:

          $ comsatd --test /var/mail/root 34589

Configuring comsatd
-------------------

Following configuration statements affect the behavior of comsatd:

Statement   Reference
debug     see Debug Statement.
logging   see Logging Statement.
mailbox   see Mailbox Statement.
locking   see Locking Statement.
acl       see ACL Statement.

General Settings
................

These statements control the general behavior of the comsat daemon:

 -- Comsatd Conf: max-lines NUMBER
     Set maximum number of message body lines to be output.

 -- Comsatd Conf: allow-biffrc BOOL
     Enable or disable processing of user's .biffrc file.  By default, it is enabled.

Security Settings
.................

These statements control the way comsatd fights possible flooding attacks.

 -- Comsatd Conf: max-requests NUMBER
     Set maximum number of incoming requests per request-control-interval.

 -- Comsatd Conf: request-control-interval DURATION
     Set the request control interval.

 -- Comsatd Conf: overflow-delay-time DURATION
     Set initial amount of time to sleep, after the first overflow occurs.

 -- Comsatd Conf: overflow-control-interval DURATION
     Set overflow control interval.  If two consecutive overflows happen within that interval, the overflow-delay-time is doubled.

A per-user Configuration File
-----------------------------

By default, when a notification arrives, comsatd prints subject, from headers and the first five lines from the new message to the user's tty.  The user is allowed to change this behavior by using his own configuration file.  This file should be located in the user's home directory and should be named .biffrc.  It must be owned by the user and have its permissions bits set to 0600. (Please note, that the use of per-user configuration files may be disabled, by specifying allow-biffrc no in the main configuration file, see Configuring comsatd).

The .biffrc file consists of a series of statements.  Each statement occupies one line and defines an action to be taken upon arrival of a new mail.  Very long lines may be split using \ as the last character on the line.  As usual, comments may be introduced with # character.

The actions specified in .biffrc file are executed in turn. The following actions are defined:

beep
     Produce an audible signal.

echo [-n] STRING [STRING...]
     Output the arguments to the user's terminal device.  If several arguments are given they will be output separated by single spaces.  The newline character will be printed at the end of the output, unless the -n option is used.

exec PROG ARGLIST
     Execute program PROG with arguments from ARGLIST.  PROG must be specified with absolute pathname.  It may not be a setuid or setgid program.

In the description above, STRING denotes any sequence of characters.  This sequence must be enclosed in a pair of double-quotes, if it contains whitespace characters.  The \ character inside a string starts a C escape sequence.  Following meta-characters may be used in strings:

$u
     Expands to username

$h
     Expands to hostname

$H{name}
     Expands to value of message header name.

$B(C,L)
     Expands to message body.  C and L give maximum number of characters and lines in the expansion.  When omitted, they default to 400, 5.

Example I
.........

Dump to the user's terminal the contents of From and Subject headers followed by at most 5 lines of message body.

     echo "Mail to \a$u@$h\a\n---\n\
     From: $H{from}\n\
     Subject: $H{Subject}\n\
     ---\n\
     $B(,5)\
     ---\n"

The above example can also be written as:

     echo Mail to \a$u@$h\a
     echo ---
     echo From: $H{From}
     echo Subject: $H{Subject}
     echo ---
     echo $B(,5)
     echo ---

Example II
..........

Produce a bell, then pop up the xmessage window on display :0.0 with the text formatted in the same manner as in the previous example.

     beep
     exec /usr/X11R6/bin/xmessage \
     -display :0.0 -timeout 10 "Mail to $u@$h \n---\n\
     From: $H{from}\n\
     Subject: $H{Subject}\n\
     ---\n\
     $B(,5)\
     ---\n"

MH --- The MH Message Handling System
=====================================

     [file mu-mh.texi not included]

MU
==

The mu utility is a multi-purpose tool shipped with Mailutils.  It can be used for various mail- and database-related tasks, as well as an auxiliary tool for compiling and linking programs with Mailutils.

Invocation Syntax
-----------------

Mu is a command line tool.  Its invocation syntax is:

     mu [OPTIONS] COMMAND [ARGS]

where OPTIONS are options that affect the behavior of mu as a whole, COMMAND instructs it what it is to do and ARGS are any arguments the COMMAND needs in order to be executed.

The commands are:

2047
     Decodes or encodes email message headers.

acl
     Tests Mailutils access control lists.

cflags
     Shows compiler options needed to compile with Mailutils.

dbm
     Invokes a DBM management tool.

;filter
     Applies a chain of filters to the input.

help
     Displays a terse help summary.

imap
     Invokes an IMAP4 client shell (in development).

info
     Displays information about Mailutils compile-time configuration.

ldflags
     Constructs a ld(1) command line for linking a program with Mailutils.

logger
     Logs information using Mailutils log facility.

pop
     Invokes a POP3 client shell.

query
     Queries configuration values.

wicket
     Scans wicket for matching URLs

mu help
-------

The mu help command lists all available options and command names along with short descriptions of what each of them does.  It is similar to the mu --help option.

A command name can be supplied as an argument to help, in which case it will display a help page for that particular command, e.g.:

     mu help ldflags

will output help for the ldflags command.  It is synonymous to the --help option used with that particular command, e.g.: mu ldflags --help.

mu info
-------

The mu info command displays information about Mailutils compile-time configuration.  In normal form its output lists a single configuration flag per line, e.g.:

     $ mu info
     VERSION=2.99.93
     SYSCONFDIR=/etc
     MAILSPOOLDIR=/var/mail/
     SCHEME=mbox
     LOG_FACILITY=mail
     IPV6
     USE_LIBPAM
     HAVE_LIBLTDL
     WITH_GDBM
     WITH_GNUTLS
     WITH_GSASL

A configuration flag can consist either of a single word, indicating that a particular capability has been enabled at compile time, or of a keyword/value pair delimited by an equal sign, which indicates a particular value used by default for that feature.  For example, IPV6 means that Mailutils was compiled with support for IPv6, whereas SYSCONFDIR=/etc means that the default place for configuration files is in /etc directory.

Such short output is convenient for using mu info in scripts to decide whether it is possible to use a given feature.  To assist human users, the --verbose (-v) option is provided. It prints a short description next to each flag:

     $ mu info --verbose
     VERSION=2.99.93           - Version of this package
     SYSCONFDIR=/etc           - System configuration directory
     MAILSPOOLDIR=/var/mail/   - Default mail spool directory
     SCHEME=mbox               - Default mailbox type
     LOG_FACILITY=mail         - Default syslog facility
     IPV6                      - IPv6 support
     USE_LIBPAM                - PAM support
     HAVE_LIBLTDL              - a portable `dlopen' wrapper library
     WITH_GDBM                 - GNU DBM
     WITH_GNUTLS               - TLS support using GNU TLS
     WITH_GSASL                - SASL support using GNU SASL

mu cflags
---------

The mu cflags command shows compiler options needed to compile a C source with Mailutils.  It is intended for use in configuration scripts and Makefiles, e.g.:

     CFLAGS=-g -O2 `mu cflags`

mu ldflags
----------

The mu ldflags command is a counterpart of cflags which is used for linking.  It constructs a ld command line for linking a program with Mailutils.

When used without arguments, it outputs ld arguments which would link only with the core Mailutils library libmailutils, e.g.:

     $ mu ldflags
     -L/usr/local/lib -lmailutils

This command accepts a number of keywords which allow to select a particular subset of Mailutils libraries to link with.  In particular, the argument all instructs it to link in all available libraries:

     $ mu ldflags all
     -L/usr/local/lib -lmu_mbox -lmu_mh -lmu_maildir -lmu_imap -lmu_pop \
     -lmu_mailer -lmu_compat -lmailutils -lmu_auth -lgsasl -lgnutls -lgcrypt \
     -lldap -lgnuradius -lpam -ldl

Other available keywords are:

mbox
     Link in the UNIX mbox format support.

mh
     Link in the MH format support.

maildir
     Link in the Maildir format support.

imap
     Link in the IMAP protocol support.

pop
     Link in the POP protocol support.

nntp
     Link in the NNTP protocol support.

mailer
     Enable support for mailers.

sieve
     Link in the support for Sieve mail filtering language.

dbm
     Link in the support for DBM databases (libmu_dbm library).

compat
     Provide a compatibility layer for Mailutils 2.x.

auth
     Link in the Mailutils authentication library.

guile
     Provide Guile language bindings.

python
     Provide Python language bindings.

cfg
     Link in the Mailutils configuration library.

argp
     Link in the library for command line parsing.

mu query
--------

The mu query command queries values from Mailutils configuration files.  It takes one or more configuration paths (see Paths) as its arguments.  On output, it displays the values it found, each value on a separate line.  If the requested value is a block statement it is displayed in full.  For example, if main configuration file contained:

     logging {
        syslog yes;
        facility mail;
     }

Then:

     $ mu query .logging.syslog
     syslog yes;
     $ mu query .logging.syslog .logging.facility
     syslog yes;
     facility mail;
     $ mu query .logging
     logging {
       syslog yes;
       facility mail;
     };

Several command line options allow to modify output format.  The --value option instructs the command to output only values:

     $ mu query --value .logging.syslog
     yes

The --path option instructs it to print full pathnames for each value:

     $ mu query --path .logging.syslog
     logging.syslog: yes

The --program option instructs mu to behave as if it was called under another program name.  For example, the following command:

     $ mu query --program=pop3d .server.transcript

will return the value of the .server.transcript statement which the pop3d utility would see.

By default, mu query operates on the main configuration file.  Another configuration file can be supplied using the --file (-f) option:

     $ mu query --file /usr/local/etc/file.conf .pidfile

mu 2047
-------

The mu 2047 command is a filter for decoding or encoding email message headers formatted in accordance with RFC 2047 (see http://www.faqs.org/rfcs/rfc2047.html.  By default, it operates in encode mode and assumes the iso-8859-1 encoding.  If arguments are supplied in the command line, they are treated as the text to operate upon.  Otherwise the command acts as a UNIX filter, reading lines from the standard input and printing results on the standard output.

For example:

     $ mu 2047 'Keld Jørn Simonsen <keld@dkuug.dk>'
     =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <keld@dkuug.dk>

The decode mode can be requested via the --decode (-d) option:

     $ mu 2047 --decode '=?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= \
      <keld@dkuug.dk>'
     Keld Jørn Simonsen <keld@dkuug.dk>

The --charset (-c) option changes the default character set.  It is meaningful both in decode and in encode modes. In decode mode it instructs the utility to convert the output to the given character set.  In encode mode it indicates the encoding of the input data, which will be reflected in the resulting string:

     $ mu 2047 --charset=utf-8 'Keld Jørn Simonsen <keld@dkuug.dk>'
     =?utf-8?Q?Keld J=C3=B8rn Simonsen <keld@dkuug.dk>?=

The --encoding (-E) option can be used in encode mode to change the output encoding.  Valid arguments for this option are: quoted-printable (the default) or base64.

The --newline (-n) option prints an additional newline character after each line of output.

mu filter
---------

The mu filter command applies a chain of filters to the input.  The filters to apply and their arguments are given in the command line.  The full invocation syntax is:

      mu filter [OPTION] FILTER-CHAIN

The syntax for FILTER-CHAIN in Backus-Naur form follows:

     <filter-chain> ::= <filter> | <filter-chain> "+" <filter>
     <filter> ::= <filter-spec> <ARG>*
     <filter-spec> ::= <WORD> | "~" <WORD>

where <WORD> stands for the filter name and <ARG> represents filter arguments.  To obtain a list of known filter names, run:

     mu filter --list

Filters are applied in the order of their appearence, from left to right and operate in encode mode.  The plus sign has the same meaning as pipe in shell.  The default mode can be changed using the --decode (-d) and --encode (-e) options. Whatever the default mode is, a ~ character before filter name reverts the mode for that filter alone.

For example, to encode the contents of file file.txt in Base64 run:

     mu filter base64 < file.txt

To convert it to base64 and use CRLF as line delimiters, run:

     mu filter base64 + crlf < file.txt

The following command will decode the produced output:

     mu filter --decode crlf + base64

It can also be written as

     mu filter ~crlf + ~base64

The following example converts the input from ISO-8859-2 to UTF-8, quotes eventual From occurring at the beginning of a line, encodes the result in Base64 and changes line delimiters to CRLF:

     mu filter iconv iso-8859-2 utf-8 + from + base64 + crlf

This final example removes UNIX-style comments from the input and joins continuation lines:

     mu filter --decode inline-comment -S '#' + linecon

Such invocation can be useful in shell scripts to facilitate configuration file processing.

mu acl
------

The mu acl command tests Mailutils Access Control Lists.  By default it reads ACL from the Mailutils configiration file section acl.  The command takes a list of IP addresses as its arguments, applies the ACL to each of them in turn and prints the result.

To select the ACL to test, two options are provided.  The --file (-f) option supplies the name of configuration file to read instead of the default one.  The --path (-p option supplies the pathname (see Paths) of the ACL section to use instead of the default .acl.  For example, to test ACL in section server 213.130.1.232 of file /etc/pop3d.conf use:

     mu acl --file=/etc/pop3d.conf \
            --path=/server="213.130.1.232"/acl ADDRESS

As an example of its use, consider file test.conf with the following contents:

     acl {
             deny from 10.10.10.1;
             deny from 10.10.1.0/24;
             log from any "Connect from ${address}";
             allow from 10.0.0.0/8;
             allow from 192.168.1.0/24;
             deny from any;
     }

Then, running mu acl --file=test.conf 127.0.0.1 you will get:

     Testing 127.0.0.1:
     mu: Connect from 127.0.0.1
     127.0.0.1: deny

More examples:

     $ mu acl --file=test.conf 127.0.0.1 10.10.10.1 \
              10.10.1.3 10.5.3.1 192.168.1.0 192.168.2.0
     Testing 127.0.0.1:
     mu: Connect from 127.0.0.1
     127.0.0.1: deny
     Testing 10.10.10.1:
     10.10.10.1: deny
     Testing 10.10.1.3:
     10.10.1.3: deny
     Testing 10.5.3.1:
     mu: Connect from 10.5.3.1
     10.5.3.1: accept
     Testing 192.168.1.0:
     mu: Connect from 192.168.1.0
     192.168.1.0: accept
     Testing 192.168.2.0:
     mu: Connect from 192.168.2.0
     192.168.2.0: accept

The mu option --debug-level will give you a deeper insight into the address matching algorithm:

     $ mu --debug-level=acl.trace9 acl --file test.conf 127.0.0.1
     Testing 127.0.0.1:
     mu: Checking sockaddr 127.0.0.1
     mu: 1:deny: Does 10.10.10.1/255.255.255.255 match 127.0.0.1? no;
     mu: 2:deny: Does 10.10.1.0/255.255.255.0 match 127.0.0.1? no;
     mu: 3:log: Does any match 127.0.0.1? yes;
     mu: Expanding "Connect from ${address}";
     mu: Expansion: "Connect from 127.0.0.1";.
     mu: Connect from 127.0.0.1
     mu: 4:accept: Does 10.0.0.0/255.0.0.0 match 127.0.0.1? no;
     mu: 5:accept: Does 192.168.0.0/255.255.0.0 match 127.0.0.1? no;
     mu: 6:deny: Does any match 127.0.0.1? yes;
     127.0.0.1: deny

See acl.

mu wicket
---------

The mu wicket command looks up matching URLs in the Mailutils ticket file (by default, ~/.mu-tickets) and prints them.  The URLs to look for are supplied in the command line.

Consider the following ticket file as an example:

     smtp://foo:bar@*
     smtp://bar:baz@gnu.org
     *://baz:qux@*
     *://quux:bar@gnu.org

Now, running mu wicket smtp://bar@gnu.org will show:

     smtp://bar@gnu.org: /home/USER/.mu-tickets:2

(where USER is your login name).  This means that this URL matches the line 2 in your .mu-tickets file.  The wicket command does not show the actual matching line to avoid revealing eventual security-sensitive information.  You can instruct it to do so using the --verbose (-v) option:

     $ mu wicket -v smtp://bar@gnu.org
     smtp://bar@gnu.org: /home/USER/.mu-tickets:2: smtp://bar:***@gnu.org

As you see, even in that case the tool hides the actual password part by replacing it with three asteriscs.  If you are working in a secure environment, you can tell mu wicket to show passwords as well, by supplying the -v option twice.

A counterpart of --verbose is the --quite (-q) option, which instructs wicket to suppress any output, excepting error messages.  This can be used in scripts, which analyze the mu wicket exit code to alter the control flow.

The mu wicket tool exits with code 0 if all URLs were matched and with code 1 if some of them were not matched in the ticket file.  If an error occurred, the code 2 is returned.

mu dbm
------

The mu dbm tool manages DBM files using libmu_dbm The invocation syntax is:

     mu dbm SUBCOMMAND [OPTIONS] FILE [KEYS]

or

     mu dbm [OPTIONS] SUBCOMMAND FILE [KEYS]

where SUBCOMMAND selects the operation mode, OPTIONS modify the tool behavior and FILE specifies the DBM file to operate upon.  Some COMMANDs allow for optional KEYS to be specified.

The FILE argument can be either a DBM file name or a Database URL.

Create a Database
.................

The create subcommand and its synonym load instruct the tool to create a new database:

     mu dbm create file.db

If the argument file already exists, it will be truncated prior to adding new records to it.

The data to populate the database with are read from the standard input.  The mu dbm command supports several formats for these data, which are discussed later.  In the simplest case (a so called format 0.0) each input line must consist of two fields separated by any amount of whitespace.  The first field is treated as a key and the second one as the corresponding value.

The usual way to read data from a file is, of course, by redirecting the file to the standard input as in:

     mu dbm create file.db < input.txt

There is also a special option for that purpose: --file (-f).  Thus, the following command is equivalent to the one above:

     mu dbm create --file input.txt file.db

The --file option has the advantage that it allows, in conjunction with another options, for copying input file metadata (owner UID, GID and file mode) to the created database.  For example, the following command ensures that the created database file will have the same metadata as the input file:

     mu dbm create --file input.txt --copy-permissions file.db

The --copy-permissions (-P) option is the one that does the job.

There are also other ways to control mode and ownership of the created database, which are described below.

More advanced dump formats (e.g.  version 1.0 format) carry additional information about the file, including its original name, ownership and mode.  If input is in one of these formats, the file name argument becomes optional.  If it is not supplied, the name stored in the input stream will be used.  For example, supposing that the file users.dump is in format 1.0, the following command suffices to restore the original filename, ownership, mode and, of course, data:

     mu dbm create --file users.dump

Add Records to a Database
.........................

The add subcommand adds records to a database.  Records are read from the standard input and must be formatted as for create:

     mu dbm add file.db

If the argument file does not exist, it will be created.

Adding a record with a key which is already present in the database produces an error.  To replace existing records, use the replace subcommand instead.

The same options that affect the behavior of create apply to add and replace as well, e.g.:

     mu dbm replace --file input.txt --copy-permissions file.db

Delete Records
..............

To delete records, use the delete subcommand.  It reads a list of keys to delete to be specified as arguments in the command line:

     mu dbm delete file.db foo bar

The command above will delete from file.db records with keys foo and bar.

It is not an error to attempt to delete a key that does not exist in the database, although such use will produce a warning message.

By default, keys are matched literally.  It is also possible to use various pattern matching techniques, depending on the option specified.

The --glob (-G) option instructs the tool to use UNIX globbing pattern matching.  For example, the command below will delete all keys starting with foo and ending with a decimal digit:

     mu dbm delete file.db 'foo*[0-9]'

(note the quoting necessary to prevent shell from interpreting the metacharacters itself).

Another option, --regex (-R) instructs mu to treat supplied keys as extended regular expressions:

     mu dbm delete --regex file.db 'foo.*[0-9]{1,3}'

Both options are affected by the --ignore-case (-i) option, which turns on case-insensitive matching.

Using pattern matching to delete records can be a risky operation as selecting a wrong pattern will lead to removing wrong records.  It is recommended to first use the list mode described below to verify that the patterns match the right keys.

List the Database
.................

The list command lists the content of the database:

     mu dbm list file.db

By default, entire content is listed on the standard output.

If supplied more than one command line argument, this mode treats the rest of arguments after the database file name as the keys to look for and lists only records with these keys:

     $ mu dbm list file.db foo bar
     foo 1
     bar 56

The --glob and --regex options instruct the tool to use UNIX globbing or extended regular expression matching, correspondingly.  These were described in detail above.

The dump subcommand dumps the database to the standard output in a format suitable for backup or sending over the network (a version 1.0 format).

     mu dbm dump file.db < file.dump

The produced file is suitable for input to the create (load) command.  Among other uses, it provides an easy way to convert databases between various formats supported by Mailutils.  For example this is how to convert the database file file.db to the GDBM database new.db:

     mu dbm dump file.db | mu dbm create gdbm://new.db

Both list and dump subcommands share the same set of options.  In fact, they are pretty similar, except that use different defaults.  The list subcommand is designed to produce a human-readable output, whereas the dump subcommand is oriented towards backup purposes.

Dump Formats
............

As of version VERSION, mu dbm supports two formats for dumping DBM databases.  Both formats are line-oriented.  Comments are introduced with a sharp (#) sign in the column 0 of a line, followed by at least one white space character (space or tab).  Sharp sign followed by a colon (#:) introduces a paragmatic comment, which carries some additional information to the loader.

The version 0.0 format is suitable for databases whose records contain only ASCII data.  In this format, each record occupies a separate line, which consists of the key and value separated by a single TAB character.  Empty lines are ignored.  For example:

     $ mu list /etc/mail/users.db
     root    guessme
     smith   pAssword
     qed     fooBar

The output in version 0.0 format is human readable and can be used as input to the popauth utility (-pxrefpopauth.  However, version 0.0 has serious drawbacks.  First of all, it is not suitable for databases that contain binary data.  Secondly, it cannot properly handle keys beginning with a sharp sign or containing TAB.  The version 1.0 format is free from these drawbacks.

The version 1.0 dump format begins with a header containing important information about the file, such as its file name, ownership and file mode.  This information is stored in pragmatic comments and allows mu dbm load to easily recreate an exact copy of the file.  The following comments are defined:

#:version=1.0
     Indicates that the data that follow are in version 1.0 format.

#:filename=S
     Original database file name, without directory parts.

#:uid=N
     Owner UID.

#:user=S
     Owner name.

#:gid=N
     Owner GID

#:group=S
     Owner group name.

#:mode=O
     File mode in octal

Following this header are actual data.  Each record is output in two parts: key and value.  Each part begins with a #:len=N construct on a line by itself, where N is the length of the data in decimal.  This line is followed by one or more lines of the actual data, encoded in base64.  The data are formatted so that each line does not exceed 76 bytes in length (not counting the terminating newline).  An example of this format follows:

     # Database dump file created by GNU Mailutils 2.99.93 on
     # Tue Nov  1 13:28:03 2011
     #:version=1.0
     #:file=users.db
     #:uid=0,user=root,gid=25,group=mail,mode=640
     #:len=6
     c21pdGgA
     #:len=9
     cEFzc3dvcmQA
     #:len=5
     cm9vdAA=
     #:len=8
     Z3Vlc3NtZQA=
     #:len=4
     cWVkAA==
     #:len=7
     Zm9vQmFyAA==

Dbm Exit Codes
..............

The table below summarizes exit codes used by mu dbm:

Code    Symbolic name   Meaning
0   EX_OK   Successful termination
64   EX_USAGE   Command line usage error
65   EX_DATAERR   Error in user-supplied data: the input
file is badly formatted, or some of the data supplied in the command
line are invalid (e.g. user name, uid or the like), etc.
66   EX_NOINPUT   Cannot open input file
67   EX_NOUSER    No such user or UID when trying to set
output file ownership
69   EX_UNAVAILABLE   Operation cannot be performed due to
some kind of problem (e.g. access to the file denied, etc.)
70   EX_SOFTWARE   Internal software error
74   EX_IOERR   Input/output error

mu logger
---------

The mu logger tool logs information using Mailutils log facility.

Syntax:

     mu logger [OPTIONS] [MESSAGE]

The MESSAGE argument, if supplied, gives the text to log.  If not supplied, the utility reads lines of text from standard input or a file (if the --file option is given) and sends them to log:

     # Send text to log
     $ mu logger I am here
     # Log each line from file.txt
     $ mu logger --file file.txt
     # Read stdin and log it:
     $ mu logger

The default logging channel is bound to standard error.  To bind it to syslog, use the --syslog command line option.  In that case mu uses facility user and priority err.  You can change this by using the --priority (-p) option. Its argument is either a syslog facility name or facility and severity names separated by a dot.  For example, the following invocation will use facility auth, severity info:

     mu logger --priority auth.info

The syslog tag can be set using the --tag (-t) option:

     mu logger --tag myprog

The default tag is mu-logger.

The --severity (-s) option sets the Mailutils severity level.  Its argument can be any of the following: debug, info, notice, warning, error, crit, alert, emerg.

Finally, the --locus (-l) option binds log messages to a location in a file.  Its argument has the following syntax:

     FILE:LINE[:COL]

where FILE is the file name, LINE is the line number and optional COL is the column number in that file.

For example, the following invocation:

     mu logger --locus mailutils.rc:34 Suspicious statement

will send the following to the log:

     mu-logger: mailutils.rc:34: Suspicious statement

mu pop
------

The mu pop command invokes an interactive POP3 client shell. It reads commands from the standard input, executes them and displays the results on the standard output.  If the standard input is connected to a terminal, the readline and history facilities are enabled (provided that Mailutils is configured with GNU Readline).

The mu pop commands form two major groups.  POP3 protocol commands interact with the remote POP3 server and display responses obtained from it.  These commands are named after their POP3 equivalents.  Another group, internal commands, are used to configure the shell itself.

POP protocol commands
.....................

connect [-tls] HOSTNAME [PORT]
     Open connection to HOSTNAME.  If the -tls option is given, TLS encryption (also known as POPS protocol) will be used.  If PORT argument is not given, the command uses port 110 for a plain POP connection or 995 for POPS (if -tls is given).

stls
     Start TLS negotiation.  This command is valid only after successful unencrypted connection has been initiated (using connect without -tls argument).

user NAME
     Send user name to the server.  The pass command must follow.

pass [PASSWORD]
     Send password.  This command is valid only after user.  If the PASSWORD argument is omitted, the shell will ask you to enter it.  While entering, both echoing and history recording will be disabled.  Use this to avoid compromising your password.

apop USER [PASSWORD]
     Authenticate with APOP.   If the PASSWORD argument is omitted, you will be asked to supply it.  While entering, both echoing and history recording will be disabled.

capa [-reread] [NAME...]
     List server capabilities.  Any number of arguments is accepted.  If given, the shell will display only the named capabilities, otherwise it displays entire list.  By default capa reuses the response of its previous invocation (if there was any), instead of resending the CAPA command to the server.  To force it do so, use the -reread option.

noop
     Send a NOOP (no operation) command to the server.

stat
     Get the mailbox size and number of messages in it.

uidl [NUMBER]
     Shows unique message identifiers.  Without arguments, shows identifiers for each message in the mailbox.  If NUMBER is given, the command returns the UIDL of that particular message only.

list [NUMBER]
     Lists messages.  See above for the meaning of NUMBER.  Each line of the produced listing contains describes a single message and contains at least the message number and size in bytes.  Depending on the POP3 server implementation, additional fields may be present.  For example, Mailutils pop3d can also output number of lines in the message in the additional third field.

retr NUMBER
     Retrieve a message.

top MSGNO [NUMBER]
     Display message headers and first NUMBER (default 5) of lines of its body.

dele NUMBER
     Mark message for deletion.

rset
     Remove deletion marks.

quit
     Quit pop3 session.

disconnect
     Close existing connection.

Internal commands
.................

verbose [on|off|mask|unmask] [secure [payload]]
     Control output verbosity.  Without arguments the verbose command shows current settings.

     The argument off (the default) turns off all additional output. The verbose on command enables POP3 protocol tracing output. Additional arguments can be used to provide more verbosity.  The secure argument enables display of user passwords in the trace output and the payload argument enables showing payload data (e.g. response body sent in the reply to RETR command, etc.) Thus, the full diagnostics output is obtained by

          verbose on secure payload

     The mask and unmask arguments allow to disable and enable such additional verbosity.  For example, supposing the command above is in action, the following command will suppress the display of user passwords in the traces:

          verbose mask secure

     Similarly, verbose unmask secure will turn it back again.

prompt STRING
     Set command prompt.  The argument can contain variable references in any of the following forms:

          $NAME
          ${NAME}

     where NAME is the variable name.  Such references are expanded to the actual value of the variable at the time of expansion.  The following variables are defined:

     Variable   Expansion
     user   Login name of the authenticated POP3 user.  If the session is not authenticated yet, expands to [nouser].
     host   Name of the remote host, or [nohost] if no
     connection is established.
     program-name   Name of the program, as typed on the command
     line to invoke it.
     canonical-program-name   mu
     package   Mailutils
     version   Mailutils version number (VERSION)
     status   Session status.  One of: disconnected,
     connected or logged in.

     For example:

          prompt "[${user}@$host "

     Notice the use of quotes to include the space character in the prompt.

exit
     Exit the program.

help [COMMAND]
? [COMMAND]
     Without arguments displays a list of commands with possible arguments and short descriptions.

     With one argument, displays a terse description for the given COMMAND.

history
     Shows command history.

mu imap
-------

The mu imap command is reserved for an interactive IMAP4 client shell.  It does not do much now (as of version VERSION.