| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GNU Mailutils provides a set of programs for handling the e-mail.
3.1 Mailutils Configuration File Common Configuration File. 3.2 Authorization and Authentication Principles
3.3 frm-- List Headers from a MailboxList Headers from a Mailbox. 3.4 Send and Receive Mail. 3.5 messages-- Count the Number of Messages in a MailboxCount the Number of Messages in a Mailbox. 3.6 movemail-- Moves Mail from the User Maildrop to the Local FileMoves Mail from the User Maildrop to the Local File. 3.7 readmsg-- Extract Messages from a FolderExtract Messages from a Folder.
3.8 sieveMail Filtering Utility. 3.9 guimb-- A Mailbox Scanning and Processing LanguageMailbox Scanning and Processing Language.
3.10 mail.local-- Deliver Mail to the Local MailboxDeliver Mail to the Local Mailbox. 3.11 mail.remote-- Pseudo-Sendmail Interface for Mail DeliveryPseudo-Sendmail Interface for Mail Delivery.
3.12 POP3 Daemon 3.13 IMAP4 Daemon 3.14 Comsat Daemon
3.15 MH -- The MH Message Handling System The MH Message Handling System.
3.16 mailutils-config-- Get the Information about the Mailutils BuildGet the Information about the Mailutils Build.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
There are some command line options that are used so often that it is inconvenient to specify them in the command line each time you run a Mailutils utility. The configuration files provide a way to add default command line arguments without having to type them in the command line. Upon startup, each Mailutils utility scans and processes the contents of the three startup files, none of which are required to exist:
`mailutils.rc', found in your your system configuration directory (usually `/etc' or `/usr/local/etc').
Usually `~/.mailutils', unless `~/.mailutils' is a directory, in which case `~/.mailutils/mailutils' is used.
Usually `~/.mu.programrc', unless `~/.mailutils' is a directory, in which case `~/.mailutils/programrc' is used (where program means the program name).
These files have simple line-oriented syntax. Comments begin with the pound sign (`#') and extend through the end of the line (1). Very long lines may be split across several lines by escaping final newline with a backslash (`\') character.
In the non-program-specific configuration files, any configuration line must start with a tag. In the program-specific configuration file the tag must not be present, all options are for that specific program.
A tag is either a name of a particular Mailutils utility or option group, prefixed with colon (`:'). The command line options common for several Mailutils programs are divided into option groups or capabilities, e.g. the options `--mail-spool' and `--lock-flags' form group `mailbox'. These groups are discussed in detail below.
When processing the non-program-specific configuration files, a Mailutils utility selects those lines whose tag is either the name of that utility or the name of the option group supported by it. In the program-specific configuration file, all lines are selected. For each line found, its tag (if present) is stripped away, and the rest of the line is split up into words. These words are regarded as command line options and are inserted to the program arguments before any options from the command line. Thus the options from `.mailutils' take precedence over those from `mailutils.rc', and the options from the command line take precedence over those from all three configuration files.
The word splitting occurs at whitespace characters and is similar to that performed by the shell. If an option must contain embedded whitespace, it should be enclosed in a pair of quotes (either double or single quotes).
3.1.1 Common Options understood by most GNU utilities. 3.1.2 Mailbox Specifies the mail spool location, and locking strategy. 3.1.3 Mailer Sets the mailer URL. 3.1.4 Address Specifies the default email address and domain. 3.1.5 Daemon Options common for daemon programs. 3.1.6 Auth Authentication-specific options. 3.1.7 Encryption Encryption options. 3.1.8 Logging Logging control options. 3.1.9 Sieve Specific Options Sieve specific options 3.1.10 A Sample Configuration File A sample configuration file.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Each program understands the following informational options:
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Option group `mailbox' consists of options used to specify the location of the mail spool, and the locking strategy.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This option group overrides the default mailer URL (sendmail:).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Option group `address' consists of options used to specify how to qualify email addresses.
An unqualified address (one without an @) is qualified by appending
@defaultdomain. defaultdomain is the return of
gethostname(), or the result of gethostbyname() on the return
of gethostname() (if the DNS lookup is successful).
If the email address of the current user is needed, either the address set by `--email-addr' is returned, or the current uid is looked up in the user database, and qualified with the defaultdomain.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
These options control the authorization and authentication module lists. For a description of authentication concepts, refer to See section 3.2 Authorization and Authentication Principles.
This option allows to set up a list of modules to be used for authorization. modlist is a colon-separated list of modules. Valid modules are:
This option allows to set up a list of modules to be used for authentication. modlist is a colon-separated list of modules. Valid modules are:
The following options exist in this group if the package was configured with `--enable-sql' option. They take effect only if the `sql' module is used in authentication and/or authorization.
mailutils was compiled with support for several
SQL drivers.
If this option is omitted, mailutils will use the first
available SQL driver.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
These options control TLS/SSL encryption in imap4d
and pop3d daemons.
imap4d or pop3d daemons will
refuse to support TLS/SSL encryption.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
syslog facility. The following
facility names are recognized: `user', `daemon', `mail',
`auth' and `local0' through `local7'. These names are
case-insensitive.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following options comprise this group:
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following configuration file specifies that all Mailutils programs
should use `/var/spool/mail' as a local mailspool
directory. Programs performing authentication will use PAM
service `mailutils'. All programs, except imap4d will
issue log messages via `mail' facility, imap4d will use
facility `local1'.
:mailbox --mail-spool /var/spool/mail :auth --authentication pam --pam-service mailutils :logging --log-facility mail imap4d --daemon=20 --timeout=1800 --log-facility local1 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 either a one of them succeeds or the list is exhausted. In 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.
We represent the module lists as column-separated lists of module names. 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 modules available for use in authorization list are:
The modules available for use in authentication list are:
Unless overridden by `--authentication' command line option, the list of authentication modules is:
generic:system:pam:sql |
Unless overridden by `--authorization' command line option, the list of authorization modules is:
system:sql:virtdomains |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
frm -- List Headers from a Mailbox
The frm command outputs a header information of
the selected messages in a mailbox. By default, frm reads the
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 program uses following option groups: See section 3.1.2 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.
frm program from Elm package.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
mail -- Send and Receive Mail
Mail is an enhanced version of standard /bin/mail program.
As well as its predecessor, it can be used either in sending mode or
in reading mode. Mail enters sending mode when one or more
email addresses were specified in this command line. In this mode the
program waits until user finishes composing the message, then attempts
to send it to the specified addresses and exits.
See 3.4.3 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 3.4.4 Reading Mail.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
mail
General usage of mail program is:
mail [option...] [address...] |
mail switches to
mail sending mode, otherwise it operates in mail reading mode.
The program uses following option groups: See section 3.1.2 Mailbox.
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).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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:
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 section 3.4.6 How to Alter the Behavior of mail).
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 |
~< 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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To read messages from a given mailbox, use one of the following ways of
invoking mail:
mail
mail --file
mail --file=path_to_mailbox
mail --user=user
Please note, that usual mailbox permissions won't allow you to use the last variant of invocation, unless you are a super-user. Similarly, the last but one variant is also greatly affected by the permissions the target mailbox has.
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 3.4.7 Personal and System-wide 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:
mail was operating upon user's system
mailbox, then all undeleted and unsaved messages that have been read and
are not marked with hold flag are saved to the user's mbox file
(`$HOME/mbox'). The messages, marked with delete are removed.
The program exits to the Shell, unless saving the mailbox fails, in
which case user can escape with the exit command.
Typing EOF (`C-D') alone is equivalent to `quit'.
Following commands can be used during the session to request online help:
$HOME is
assumed.
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 |
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.
For each message in msglist, switches to compose mode and sends the composed message to the sender and all recipients of the message.
Like reply, except that the composed message is sent only to
originators of the specified messages.
Switches to compose mode. After composing, sends the message to the originators and recipients of all messages in msglist.
Similar to followup, but reply message is sent only to
originators of messages in msglist.
To determine the sender of the message mail uses the
list of sender fields (see section 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 !.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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:
mail is operating in mail sending mode.
mail is operating in mail reading mode.
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 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
mail
Following variables control the behavior of GNU mail:
Sign
Contains the filename holding users signature. The contents of this
file is appended to the end of a message being composed by ~A
escape.
appenddeadletter
If this variable is True, the contents of canceled letter is
appended to the user's `dead.letter' file. Otherwise it overwrites
its contents.
askbcc
When set to True the user will be prompted to enter Bcc
field before composing the message.
askcc
When set to True the user will be prompted to enter Cc
field before composing the message.
asksub
When set to True the user will be prompted to enter Subject
field before composing the message.
autoinc
Automatically incorporate newly arrived messages.
autoprint
Causes the delete command to behave like dp - thus, after deleting a message, the next one will be typed automatically.
datefield
By default the date in a header summary is taken from the SMTP
envelope of the message. Setting this variable tells mail
to use the date from Date: header field, converted to
localtime. Notice, that for messages lacking this field mail
will fall back to using SMTP envelope.
charset
The value of this variable controls the output character set for the
header fields encoding using RFC 2047. If the variable is unset, no
decoding is performed and the fields are printed as they are. If the
variable is set to `auto', mail tries to deduce the
name of the character set from the value of LC_ALL environment
variable. Otherwise, its value is taken as the name of the charset.
cmd
Contains default shell command for pipe.
columns
COLUMNS is used.
This variable contains the number of columns on terminal screen.
crt
The variable crt determines the minimum number of lines the body
of the message must contain in order to be piped through pager command
specified by environment variable PAGER. If crt is set
to a numeric value, this value is taken as the threshold. Otherwise,
if crt is set without a value, then the height of the terminal
screen is used to compute the threshold. The number of lines on
screen is controlled by screen variable.
decode-fallback
This variable controls the way to represent characters that cannot be rendered using current character set. It can have three values:
dot
If True, causes mail to interpret a period alone on a line as the
terminator of a message you are sending.
emptystart
If the mailbox is empty, mail normally prints `No mail for user' and
exits immediately. If this option is set, mail will start no matter is
the mailbox empty or not.
editheaders
When set, mail will include message headers in the text to
be the ~e and ~v escapes, thus allowing you to customize
the headers.
escape
If defined, the first character of this option gives the character to denoting escapes.
folder
The name of the directory to use for storing folders of messages. If
unset, $HOME is assumed.
header
Whether to run headers command automatically after entering
interactive mode.
hold
When set to True, the read or saved messages will be stored in
user's mailbox (`$HOME/mbox'). Otherwise, they will be held in
system mailbox also. This option is in effect only when operating
upon user's system mailbox.
ignore
When set to True, mail will ignore keyboard interrupts
when composing messages. Otherwise an interrupt will be taken as a
signal to abort composing.
ignoreeof
Controls whether typing EOF character terminates the letter being composed.
indentprefix
String used by the ~m tilde escape for indenting quoted messages.
keepsave
Controls whether saved messages should be kept in system mailbox too. This variable is in effect only when operating upon a user's system mailbox.
mailx
When set, enables mailx compatibility mode. This mode has the following effects:
mail will ask
for Cc and Bcc addresses after composing the body.
The default behavior is to ask for these values before composing
the body.
mail
will exit with zero status. By default it exits with zero status only
if the message was sent successfully.
metoo
Usually, when an alias is expanded that contains the sender, the sender is removed from the expansion. Setting this option causes the sender to be included in the group.
mode
Setting this variable does not affect the operation mode of the program.
regex
Setting this to True enables use of regular expressions in
`/.../' message specifications.
outfolder
Contains the directory in which files created by save,
write, etc. commands will be stored. When unset, current
directory is assumed.
page
If set to True, the pipe command will emit a linefeed
character after printing each message.
prompt
Contains the command prompt sequence.
quit
When set, causes keyboard interrupts to terminate the program.
rc
When this variable is set, mail will read the system-wide
configuration file upon startup. See 3.4.7 Personal and System-wide Configuration Files.
record
When set, any outgoing message will be saved to the named file.
replyprefix
Sets the prefix that will be used when constructing the subject line of a reply message.
replyregex
Sets the regular expression used to recognize subjects of reply
messages. If the Subject header of the message matches this
expression, the value of replyprefix will not be prepended to
it before replying. The expression should be a POSIX extended regular
expression. The comparison is case-insensitive.
For example, to recognize usual English, Polish, Norwegian and German reply subject styles, use:
set replyregex="^(re|odp|aw|ang)(\\[[0-9]+\\])?:[[:blank:]]" |
(Notice the quoting of backslash characters).
save
When set, the aborted messages will be stored in the user's
`dead.file'. See also appenddeadletter.
screen
LINES is used.
This variable contains the number of lines on terminal screen.
sendmail
Contains the URL of mail transport agent.
sign
Contains the user's signature. The contents of this variable is appended
to the end of a message being composed by ~a escape. Use
Sign variable, if your signature occupies more than one line.
subject
Contains default subject line. This will be used when asksub is
off.
toplines
Number of lines to be displayed by top and Top commands.
verbose
When set, the actual delivery of messages is displayed on the user's terminal.
xmailer
Controls whether the header `X-Mailer' should be added to outgoing messages. The default value of this header is
X-Mailer: mail (GNU Mailutils 0.6) |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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'.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
messages -- Count the Number of Messages in a Mailbox
Messages prints on standard output the number of messages
contained in each folder specified in command line. If no folders
are specified, it operates upon user's system mailbox. For each
folder, the following output line is produced:
Number of messages in folder: number |
where folder represents the folder name, number represents the number of messages.
The program uses following option groups: See section 3.1.2 Mailbox.
The program accepts following command line options:
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
movemail -- Moves Mail from the User Maildrop to the Local File
The purpose of movemail, as its name implies, is to move mail
from one location to another. For example, the following invocation:
movemail /var/mail/smith INBOX |
moves messages from file `/var/mail/smith' to file `INBOX'.
You will probably never have to run this program manually. It is
intended as a replacement for movemail from GNU Emacs. The
movemail program is run by Emacs Rmail
module. See section `Rmail' in Reading Mail with 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.
3.6.1 Movemail Options Description of the Available Options 3.6.2 Summary of Movemail Usage Short Movemail Invocation Summary
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
movemail [option...] inbox destfile [remote-password] |
The first argument, inbox, is the URL (see section 4.1.14 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.(2). 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:
dotlock,
`R' -- retry 10 times if acquiring of the lock failed (see also
`--lock-retry-count' below), `T' -- remove stale locks
after 10 minutes (see also `--lock-expire-timeout',
and `P' -- write process PID to the lock file.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
readmsg -- Extract Messages from a Folder The program, readmsg, extracts with the selection argument messages from a mailbox. Selection can be specify by:
readmsg 1 3 0 |
readmsg staff meeting |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
sieve Sieve is a language for filtering e-mail messages at time of final delivery, described in RFC 3028. GNU Mailutils provides two implementations of this language: a stand-alone sieve interpreter and a sieve translator and filter. The following sections describe these utilities in detail.
3.8.1 A Sieve Interpreter 3.8.2 A Sieve to Scheme Translator and Filter
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 section 5. Sieve Language,
for a description of the Sieve language. See section 5.8 GNU Extensions, for a
discussion of differences between the GNU implementation of Sieve and
its standard.
Invoking sieveLogging and debugging Extending sieve
sieve
The sieve invocation syntax is:
sieve [options] script |
where script denotes the filename of the sieve program to parse, and options is one or more of the following:
| `g' | Enable main parser traces |
| `T' | Enable mailutil 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.
Apart from these, sieve understands the options from the
following groups: sieve, mailbox, mailer,
logging.
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 (see section 3.1.8 Logging).
This option causes sieve to output its diagnostics to
the given syslog facility.
sieve
The basic set of sieve actions, tests and comparators may be extended
using loadable extensions. Usual require mechanism is used for
that.
When processing arguments for require statement, sieve
uses the following algorithm:
LTDL_LIBRARY_PATH.
#searchpath directive.
LD_LIBRARY_PATH).
The value of LTDL_LIBRARY_PATH and LD_LIBRARY_PATH must be
a colon-separated list of absolute directories, for example,
`"/usr/lib/mypkg:/lib/foo"'.
In any of these directories, sieve first attempts to find
and load the given filename. If this fails, it tries to append the
following suffixes to the file name:
sieve executes its
initialization function (see below) and again looks up the name
in the symbol table. If found, search terminates successfully.
sieve then displays
the following diagnostic message:
source for the required action NAME is not available |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 1.4 on the system. For more information on Guile refer to
section `Overview' in The Guile Reference Manual.
The Scheme programs produced by sieve.scm can be used with
guimb or mail.local.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
guimb -- A Mailbox Scanning and Processing Language
Guimb is for mailboxes what awk is for text files.
It processes mailboxes, applying the user-supplied scheme procedures
to each of them in turn and saves the resulting output in mailbox
format.
The program uses following option groups: See section 3.1.2 Mailbox.
Specifying Scheme Program to Execute Specifying Mailboxes to Operate Upon Passing Options to Scheme Command Line Option Summary
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 defmbox
guimb [options] --mailbox defmbox mailbox [mailbox...]
guimb [options] --user username [mailbox...]
guimb as a mail delivery agent.
If no mailboxes are specified in the command line, guimb reads
and processes the system mailbox of the current user.
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
mail.local -- Deliver Mail to the Local Mailbox
mail.local reads the standard input up to an end-of-file
and appends the received data to the local mailboxes.
3.10.1 Invoking mail.localMail.local options 3.10.2 Using mail.localwith Various MTAsUsing mail.local with various MTAs 3.10.3 Setting up Mailbox Quotas Setting up mailbox quotas. 3.10.4 Implementing User-defined Sieve Mail Filters Implementing user-defined Sieve mail filters. 3.10.5 Implementing User-defined Scheme Mail Filters Implementing user-defined Scheme mail filters.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
mail.local
General usage of mail.local program is:
mail.local [option...] recipient [recipient ...] |
If recipient part is present is a FQDN, mail.local
will attempt to deliver to a virtual host.
The program uses following option groups: See section 3.1.2 Mailbox, See section 3.1.6 Auth,
See section 3.1.8 Logging, See section 3.8 sieve.
mail.local to
add `From ' envelope to the beginning of the message. If it is
not specified, mail.local first looks into the first line
from the standard input. If it starts with `From ', it is assumed
to contain a valid envelope. If it does not, mail.local
creates the envelope by using current user name and date.
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
mail.local with Various MTAs
This section explains how to invoke mail.local from
configuration files of various Mail Transport Agents.
All examples in this section suppose that mail.local
must receive following command line switches:
-s %h/.filter.scm -q /etc/mail/userquota |
Using mail.localwith SendmailUsing mail.localwith Exim
mail.local with Sendmail
The mail.local must be invoked from the local mailer
definition in the `sendmail.cf' file. It must have the
following flags set `lswS', meaning the mailer is local,
the 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, `fn' flags may be specified to allow
mail.local to generate usual `From ' envelope
instead of the one supplied by sendmail.
If you wish to use mail.local with SQL authentication, you may
wish 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/libexec/mail.local,
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/libexec/mail.local') define(`LOCAL_MAILER_ARGS', `mail $u') |
mail.local with Exim
Using mail.local with Exim is quite straightforward. The
following example illustrates the definition of appropriate transport
and director in `exim.conf':
# transport mail_local_pipe: driver = pipe command = /usr/local/libexec/mail.local $local_part return_path_add delivery_date_add envelope_to_add # director mail_local: driver = localuser transport = mail_local_pipe |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Sometimes it is necessary to limit the maximum size of a user's mailbox. Such maximum size is called mailbox quota for this user.
When delivering a message, mail.local first cheks if
the mailbox quota is specified for the recipient. If so,
mail.local computes the difference between the quota
value and the actual size of the recipient's mailbox. This difference
represents the maximum size of the message the receipient's mailbox is
able to accomodate. Let's call it msize. Depending on its value,
mail.local takes decision on whether to deliver the message.
There are three possible cases:
user: mailbox quota exceeded for this recipient |
mail.local is about to deliver. In this case the message is
not delivered and the sender receives following notification message:
user: message would exceed maximum mailbox size for this recipient |
mail.local does deliver the message.
Version 0.6 of GNU mailutils is able to retrieve mailbox quotas from a DBM or SQL database.
3.10.3.1 Keeping Quotas in DBM Database 3.10.3.2 Keeping Quotas in SQL Database
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To use the DBM quota database, your copy of mailutils must
be compiled with DBM support (one of `--with-gdbm',
`--with-db2', `--with-ndbm', `--with-dbm' options
to configure). Examine the of
mail.local --show-config-options if not sure.
The quota database should have the following structure:
A special value `NONE' means no mailbox size limitation 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 database, specify its full name using `-q'
or `--quota-db' in the invocation of mail.local. For
example, in sendmail .mc file:
define(`LOCAL_MAILER_PATH', `/usr/local/libexec/mail.local') define(`LOCAL_MAILER_ARGS', `mail -q /etc/mail/quota.db $u') |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Option `--quota-query' allows to specify a special query to retrieve the quota from the database. Currently (as of mailutils version 0.6) it is assumed that this table can be accessed using the same credentials as SQL authentication tables (See section 3.1.5 Daemon, for the detailed discussion of `--sql-' options).
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 the quota for user %u you may then use the
following query:
SELECT quota FROM mailbox_quota WHERE user_name='%u' |
There is 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. Mail.local
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. For the following discussion,
it is important that the user_name column for this entry be
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 ('%u','00DEFAULT')
ORDER BY user_name DESC
|
will return two tuples if user %u is found in
mailbox_quota. Due to ORDER statement, the first tuple
will contain the quota for the user, which will be used by
mail.local. On the other hand, if user name %u is not
present in the table, the above query will return a single tuple
containing the group quota.
To summarize this, here is a working `mailutils.rc' entry for
mail.local:
:mail.local \
--sql-db MAILAUTH \
--sql-host some.host.net \
--sql-user mail.local \
--sql-passwd guessme \
--quota-query "SELECT quota \
FROM mailbox_quota \
WHERE user_name IN ('%u','00DEFAULT') \
ORDER BY user_name DESC"
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
mail.remote -- Pseudo-Sendmail Interface for Mail Delivery [FIXME]
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 program uses following option groups: See section 3.1.2 Mailbox, See section 3.1.5 Daemon, See section 3.1.8 Logging, See section 3.1.6 Auth.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
3.13.1 Namespace 3.13.2 Starting imap4dInvocation Options.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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:
LIST command, that is he can access a
mailbox only if he knows exactly its location.
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' options.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
imap4d
imap4d may run either in standalone or in inetd
operation modes. When run in "standalone" mode, the server disconnects
from the terminal and runs as a daemon, forking a child for each new
connection.
The "inetd" mode allows to start the server from `/etc/inetd.conf' file. This is the default operation mode.
imap4 stream tcp nowait root /usr/local/sbin/imap4d imap4d |
The program uses following option groups: See section 3.1.2 Mailbox, See section 3.1.5 Daemon, See section 3.1.8 Logging, See section 3.1.6 Auth.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
3.14.1 Starting comsatdInvocation. 3.14.2 Configuring comsatdConfiguration of comsatd.A per-user Configuration File A per-user configuration file.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
comsatd
Comsatd uses following option groups: See section 3.1.2 Mailbox,
See section 3.1.5 Daemon, See section 3.1.8 Logging.
comsatd.
comsat dgram udp wait root /usr/sbin/comsatd \ comsatd -c /etc/comsat.conf |
This is the default operation mode.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
comsatd
The configuration parameters for comsatd are kept in a single
configuration file. The file uses line-oriented format: each line
contains a single statement. Comments are introduced with the `#'
sign and empty lines are ignored. You can specify the configuration
file to use by using `-c' or `--config' command line switch.
The configuration file statements can logically be subdivided into General Settings, Security Settings and Access Control Lists. The following sections address each of these statement group in detail.
General Settings Security Settings Access Control Lists
These statements control the general behavior of the comsat daemon:
These statements control the way comsatd fights possible
flooding attacks.
Access control lists determine from which addresses comsatd
will receive mail notification messages.
The access control lists are introduced in configuration file using keyword `acl'. General format for an ACL rule is
acl action netlist |
Here, action specifies the action to be taken when a request arrives from one of the networks, listed in netlist. There are two possible actions: `allow' and `deny'.
The netlist is a whitespace-separated list of network numbers. Each network number may be specified in one of the following forms:
Upon receiving a notification message, comsatd compares its
source address against each ACL rule in the order of their appearance
in the configuration file. The first rule that matches the packet
determines whether the message will be processed or rejected. If
no matching rule was found, the default rule applies. Currently, default
rule is
acl allow any |
If you don't need such behavior, specify the default rule explicitly. For example, the common use would be:
acl allow 127.0.0.1 acl deny any |
which makes comsatd receive the notification messages from
localhost only.
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 section 3.14.2 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"
|
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"
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[FIXME]
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
mailutils-config -- Get the Information about the Mailutils Build 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.
Getting Compiler Flags Getting Loader Flags Obtaining General Build Information
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.
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=0.4.1 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 |
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:
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |