This edition of the GNU Mailutils Manual, last updated on 26 December 2008, documents GNU Mailutils Version 2.0.
Appendices
Indices
--- The Detailed Node Listing ---
Introduction
Mailutils Programs
Command Line
Mailutils Configuration File
Configuration File Syntax
Server Settings
mail --- Send and Receive Mail
Composing Mail
Reading Mail
movemail --- Moves Mail from the User Maildrop to the Local File
readmsg --- Extract Messages from a Folder
sieve
A Sieve Interpreter
guimb --- A Mailbox Scanning and Processing Language
maidag
Mailbox Quotas
Maidag Scripting
mail.local --- Deliver Mail to the Local UNIX Mailbox
mimeview
POP3 Daemon
IMAP4 Daemon
Comsat Daemon
Configuring comsatd
MH --- The MH Message Handling System
Major differences between Mailutils MH and other MH implementations
mailutils-config --- Get the Information about the Mailutils Build
Mailutils Libraries
Framework
Authentication Library
Mailutils to Scheme Interface
Using libmu_scm
Sieve Library
Sieve Language
Syntax
Preprocessor
Tests
Actions
Date Input Formats
GNU Mailutils contains a series of useful mail clients, servers, and libraries. These are the primary mail utilities of the GNU system. Specifically, this package contains a POP3 server, an IMAP4 server, and a Sieve mail filter. It also provides a POSIX `mailx' client, and a collection of other tools. All utilities can manipulate the mailboxes of various formats, both local, stored on the hard disk, and remote, accessed via network protocols, such as POP3 or IMAP4.
The GNU Mailutils libraries supply a rich set of primitives for handling electronic mail in programs written in C, C++ or Scheme.
This software is part of the GNU Project and belongs to the Free Software Foundation. All libraries are licensed using the GNU LGPL. The documentation is licensed under the GNU FDL, and everything else is licensed using the GNU GPL.
This book addresses a wide audience of both system administrators and users that aim to use Mailutils programs, and programmers who wish to use Mailutils libraries in their programs. Given this audience, the book is divided in three major parts.
The first part provides a detailed description of each Mailutils utility, and advices on how to use them in various situations. This part is intended for users and system administrators who are using Mailutils programs. If you are not interested in programming using Mailutils, this is the only part you need to read.
Subsequent parts address programmers.
The second part is a tutorial which provides an introduction to programming techniques for writing mail applications using GNU Mailutils.
Finally, the third part contains a complete Mailutils library reference.
This version of the book is not finished. The places that may contain inaccurate information carry prominent notices stating so. For updated versions of the documentation, visit http://www.gnu.org/software/mailutils/manual. If you have any questions, feel free to ask them at the mailing list bug-mailutils@gnu.org.
(The information in this node may be obsolete or otherwise inaccurate. This message will disappear, once this node revised.)
This package started off to try and handle large mailbox files more gracefully then current POP3 servers did. While it handles this task, it also allows you to support a variety of different mailbox formats without any real effort on your part. Also, if a new format is added at a later date, your program will support that new format automatically as soon as it is compiled against the new library.
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.
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.
All GNU Mailutils programs understand a common subset of options.
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: 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.
The following command line options affect parsing of configuration files. Here we provide a short summary, the next section will describe them in detail.
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:
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.
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.
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.
Configuration files consist of a series of statements. 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 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 are allowed to appear within a multi-line one.
A simple statement, consists of a keyword and value separated by any amount of whitespace. Simple statement is terminated with a semicolon (‘;’), unless it contains a here-document (see below), in which case semicolon is optional.
Examples of simple statements:
pidfile /var/run/imap4d.pid;
transcript yes;
A keyword begins with a letter and may contain letters, decimal digits, underscores (‘_’) and dashes (‘-’). Examples of keywords are: ‘group’, ‘identity-check’.
A value can be one of the following:
| 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)
|
| \\ | A single backslash (‘\’)
|
| \" | A double-quote.
|
Table 2.1: Backslash escapes
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"
The <<word construct instructs the parser to read all
the lines that follow 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
Body of a here-document is interpreted the same way as 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
All 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;
However, terminated semicolon after a here-document is optional.
shared-namespace ("/home", "/var/spool/common");
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. ‘shared-namespace /home;’ is equivalent to ‘shared-namespace (/home);’.
A block statement introduces a logical group of another statements. It consists of a keyword, followed by an optional value, and a sequence of statements enclosed in curly braces, as shown in example below:
tcp-wrappers {
enable yes;
allow-syslog-priority info;
deny-syslog-priority notice;
}
The closing curly brace may be followed by a semicolon, although this is not required.
An include statement is a special statement that causes inclusion of a named file. This statement 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 {
# Set syslog facility.
facility name;
# Tag syslog messages with this string.
tag text;
}
The logging block statement provides configuration for
programs that use syslog for diagnostics. The default
syslog facility is determined at compile time, it can be inspected
using the following command:
$ mailutils-config --info log_facility
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.
Tag syslog messages with text. By default, program name is used as syslog tag.
debug {
# Set Mailutils debugging level.
level spec;
# Prefix debug messages with Mailutils source locations.
line-info bool;
}
The debug statement configures debugging output. Although it
is mostly useful for Mailutils developers, it may be of interest for
casual users as well. In particular, you may use it to obtain more
information about Mailutils actions, which may help in configuring it,
or in filling a bug report.
Debugging output is controlled by a set of levels, each of which can be enabled or disabled independently of others. A debugging level consists of a module name, which defines a Mailutils module affected by this level, and a level number, which defines the verbosity of the debugging output. Valid debugging levels are:
Table 2.2: Debugging levels
The most important debugging modules are:
Due to its specific nature, this debugging module cannot be enabled
using level statement below. The --debug-level
command line option should be used instead
(). Alternatively, you may use the following
hook, provided to facilitate debugging of the configuration parser: a
pragmatic comment in form:
#debug=level
is understood as a request to set debugging level of module
‘config’ to level.
This statement enables debugging levels given by spec. The argument is an list of debugging specifications or a string with specifications delimited by semicolons. The syntax of a specification is:
module[[:]=level]where module is the name of a module, and level is the level to be set. The level may be optionally prefixed with the following symbols:
- ‘!’
- All levels except this one. E.g. ‘config=!trace7’ means set all debugging levels, except ‘trace7’ for the ‘config’ module.
- ‘<’
- All levels up to and including this. The words ‘up to’ refer to the position of levels in Table 2.2 table, so that, e.g. ‘<trace2’ means levels ‘error’, ‘trace0’, ‘trace1’ and ‘trace2’.
Both prefixes can be used together, in this order: ‘!<’. This means all levels except this one and ones listed before it in the table.
A comma before equal sign, as in ‘mailbox:=<trace7’ means set this debugging levels in all modules, invoked by this one.
The level in the level specification can also be a comma-separated list of valid levels, e.g.:
mailbox=<trace2,!<trace4which means “levels trace3 and trace4”.
The following example illustrates two equivalent ways of setting debugging level in a configuration file:
level ("mailbox=!proto", "acl=<trace7"); level "mailbox=!proto;acl=<trace7";The --debug-level command line option overrides the settings of the
levelconfiguration statement.
If bool is ‘true’ (see boolean value), each debugging message will be preceded by a corresponding source file location, i.e. the file name and line number where this message was generated.
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;
}
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.
The
mail-spoolstatement 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-patternstatement.
The
mailbox-patternstatement is a modern way of configuring mailbox locations. It supersedesmail-spoolstatement.The pattern is valid mailbox URL, which may contain references to ‘user’ macro-variable (). 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. . By default, ‘local’ is assumed. .
- 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:
- Take the first letter of the user name.
- Map it to a lower-case letter using index mapping table. The result gives sub-directory name.
- 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:
- Take next letter from the user name
- Add its ASCII value to the hash sum.
- Continue (1-2) until level letters are processed, or all letters from the file name are used, whichever occurs first.
- 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 2.0 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-patternfor 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:
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.
Specifies type of mailboxes. By default, ‘mbox’ (UNIX mailbox) is assumed. This can be changed while configuring the package by setting
MU_DEFAULT_SCHEMEconfiguration variable. The default value can be verified by running mailutils-config --info scheme.
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 {
# 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;
}
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.
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-lockerstatement (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-countandretry-timeoutstatements, 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-timeoutstatement.- P
- Store the PID of the locking process in a lock file.
Number of locking attempts. The ‘P’ flag must be set for this to take effect.
Time interval, in seconds, between the two successive locking attempts. The ‘P’ flag must be set for this to take effect.
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.
Set command line of an external locker program. The ‘E’ flag must be set for this to take effect.
mailer {
url url;
}
A mailer is a special logical entity GNU Mailutils uses for
sending messages. Its internal representation is discussed in
Mailer. The mailer statement configures it.
The mailer statement contains a single sub-statement:
GNU Mailutils supports two types of mailer URLs, described in the table below. As usual, square brackets indicate optional parts:
_PATH_SENDMAIL macro in your
/usr/include/paths.h. It is the default mailer.
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:
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;
}
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 2.0 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:
The following controls are understood:
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:
Log connections from addresses in this cidr. The
MU_DIAG_INFOchannel is used. If the logging goes to syslog, it is translated to theLOG_INFOpriority.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 2.0 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.
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 {
# 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;
}
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, for details.
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.
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.
# 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;
These statements configure general server-related issues.
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, 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
modestatement is specified. This will change in the future.
[daemon mode only]
Do not disconnect from the controlling terminal and remain in the foreground.
[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.
After startup, store the PID of the main server process in file. When the process terminates, the file is removed. As of version 2.0, GNU Mailutils servers make no further use of this file. It is intended for use by automated startup scripts and controlling programs ().
[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).
Set maximum idle time out in seconds. If a client does not send any requests during time seconds, the child process terminates.
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. */ };
}
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). 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.
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.
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.
Set idle timeout for this server. This overrides global timeout settings (see timeout).
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 {
# Set a list of modules for authentication.
authentication module-list;
# Set a list of modules for authorization.
authorization module-list;
}
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.
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
virtdomainstatement (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.
Unless overridden by
authorizationstatement, the default list of authorization modules is:(system, sql, virtdomains)
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
getpassstatement (see getpass).- pam
- The user is authenticated via pluggable authentication module (PAM). The PAM service name to be used is configured in
pamstatement (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.
Unless overridden by
authenticationstatement, the list of authentication modules is:(generic, system, pam, sql)
pam {
# Set PAM service name.
service text;
}
The pam statement configures PAM authentication. It
contains a single sub-statement:
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 {
# Name of the virtdomain password directory.
passwd-dir dir;
}
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.
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), with encrypted passwords stored in it (as of GNU Mailutils version 2.0, 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 {
# Set radius configuration directory.
directory dir;
# Radius request for authorization.
auth request;
# Radius request for getpwnam.
getpwnam request;
# Radius request for getpwuid.
getpwuid request;
}
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). 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:
It authorization is used, the Radius dictionary file must declare the the following attributes:
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) 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). 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 ():
auth and getpwnam), or user ID
(for getpwuid). For example:
User-Name = ${user}
User-Password = ${passwd}
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). Any returned attribute-value pairs are ignored.
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-Acceptpacket 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-MailboxandGNU-MU-Quotaare optional.If
GNU-MU-Mailboxis present, it must contain a valid mailbox URL (). IfGNU-MU-Mailboxis not present, Mailutils constructs the mailbox name using the settings from themailboxconfiguration statement (see Mailbox Statement), or built-in defaults, if it is not present.If
GNU-MU-Quotais present, it specifies the maximum mailbox size for this user, in bytes. In the absence of this attribute, mailbox size is unlimited.
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
getpwuidrequest is the same as togetpwnamrequest (see above).
(The information in this node may be obsolete or otherwise inaccurate. This message will disappear, once this node revised.)
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;
}
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.
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:
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.
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.
This node is to be written.
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;
}
This node is to be written.
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;
}
This node is to be written.
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;
}
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.
|
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:
From
Subject pair.
To header to the output. The output field
order is then: To From Subject.
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:
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 a mailbox. The URL of the mailbox to operate upon is taken from the argument of --file command line option. If it is not specified, the user's system mailbox is assumed. 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.
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: .
Mail understands following command line options:
print *
quit
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).
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:
In its complex form, the message list is a comma or whitespace-separated list of message specifiers. A message specifier is one of
[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:’.
:/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:
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).
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.
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.
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.
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.
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.
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
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.
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.
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.
The ‘~i’ escape enters the value of the named mail variable into the body of the message being composed.
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.
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.
To read messages from a given mailbox, use one of the following ways of invoking mail:
mailmail --filemail --file=path_to_mailboxmail --user=userPlease 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.
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.
Following commands quit the program:
delete are removed.
The program exits to the Shell, unless saving the mailbox fails, in
which case user can escape with the exit command.
Typing EOF (‘C-D’) alone is equivalent to ‘quit’.
Following commands can be used during the session to request online help:
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 |
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.
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.
folder variable.
| & summary "/var/spool/mail/gray": 23 messages 22 unread |
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.
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 ... |
toplines and
defaults to five.
cmd is set,
the value of this variable is used as a command name.
& untag :t
delete command.
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.
delete command, unless the variable
keepsave is set.
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.
save, except that only message body (without the
header) is saved.
Save, except that only message body (without the
header) is saved.
quit command. This is the default action for
all read messages, unless you have variable hold set.
save, except that saved messages are not marked for
deletion.
Save, except that saved messages are not marked for
deletion.
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.
EDITOR environment variable.
VISUAL environment variable.
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, 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 |
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 |
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.
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 !.
The ‘#’ character introduces an end-of-line comment. All characters until and including the end of line are ignored.
The ‘echo’ (‘ec’) command prints its arguments to stdout.
The command ‘source filename’ reads commands from the named file. Its minimal abbreviation is ‘so’.
The mail variables may be set using ‘set’ (‘se’) command. The command takes a list of assignments. The syntax of an assignment is
True value.
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
Shell environment may be modified using ‘setenv’ (‘sete’) command. The command takes a list of assignments. The syntax of an assignment is:
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:
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
Following variables control the behavior of GNU mail:
appenddeadletterTrue, the contents of canceled letter is
appended to the user's dead.letter file. Otherwise it overwrites
its contents.
askbccTrue the user will be prompted to enter Bcc
field before composing the message.
askccTrue the user will be prompted to enter Cc
field before composing the message.
asksubTrue the user will be prompted to enter Subject
field before composing the message.
autoincautoprintbang! in arguments to !
command is replaced with the last executed command.
datefieldDate: header field, converted to
local time. Notice, that for messages lacking this field mail
will fall back to using SMTP envelope.
charsetLC_ALL environment
variable. Otherwise, its value is taken as the name of the charset.
cmdpipe.
columnsCOLUMNS is used.
This variable contains the number of columns on terminal screen.
crtcrt 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.
decode-fallbackdotTrue, causes mail to interpret a period alone on a line as the
terminator of a message you are sending.
emptystarteditheaders~e and ~v escapes, thus allowing you to customize
the headers.
escapefliprflipr if set swaps the meanings of reply
and Reply commands (see Replying).
folderheaderheaders command automatically after entering
interactive mode.
holdTrue, 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.
ignoreTrue, mail will ignore keyboard interrupts
when composing messages. Otherwise an interrupt will be taken as a
signal to abort composing.
ignoreeofindentprefix~m tilde escape for indenting quoted messages.
inplacealiasesIf 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.
keepsavemailxCc and Bcc addresses after composing the body.
The default behavior is to ask for these values before composing
the body.
metamaildecode 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"
mimenoaskset 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’.
metoomodenullbodytrue, 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'
nullbodymsgUnsetting this variable disables the warning.
outfoldersave,
write, etc. commands will be stored. When unset, current
directory is assumed.
pageTrue, the pipe command will emit a linefeed
character after printing each message.
promptquitrcrecordrecursivealiasesWhen set, mail will expand aliases recursively.
regexTrue enables use of regular expressions in
‘/.../’ message specifications.
replyprefixreplyregexSubject 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).
saveappenddeadletter.
screenLINES is used.
This variable contains the number of lines on terminal screen.
sendmailSign~A
escape.
sign~a escape. Use
Sign variable, if your signature occupies more than one line.
showtoTo: addresses
instead of From: for all messages that come from the user that
invoked the program.
subjectasksub is
off.
toplinestop and Top commands.
verbosexmailerX-Mailer: mail (GNU Mailutils 2.0)
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 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:
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, for detailed
description of Rmail interface.
Mailutils version of movemail is completely
backward-compatible with its Emacs predecessor, so it should run
flawlessly with older versions of Emacs. Emacs version 21.4, which is
being developed at the time of this writing, will contain improved
Rmail interface for work with mailutils movemail.
Following configuration file statements affect the behavior of movemail:
| 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.
|
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.
Quite a few options control how movemail handles mail locking (a way of preventing simultaneous access to the source mailbox). By default, before accessing mailbox file, movemail will first see if the file named file.lock (so called lock file) exists. If so, it will assume that the mailbox is being used by another program and will sleep one second. If file.lock file disappears after this wait period, the program will proceed. Otherwise, it will repeat this action ten times. If after ten wait periods the lock file does not disappear, movemail gives up and exits.
If the lock file does not exist, movemail will create it, thereby indicating to other programs that the mailbox is being used, and will proceed to copying messages to the destination file. When finished, movemail closes the mailbox and removes the lock file.
Several options control this behavior. To change the default sleep period use --lock-retry-timeout. Its argument is the timeout value in seconds.
To change number of retries, use --lock-retry-count. For
example, setting rmail-movemail-flags to
--lock-retry-timeout=2 --lock-retry-count=5
instructs movemail to make five attempts to acquire the lock file, with two-second intervals between the attempts.
You may also force movemail to remove the lock file if it is older than a given amount of time (a so called stale lock file). To do so, use the following option:
--lock-expire-timeout=seconds
The --lock-expire-timeout sets the number of seconds after which a lock file is considered stale.
There are special programs that can be used to lock and unlock mailboxes. A common example of such programs is dotlock. If you wish to use such external locking program instead of the default mailutils locking mechanism, use option --external-locker. Argument to this option specifies the full name of the external program to use.
movemail [option...] inbox destfile [remote-password]
The first argument, inbox, is the url (see URL) 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.1. 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:
The readmsg utility extracts messages from a mailbox according to the criteria specified in the command line. These criteria are:
readmsg 1 3 0
extracts three messages from the folder: the first, the third, and the last.
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.
Following configuration statements affect the behavior of readmsg:
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).
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 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.
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.
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:
| ‘g’ | Enable main parser traces
|
| ‘T’ | Enable mailutils traces
|
| ‘P’ | Trace network protocols
|
| ‘t’ | Enable sieve trace
|
| ‘i’ | Trace the program instructions
|
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.
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:
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.
Used within the
sieveblock statement.If bool is ‘true’, clear library search path.
Used within the
sieveblock statement.If bool is ‘true’, clear include search path.
Used within the
sieveblock statement.Add directories to sieve library search path. Argument is a string containing a colon-separated list of directories.
Used within the
sieveblock statement.Add directories to the include search path. Argument is a string containing a colon-separated list of directories.
If bool is ‘true’, do not abort if execution of a Sieve script fails on a particular message.
Sets Sieve debug flags. See Logging and Debugging, for a detailed description.
If bool is ‘true’, print source locations along with action logs. This statement takes effect only if
verbose trueis also set.
Set user e-mail address. This is useful for
rejectandredirectactions. By default, the user email address is deduced from the user name and the full name of the machine where sieve is executed.
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:
mailutils library.
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 (). This option causes sieve to output its diagnostics to the given syslog facility.
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:
library-path statement (see library-path) in Sieve configuration file.
#searchpath Sieve directive (see #searchpath).
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:
source for the required action NAME is not available
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 Scheme programs produced by sieve.scm can be used with guimb or mail.local.
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.
|
The Scheme program or expression to be executed is passed to guimb via the following options:
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:
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.
There are four basic ways of passing mailboxes to guimb.
guimb [options] [mailbox...]guimb [options] --mailbox defmboxguimb [options] --mailbox defmbox mailbox [mailbox...]guimb [options] --user username [mailbox...]If no mailboxes are specified in the command line, guimb reads and processes the system mailbox of the current user.
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
This is a short summary of the command line options available to guimb.
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 or Scheme 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.
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 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
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 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:
To use DBM quota database, GNU Mailutils must be compiled with one of the following command line options: --with-gdbm, --with-berkeley-db, or --with-ndbm. Examine the output of maidag --show-config-options, if not sure.
The quota database should have the following structure:
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;
Configuration statement quota-query allows to specify a special
query to retrieve the quota from the database. Currently (as of mailutils
version 2.0) 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 can use global or per-user mail filters to decide whether to deliver the message, and where to deliver it. As of Mailutils version 2.0, such mail filters may be written in the following languages:
The file name of the Sieve filter to use is specified using ‘sieve-filter’ configuration statement. The following meta-symbols can be used in its argument:
For example, the following configuration statement:
sieve-filter "~/.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.
The file name of the Scheme mail filter is specified using ‘guile-filter’ configuration statement. This statement is processed as described in Sieve Maidag Filters.
Only one of guile-filter or sieve-filter may be
used. The behavior of maidag if both statements are used is
undefined.
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:
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);
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
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:
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 |
+---------------------+---------------------------------------+
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.
|
In case of multiple delivery, exit with code 0 if at least one delivery has succeeded.
Indicate temporary failure if the recipient is over his mail quota. By default, permanent failure is returned. See Mailbox Quotas.
Set file name or name pattern of the Sieve filter file. See Sieve Maidag Filters.
When logging Sieve actions, identify messages by the value of this header.
File name or name pattern for Guile filter file. See Scheme Maidag Filters.
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.
Configure safety checks for the forward file. See forward-file-checks.
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’.
Mail.local reads the standard input up to an end-of-file and appends the received data to the local mailboxes in UNIX mailbox format. This program is superseded by maidag (see maidag) and will be decommissioned in future releases.
General usage of mail.local program is:
mail.local [option...] recipient [recipient ...]
If recipient part is a FQDN, mail.local will attempt to deliver to a virtual host.
This option is available only if the package has been configured to
use Guile extension language.
MU_DEBUG_TRACE).
MU_DEBUG_PROT)
MU_SIEVE_DEBUG_TRACE)
The digits in the range ‘0’ – ‘9’ used in flags set
mail.local debugging level.
The behavior of mail.local 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.
|
Additionally, mail.local defines the following configuration statements for its use:
In case of multiple delivery, exit with code 0 if at least one delivery has succeeded.
Indicate temporary failure if the recipient is over his mail quota. By default, permanent failure is returned.
Set file name or name pattern of the Sieve filter file.
The following meta-sequences are expanded in pattern:
- ~
- %h
- Expands to the recipient home directory.
- %u
- Expands to the recipient user name.
When logging Sieve actions, identify messages by the value of this header.
File name or name pattern for Guile filter file. See
sieve-filterabove, for the description if pattern.
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.
The mail.remote utility reads the standard input, which must be formatted as an RFC-2822 email message, and forwards it to the specified remote SMTP server. This utility is superseded by maidag and will be decommissioned in future releases. For a description of how to use maidag for remote delivery, Remote Mailbox Delivery.
This section provides a short overview of the mail.remote utility.
$ mail.remote [option...] rcpt [rcpt...]
Options are:
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. By default mimeview searches for mime.types in $prefix/etc/cups/2, 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
The following table summarizes options specific for mimeview:
--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/*').
mailcap files.
If flags are not given, the default ‘9’ is assumed.
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.
The following configuration statements affect the behavior of mimeview:
| Statement | Reference
|
|---|---|
| debug | See Debug Statement.
|
Set mimeview debug level. See –debug, for a description of debug levels.
The pop3d daemon implements the Post Office Protocol Version 3 server.
pop3d has two operation modes:
pop3 stream tcp nowait root /usr/local/sbin/pop3d pop3d
This is the default operation mode.
The server operation mode is configured using mode statement
(see mode).
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 2.0, 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;
Notice, that there is no need to include the ‘.db’ suffix in the file name.
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.
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;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:
delete-expired
configuration statement:
QUIT command.
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.
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 mboxbulletin-db fileThe 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;
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.
|
Automatically expire read messages after n days. See Auto-expire, for a detailed description.
Delete expired messages upon closing the mailbox. See Auto-expire, for a detailed description.
Set the minimal allowed delay between two successive logins. See Login delay, for more information.
Set the name of login statistics file for the
login-delayfacility. See Login delay, for more information.
Get bulletins from the specified mailbox. See Bulletins, for a detailed description.
Set bulletin database file name. See Bulletins, for a detailed description.
The following table summarizes all pop3d command line options.
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.
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:
By default, imap4d starts with the following namespaces:
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:
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:
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;
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.
|
Set shared namespace. List is a list of strings. See Namespace, for a detailed description.
Set other users' namespace. List is a list of strings. See Namespace, for a detailed description.
Set file mode for mailboxes created within shared namespace. See Namespace, for a detailed description.
Set file mode for mailboxes created within other users' namespace. See Namespace, for a detailed description.
Create nonexistent user home directories. See also home-dir-mode, below.
Set file mode for created user home directories. Mode is specified in octal.
The default value for mode is ‘700’ (‘drwx------’ in
lsterms).
Require successful
STARTTLScommand before entering authentication phase.
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.
If bool is ‘true’, use only preauth mode. If unable to setup it, disconnect immediately.
Set DES keyfile for decoding encrypted ident responses. Used with ‘ident://’ preauth mode.
Set list of fields to return in response to ID command.
Valid field names are:
- name
- Package name (‘GNU Mailutils’).
- version
- Package version (‘2.0’).
- 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.
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
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.
Comsatd uses following option groups: , , .
$ comsatd --convert-config=/etc/comsatd.conf > /etc/mailutils.d/comsatd
comsat dgram udp wait root /usr/sbin/comsatd \
comsatd -c /etc/comsat.conf
This is the default operation mode.
$ comsatd --test /var/mail/root 34589
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.
|
These statements control the general behavior of the comsat daemon:
Enable or disable processing of user's .biffrc file. By default, it is enabled.
These statements control the way comsatd fights possible flooding attacks.
Set maximum number of incoming requests per ‘request-control-interval’.
Set initial amount of time to sleep, after the first overflow occurs.
Set overflow control interval. If two consecutive overflows happen within that interval, the overflow-delay-time is doubled.
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 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:
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:
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 ---
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"
The primary aim of this implementation is to provide an interface between Mailutils and Emacs using mh-e module.
To use Mailutils MH with Emacs, add the following line to your site-start.el or .emacs file:
(load "mailutils-mh")
For the information about the current state of Mailutils MH implementation please refer to file mh/TODO in the Mailutils distribution directory.
[FIXME]
Decodes the input string str as per RFC 2047. Useful in printing ‘From:’, ‘To:’ and ‘Subject:’ headers.
Notice that, unlike the similar NMH function,
decodechecks the value of the global profile variableCharset(see Charset variable) to determine the charset to output the result in. If this variable is not set,decodereturns its argument without any change. If this variable is set toauto,decodetries to determine the charset name from the setting of LC_ALL environment variable. Otherwise, the value ofCharsetis taken to be the name of the character set.
The function removes any leading whitespace and eventual ‘Re:’ prefix from its argument. Useful for creating subjects in reply messages:
%<{subject}Subject: Re: %(unre{subject})\\n%>
Sets the regular expression used to recognize reply messages. The argument r should be a POSIX extended regular expression. Matching is case insensitive.
For example, the following invocation
%(reply_regex ^\(re|aw|ang|odp\)\(\\[[0-9]+\\]\)?:[[:blank:]])corresponds to English ‘Re’, Polish ‘Odp’, Norwegian ‘Aw’ or German ‘Ang’, optionally followed by a number in brackets, followed by colon and any amount of whitespace. Notice proper quoting of the regex metacharacters.
See also
Reply-Regex(see Reply-Regex variable) andisreply(see isreply MH function) below.
If str is not given, the value of ‘Subject:’ header is taken.
The function returns true if its argument matches the “reply subject” regular expression. This expression is set via the global profile variable
Reply-Regex(see Reply-Regex variable) or via the format functionreply_regex.This function is useful for creating ‘Subject:’ headers in reply messages. For example, consider the following construction:
%<{subject}%(lit)%<(isreply)%?\ (profile reply-prefix)%(concat)%|%(concat Re:)%>\ %(concat{subject})%(printhdr Subject: )\n%>If the ‘Subject:’ header already contained reply prefix, this construct leaves it unchanged. Otherwise it prepends to it the value of
Reply-Prefixprofile variable, or, if it is unset, the string ‘Re:’.This expression is used in default replcomps and replgroupcomps files.
This function returns true if the given element is present in the recipient mask (as modified by --cc or --nocc options) and false otherwise. It is used in default formats for repl and comp, e.g.:
%(lit)%<(rcpt to)%(formataddr{to})%>Notice that this means that usual replcomps file will be ignoring --cc and --nocc options, unless it has been modified as shown above.
Prints the value of string register, prefixed by str. The output is formatted as a RFC 822 header, i.e. it is split at whitespace characters nearest to the width boundary and each subsequent segment is prefixed with horizontal tabulation.
Generates the value for ‘In-reply-to:’ header according to RFC 2822.
Generates the value for ‘References:’ header according to RFC 2822.
Controls the character set in which the components decoded via the
decode(see decode function) format function should be output.
Keeps the regular expression used to recognize reply messages. The argument should be a POSIX extended regular expression. Matching is case insensitive.
For more information, please see See reply_regex function.
The --recurse option instructs the utility to recursively expand the digest.
The --length option can be used to set the minimal encapsulation
boundary length for RFC 934 digests. Default length is 1,
i.e. encountering one dash immediately following a newline triggers
digest decoding. It is OK for messages that follow RFC 934
specification. However, many user agents do not precisely follow it,
in particular, they often do not escape lines starting with a dash by
‘- ’ sequence. Mailman is one of such agents. To cope
with such digests you can set encapsulation boundary length to a higher
value. For example, bounce --length=8 has been found to be
sufficient for most Mailman-generated digests.
ignores contains more than one component name
it must be enclosed in double-quotes. Dangling equal sign is an error,
to set a string variable to the empty value assign it an empty string, e.g.:
overflowtext="" (see the supplied mhl.format file).
Interactive prompting is not yet implemented.
moreproc
variable. Standard mhn in this case used to print ‘don't
know how to display content’ diagnostic.
The default behaviour is to pipe the content to the standard input
of the mhn-show-type[/subtype] command. This is altered to using a
temporary file if the command contains %f or %F escapes.
Content-Disposition header contains ‘filename=’,
and mhn is invoked with --auto switch, it
transforms the file name into the absolute notation and uses it only
if it lies below the current mhn-storage directory. Standard
mhn only requires that the file name do not begin with ‘/’.
Before saving a message part, GNU mhn checks if the file already exists. If so, it asks whether the user wishes to rewrite it. This behaviour is disabled when --quiet option was given.
use command.
Mailutils rmm does not delete any messages. Standard rmm in this case deletes all messages preceeding the non-existent one.
rmmproc profile component is not used.
pick --component field --pattern string
New command line option --cflags allows to control the type of regular expressions used. The option must occur right before --pattern or --component option (or one of its aliases, like --cc, --from, etc.)
The argument to this option is a string of type specifications:
| B | Use basic regular expressions
|
| E | Use extended regular expressions
|
| I | Ignore case
|
| C | Case sensitive
|
Default is ‘EI’.
The flags remain in effect until the next occurrence of --cflags option.
Sample usage:
pick --cflag BC --subject '*a string'
The date comparison options (--before and --after accept date specifications in a wide variety of formats, e.g.:
pick --after 20030301
pick --after 2003-03-01
pick --after 01-mar-2003
pick --after 2003-mar-01
pick --before '1 year ago'
etc...
Any number of --datefield, --textfield and --numfield options may be given, thus allowing to build sort criteria of arbitrary complexity.
The order of --.*field options sets the ordering priority. This differs from the behaviour of the standard sortm, which always orders datefield-major, textfield-minor.
Apart from sorting the mailfolder the following actions may be specified:
This program is designed for developers wishing to link their programs against libmailbox. It allows to examine the particulars of the current build of Mailutils and to get the command line parameters necessary for compiling and linking an application with Mailutils libraries.
When invoked with the option --compile, or its short form -c, mailutils-config prints the flags that must be given to the compiler for compiling the program using Mailutils functions. An example usage:
cc -omyprog.o `mailutils-config --compile` myprog.c
The --link, or its short form -l prints to the standard output the loader flags necessary to link a program against Mailutils libraries.
When invoked without arguments, it produces the flags necessary to link against the basic library of Mailutils: libmailbox. Arguments may be given that alter this behavior. These are:
mbox format library.
mh format library.
maildir format library.
mailer library.
imap format library.
pop format library.
The order of arguments does not matter.
For example, if you wrote a program myprog.c that uses standard unix mailbox format, mh format and the Guile interface, then you would link it with the following command:
cc -omyprog myprog.o `mailutils-config --link mbox mh guile`
The --info, or -i retrieves the options (flags) used when building Mailutils. It may be used with or without arguments.
When used without arguments, it prints the list of all build flags, e.g.:
$ mailutils-config --info
VERSION=2.0
SYSCONFDIR=/usr/local/etc
MAILSPOOLDIR=/var/mail/
SCHEME=mbox
LOG_FACILITY=mail
USE_LIBPAM
HAVE_LIBLTDL
WITH_GDBM
WITH_GNUTLS
WITH_GSASL
WITH_GUILE
WITH_PTHREAD
WITH_READLINE
HAVE_MYSQL
ENABLE_VIRTUAL_DOMAINS
ENABLE_IMAP
ENABLE_POP
ENABLE_MH
ENABLE_MAILDIR
ENABLE_SMTP
ENABLE_SENDMAIL
When this option is used in conjunction with the --verbose option, a short description is printed to the right of each keyword, e.g.:
$ mailutils-config --info --verbose
VERSION=1.9.93 - Version of this package
SYSCONFDIR=/usr/local/etc - System configuration directory
MAILSPOOLDIR=/var/mail/ - Default mail spool directory
SCHEME=mbox - Default mailbox type
LOG_FACILITY=mail - Default syslog facility
USE_LIBPAM - PAM support
HAVE_LIBLTDL - a portable `dlopen' wrapper library
WITH_GDBM - GNU DBM
...
This option also accepts any number of arguments. When these are given, each argument is treated as a name of a build flag. Mailutils-config checks if such a flag was defined and prints its full name if so. It exits with zero code if all the flags given on the command line are defined. Otherwise, it exits with code of 1.
The comparison of the flag names is case-insensitive. The arguments given need not include the leading prefix (i.e. the characters up to and including the first underscore character).
Given the previous example, the invocation
$ mailutils --info readline use_libpam pop
will produce the following output:
WITH_READLINE
USE_LIBPAM
ENABLE_POP
and will exit with a zero status.
The following command:
$ mailutils --info readline gssapi pop
will exit with status 1, and will print:
WITH_READLINE
ENABLE_POP
since WITH_GSSAPI flag is not defined.
The flags and their meanings are:
Wherever the mail is and whatever format it is stored in, it is operated upon using the same set of functions. To unified the C API, GNU Mailutils offers a heteroclite set of objects that work in aggregation to do operations on emails. Each object does a specific task and delegates non-related tasks to others. The object comes alive by specifying a URL parameter when created, it will indicate the storage format or protocol (POP3, IMAP4, MH, MAILDIR, etc ..).
mu_folder_t mu_url_t
-/var/mail- +- .. ->+-------------------+ +-->+------------+
( alain *-)-+ | | mu_url_t *-|---+ | port |
---------- | | |-------------------| | hostname |
( jakob *-)-+--+ | mu_auth_t *-|---+ | file |
---------- | |-------------------| | | ... |
( jeff *-)-+ | mu_stream_t | | +------------+
---------- | |-------------------| |
( shaleh*-)-+ | ..... | | mu_auth_t
---------- |-------------------| +-->+-------------+
+---|-* mu_mailbox_t[] | | mu_ticket_t |
mu_mailbox_t | +-------------------+ +-------------+
+-------------------+
| mu_locker_t *--|-------------+
|-------------------| |
| mu_url_t | | mu_locker_t
|-------------------| +-------->+---------+
| mu_stream_t | | lock |
|-------------------| | unlock |
| mu_message_t[] *-|-------+ +---------+
+-------------------+ | mu_envelope_t
| +-------->+-----------+
mu_message_t | | | date |
+-------------------+<------+ | | from |
| mu_envelope_t *-|------------------+ | to |
|-------------------| mu_header_t +-----------+
| mu_header_t *-|------------>+-----------------+
|-------------------| | mu_stream_t |
| mu_body_t *-|----+ +-----------------+
+-------------------+ | mu_body_t
+-->+-----------------+
| mu_stream_t |
+-----------------+
As an example, here is a simplified version of from command. It
lists the ‘From’ and ‘Subject’ headers of every mail in a mailbox.
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <mailutils/mailutils.h>
int
main (int argc, const char **argv)
{
char *from;
char *subject;
mu_mailbox_t mbox;
size_t msgno, total = 0;
int status;
/* Register the formats. */
mu_register_all_mbox_formats ();
status = mu_mailbox_create_default (&mbox, argv[1]);
if (status != 0)
{
mu_error ("mu_mailbox_create: %s", mu_strerror (status));
exit (EXIT_FAILURE);
}
status = mu_mailbox_open (mbox, MU_STREAM_READ);
if (status != 0)
{
mu_error ("mu_mailbox_open: %s", mu_strerror (status));
exit (EXIT_FAILURE);
}
mu_mailbox_messages_count (mbox, &total);
for (msgno = 1; msgno <= total; msgno++)
{
mu_message_t msg;
mu_header_t hdr;
if ((status = mu_mailbox_get_message (mbox, msgno, &msg)) != 0
|| (status = mu_message_get_header (msg, &hdr)) != 0)
{
mu_error ("Error message: %s", mu_strerror (status));
exit (EXIT_FAILURE);
}
if (mu_header_aget_value (hdr, MU_HEADER_FROM, &from))
from = strdup ("(NO FROM)");
if (mu_header_aget_value (hdr, MU_HEADER_SUBJECT, &subject))
subject = strdup ("(NO SUBJECT)");
printf ("%s\t%s\n", from, subject);
free (from);
free (subject);
}
status = mu_mailbox_close (mbox);
if (status != 0)
{
mu_error ("mu_mailbox_close: %s", mu_strerror (status));
exit (EXIT_FAILURE);
}
mu_mailbox_destroy (&mbox);
return 0;
}
Here is a sample output produced by this program:
| % ./sfrom pop://alain@localhost Passwd: xxxx Jim Meyering <meyering@foo.org> fetish(shellutils) beta François Pinard <pinard@bar.org> recode new alpha ... |
/* Prefixmu_folder_is reserved. */#include <mailutils/folder.h>
mu_folder_t mu_url_t
-/var/mail- +---//--->/-------------------\ +-->/-----------\
( alain *-)-+ | | mu_url_t *-|---+ | port |
---------- | | |-------------------+ | hostname |
( jakob *-)-+--+ | mu_observer_t *-| | file |
---------- | |-------------------+ | ... |
( jeff *-)-+ | mu_stream_t | \-----------/
---------- | |-------------------|
( sean *-)-+ | mu_auth_t |
---------- |-------------------|
| mu_mailbox_t(1) |
|-------------------|
| mu_mailbox_t(2) |
| ...... |
| mu_mailbox_t(n) |
\-----------------/
Data structures:
struct mu_list_response
{
int type;
int separator;
char *name;
};
/* Prefixmu_mailbox_is reserved. */#include <mailutils/mailbox.h>
The
mu_mailbox_tobject is used to hold information and it is an opaque data structure to the user. Functions are provided to retrieve information from the data structure.
mu_mailbox_t mu_url_t
-/var/mail- +---//--->/------------------\ +-->/-----------\
( alain ) | | mu_url_t *-|---+ | port |
---------- | |------------------+ | hostname |
( jakob *-)----+ | mu_observer_t *-| | file |
---------- |------------------+ | ... |
( jeff ) | mu_stream_t | \-----------/
---------- |------------------|
( sean ) | mu_locker_t |
---------- |------------------|
| mu_message_t(1) |
|------------------|
| mu_message_t(2) |
| ...... |
| mu_message_t(n) |
\------------------/
The function
mu_mailbox_createallocates and initializes mbox. The concrete mailbox type instantiate is based on the scheme of the url name.The return value is
0on success and a code number on error conditions:
MU_ERR_OUT_PTR_NULL- The pointer mbox supplied is
NULL.MU_ERR_NO_HANDLER- The url name supplied is invalid or not supported.
EINVALENOMEM- Not enough memory to allocate resources.
Create a mailbox with
mu_mailbox_create()based on the environment variable MAIL or the string formed by _PATH_MAILDIR/user" or LOGNAME if user is null,
Destroys and releases resources held by mbox.
A connection is open, if no stream was provided, a stream is created based on the mbox type. The flag can be OR'ed. See
stream_create()for flag's description.The return value is
0on success and a code number on error conditions:
EAGAINEINPROGRESS- Operation in progress.
EBUSY- Resource busy.
MU_ERROR_INVALID_PARAMETER- mbox is
NULLor flag is invalid.ENOMEM- Not enough memory.
The stream attach to mbox is closed.
The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is
NULL.
Get the folder.
The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is
NULL.
Give the uid validity of mbox.
The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is
NULL.
Give the next predicted uid for mbox.
The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is
NULL.
Retrieve message number msgno, message is allocated and initialized.
The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is
NULLor msgno is invalid.ENOMEM- Not enough memory.
The message is appended to the mailbox mbox.
The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is
NULLor message is invalid.
Give the number of messages in mbox.
The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is
NULL.
Give the number of recent messages in mbox.
The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is
NULL.
Give the number of first unseen message in mbox.
The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is
NULL.
All messages marked for deletion are removed.
The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is
NULL.
Gives the mbox size.
The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is
NULL.
Scan the mailbox for new messages starting at message msgno.
The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is
NULL.ENOMEM- Not enough memory.
The mailbox stream is put in stream.
The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is invalid or stream is
NULL.
Set the stream connection to use for the mailbox.
The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox or stream is
NULL.
Get the mu_locker_t object.
The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is
NULL.
Set the type of locking done by the mbox.
The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is
NULL.
Get the property object. The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is
NULL.ENOMEM
Gives the constructed url.
The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is
NULL.
Get a debug object. The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is
NULL.ENOMEM
Get the observable object.
The return value is
0on success and a code number on error conditions:
MU_ERROR_INVALID_PARAMETER- mbox is
NULL.ENOMEM- Not enough memory.
/* Prefixmu_mailer_is reserved. */#include <mailutils/mailer.h>
If from is not
NULL, it must contain a single fully qualified RFC2822 email address which will be used as the envelope from address. This is the address to which delivery status notifications are sent, so it never matters what it is set to until it really matters. This is equivalent to Sendmail's -f flag.The default for from is provided by the specific mailer.
If to is not
NULL, then the message will be sent to the list of addresses that it specifies.The default for to is to use the contents of the standard "To:", "Cc:", and "Bcc:" fields, this is equivalent to Sendmail's -t flag.
Some possible use cases the API must support are:
mu_mailer_send_message(mailer, msg, NULL, NULL)
To: or Apparently-To: header will be added if non is present (for RFC compliance)
mu_mailer_send_message(mailer, msg, from, to)
Resent-[To,From,...]
mu_mailer_send_message(mailer, msg, NULL, to)
mu_mailer_deliver(mailer, msg, address_t("<>"), to)
Don't want mail loops, so the null but valid SMTP address of ‘<>’ is the envelope From.
/sbin/sendmail isn't always Sendmail... Sometimes it's a Sendmail-compatible wrapper, so assume /sbin/sendmail understands only a recipient list, -f and -oi, these seem to be pretty basic. Cross fingers.
Pipe to "/sbin/sendmail -oi [-f from] [to...]", supplying -f if there was a from, and supplying the recipient list from the to (if there is no recipient list, assume it will read the message contents for the recipients).
Caution: since the stdout and stderr of Sendmail
is closed, we have no way of ever giving feedback on failure. Also, what
should the return code be from mu_mailer_send_message() when Sendmail
returns ‘1’? ‘1’ maps to EPERM, which is less than
descriptive!
This mailer does not canonicalize the message. This must be done before sending the message, or it may be assumed that the MTA will do so.
It does blind out the Bcc: header before sending, though.
Caution: Mutt always puts the recipient addresses on the command line, even Bcc: ones, do we strip the Bcc: before forwarding with SMTP?
An address that has no domain is not and RFC822 email address. What do I do with them? Should the user of the API be responsible for determining what is mean by email to "John" means? Or should the be able to configure Sendmail to decide globally what this means. If so, we can pass the address to Sendmail, but we have to decide for SMTP! So, right now these addresses are rejected. This could be changed.
/* Prefixmu_message_is reserved. */#include <mailutils/message.h>
The mu_message_t object is a convenient way to manipulate messages. It
encapsulates the envelope_t, the header_t and the body_t.
mailbox_t
---------- mu_message_t
(message[1]) +------>+--------------------+
---------- | | mu_envelope_t |
(message[2]) | |--------------------|
---------- | | mu_header_t |
(message[3])--------+ |--------------------|
---------- | mu_body_t |
(message[n]) |--------------------|
---------- | mu_attribute_t |
|--------------------|
| mu_stream_t |
+--------------------+
The resources allocate for msg are freed.
Set *multi to non-zero value if msg is multi-part.
/* Prefixmu_envelope_is reserved. */#include <mailutils/envelope.h>
Get the address that this message was reportedly received from. This would be the "mail from" argument if the message was delivered or received via SMTP, for example.
Primarily for internal use. The implementation of
mu_envelope_tdepends on the mailbox type, this allows the function which actually gets the sender to be set by the creator of anmu_envelope_t.
Get the date that the message was delivered to the mailbox, in something close to ANSI
ctime()format: Mon Jul 05 13:08:27 1999.
Primarily for internal use. The implementation of
mu_envelope_tdepends on the mailbox type, this allows the function which actually gets the date to be set by the creator of anmu_envelope_t.
/* Prefixmu_header_is reserved. */#include <mailutils/header.h>
So far we plan support for RFC822 and plan for RFC1522. With RFC1522 non-ASCII characters will be encoded.
Initialize a hdr to a supported type. If blurb is not
NULL, it is parsed.
The resources allocated for hdr are freed.
Some basic macros are already provided for RFC822.
MU_HEADER_UNIX_FROM- From
MU_HEADER_RETURN_PATH- Return-Path
MU_HEADER_RECEIVED- Received
MU_HEADER_DATE- Date
MU_HEADER_FROM- From
MU_HEADER_SENDER- Sender
MU_HEADER_RESENT_FROM- Resent-From
MU_HEADER_SUBJECT- Subject
MU_HEADER_SENDER- Sender
MU_HEADER_RESENT_SENDER- Resent-SENDER
MU_HEADER_TO- To
MU_HEADER_RESENT_TO- Resent-To
MU_HEADER_CC- Cc
MU_HEADER_RESENT_CC- Resent-Cc
MU_HEADER_BCC- Bcc
MU_HEADER_RESENT_BCC- Resent-Bcc
MU_HEADER_REPLY_TO- Reply-To
MU_HEADER_RESENT_REPLY_TO- Resent-Reply-To
MU_HEADER_MESSAGE_ID- Message-ID
MU_HEADER_RESENT_MESSAGE_ID- Resent-Message-ID
MU_HEADER_IN_REPLY_TO- In-Reply-To
MU_HEADER_REFERENCE- Reference
MU_HEADER_REFERENCES- References
MU_HEADER_ENCRYPTED- Encrypted
MU_HEADER_PRECEDENCE- Precedence
MU_HEADER_STATUS- Status
MU_HEADER_CONTENT_LENGTH- Content-Length
MU_HEADER_CONTENT_LANGUAGE- Content-Language
MU_HEADER_CONTENT_TRANSFER_ENCODING- Content-transfer-encoding
MU_HEADER_CONTENT_ID- Content-ID
MU_HEADER_CONTENT_TYPE- Content-Type
MU_HEADER_CONTENT_DESCRIPTION- Content-Description
MU_HEADER_CONTENT_DISPOSITION- Content-Disposition
MU_HEADER_CONTENT_MD5- Content-MD5
MU_HEADER_MIME_VERSION- MIME-Version
MU_HEADER_X_UIDL- X-UIDL
MU_HEADER_X_UID- X-UID
MU_HEADER_X_IMAPBASE- X-IMAPbase
MU_HEADER_ENV_SENDER- X-Envelope-Sender
MU_HEADER_ENV_DATE- X-Envelope-Date
MU_HEADER_FCC- Fcc
MU_HEADER_DELIVERY_DATE- Delivery-date
MU_HEADER_ENVELOPE_TO- Envelope-to
Value of field-name fn is returned in buffer fv of size len. The number of bytes written is put in n.
The value is allocated.
/* Prefixmu_body_is reserved. */#include <mailutils/body.h>
/* Prefixmu_attribute_is reserved. */#include <mailutils/attribute.h>
#include <mailutils/stream.h>
These generic flags are interpreted as appropriate to the specific streams.
MU_STREAM_READMU_STREAM_WRITEMU_STREAM_RDWRMU_STREAM_APPENDMU_STREAM_CREATMU_STREAM_NONBLOCKMU_STREAM_NO_CHECKMU_STREAM_SEEKABLEMU_STREAM_NO_CLOSEMU_STREAM_ALLOW_LINKSIf
MU_STREAM_NO_CLOSEis specified,fclose()will not be called on stdio when the stream is closed.
Used to implement a new kind of stream.
MU_STREAM_STATE_OPEN- Last action was
mu_stream_open.MU_STREAM_STATE_READ- Last action was
mu_stream_readormu_stream_readline.MU_STREAM_STATE_WRITE- Last action was
mu_stream_write.MU_STREAM_STATE_CLOSE- Last action was
mu_stream_close.
An example using mu_tcp_stream_create() to make a simple web client:
/* This is an example program to illustrate the use of stream functions.
It connects to a remote HTTP server and prints the contents of its
index page */
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <sys/time.h>
#include <mailutils/mailutils.h>
char wbuf[1024];
char rbuf[1024];
size_t io_timeout = 3;
size_t io_attempts = 3;
int
http_stream_wait (mu_stream_t stream, int flags, size_t *attempt)
{
int rc;
int oflags = flags;
struct timeval tv;
while (*attempt < io_attempts)
{
tv.tv_sec = io_timeout;
tv.tv_usec = 0;
rc = mu_stream_wait (stream, &oflags, &tv);
switch (rc) {
case 0:
if (flags & oflags)
return 0;
/* FALLTHROUGH */
case EAGAIN:
case EINPROGRESS:
++*attempt;
continue;
default:
return rc;
}
}
return ETIMEDOUT;
}
int
main (int argc, char **argv)
{
int ret, off = 0;
mu_stream_t stream;
size_t nb, size;
size_t attempt;
char *url = "www.gnu.org";
if (argc > 3)
{
fprintf (stderr, "usage: %s [hostname [url]]\n", argv[0]);
exit (1);
}
if (argc > 1)
url = argv[1];
snprintf (wbuf, sizeof wbuf, "GET %s HTTP/1.0\r\n\r\n",
argc == 3 ? argv[2] : "/");
ret = mu_tcp_stream_create (&stream, url, 80, MU_STREAM_NONBLOCK);
if (ret != 0)
{
mu_error ("mu_tcp_stream_create: %s", mu_strerror (ret));
exit (EXIT_FAILURE);
}
for (attempt = 0; (ret = mu_stream_open (stream)); )
{
if ((ret == EAGAIN || ret == EINPROGRESS) && attempt < io_attempts)
{
ret = http_stream_wait(stream, MU_STREAM_READY_WR, &attempt);
if (ret == 0)
continue;
}
mu_error ("mu_stream_open: %s", mu_strerror (ret));
exit (EXIT_FAILURE);
}
for (attempt = 0, size = strlen (wbuf); size > 0; )
{
ret = mu_stream_write (stream, wbuf + off, strlen (wbuf), 0, &nb);
if (ret == 0)
{
if (nb == 0)
{
mu_error("mu_stream_write: wrote 0 bytes");
exit (EXIT_FAILURE);
}
off += nb;
size -= nb;
}
else if (ret == EAGAIN)
{
if (attempt < io_attempts)
{
ret = http_stream_wait (stream, MU_STREAM_READY_WR, &attempt);
if (ret)
{
mu_error ("http_wait failed: %s", mu_strerror (ret));
return -1;
}
continue;
}
else
{
mu_error ("mu_stream_write timed out");
exit (EXIT_FAILURE);
}
}
else
{
mu_error ("mu_stream_write: %s", mu_strerror (ret));
exit (EXIT_FAILURE);
}
}
attempt = 0;
for (;;)
{
ret = mu_stream_read (stream, rbuf, sizeof (rbuf), 0, &nb);
if (ret == 0)
{
if (nb == 0)
break;
write (1, rbuf, nb);
}
else if (ret == EAGAIN)
{
if (attempt < io_attempts)
{
ret = http_stream_wait (stream, MU_STREAM_READY_RD, &attempt);
if (ret)
{
mu_error ("http_stream_wait failed: %s", mu_strerror (ret));
exit (EXIT_FAILURE);
}
}
else
{
mu_error ("mu_stream_read: %s", mu_strerror (ret));
exit (EXIT_FAILURE);
}
}
}
ret = mu_stream_close (stream);
if (ret != 0)
{
mu_error ("mu_stream_close: %s", mu_strerror (ret));
exit (EXIT_FAILURE);
}
mu_stream_destroy (&stream, NULL);
exit (EXIT_SUCCESS);
}
/* Prefixmu_iterator_is reserved. */#include <mailutils/iterator.h>