|
|
|
mail [ -tw ] [ -m message_type ] recipient...
rmail [ -tw ] [ -m message_type ] recipient...
mail [ -ehpPqr ] [ -f file ]
mail [ -x debug_level ] [ other_mail_options ] recipient...
A recipient is usually a user name recognized by login.1 When recipients are named, mail assumes a message is being sent. It reads from the standard input up to an end-of-file (CTRL-D) or, if reading from a terminal device, until it reads a line consisting of just a period. When either of those indicators is received, mail adds the letter to the mailfile for each recipient.
A letter is composed of some header lines followed by a blank line followed by the message content. The header lines section of the letter consists of one or more UNIX postmarks:
followed by one or more standardized message header lines of the form:
where keyword-name is comprised of any printable, non-whitespace characters other than colon (`:'). A Content-Length: header line, indicating the number of bytes in the message content will always be present unless the letter consists of only header lines with no message content. A Content-Type: header line that describes the type of the message content (such as text, binary, multipart, etc.) will also be present unless the letter consists of only header lines with no message content. Header lines may be continued on the following line if that line starts with white space.
The following command-line arguments affect sending mail:
If a letter is found to be undeliverable, it is returned to the sender with diagnostics that indicate the location and nature of the failure. If mail is interrupted during input, the message is saved in the file dead.letter to allow editing and resending. dead.letter is always appended to, thus preserving any previous contents. The initial attempt to append to (or create) dead.letter will be in the current directory. If this fails, dead.letter will be appended to (or created in) the user's login directory. If the second attempt also fails, no dead.letter processing will be done.
rmail only permits the sending of mail; uucp.1c uses rmail as a security precaution. Any application programs that generate mail messages should be sure to invoke rmail rather than mail for message transport and/or delivery.
If the local system has the Basic Networking Utilities installed, mail may be sent to a recipient on a remote system. There are numerous ways to address mail to recipients on remote systems depending on the transport mechanisms available to the local system. The two most prevalent addressing schemes are UUCP-style and Domain-style.
The following command-line arguments affect reading mail:
mail,
unless otherwise influenced by command-line arguments,
prints a user's mail messages
in last-in, first-out order.
The default mode for printing messages is to display only
those header lines of immediate interest.
These include, but are not limited to,
the UNIX
From
and
>From
postmarks,
From:,
Date:,
Subject:,
and
Content-Length:
header lines,
and any recipient header lines such as
To:,
Cc:,
Bcc:,
and so forth.
After the header lines
have been displayed,
mail
will display the contents (body) of the message only if it
contains no unprintable characters.
Otherwise,
mail
will issue a warning statement about the message
having binary content and
not
display the content.
(This may be overridden via the
p
command. See below.)
For each message, the user is prompted with a ? and a line is read from the standard input. The following commands are available to determine the disposition of the message:
When a user logs in, the presence of mail,
if any,
is usually indicated.
Also,
notification is made if new mail arrives while using
mail.
The permissions of mailfile may be manipulated using chmod.1 in two ways to alter the function of mail. The other permissions of the file may be read-write (0666), read-only (0664), or neither read nor write (0660) to allow different levels of privacy. If changed to other than the default (mode 0660), the file will be preserved even when empty to perpetuate the desired permissions. (The administrator may override this file preservation using the DEL_EMPTY_MAILFILE option of mailcnfg.)
The group ID of the mailfile must be mail to allow new messages to be delivered, and the mailfile must be writable by group mail.
The following command-line arguments cause mail to provide debugging information:
The -x option causes mail to create a file named /tmp/MLDBGprocess_id that contains debugging information relating to how mail processed the current message. The absolute value of debug_level controls the verboseness of the debug information. 0 implies no debugging. If debug_level is greater than 0, the debug file will be retained only if mail encountered some problem while processing the message. If debug_level is less than 0 the debug file will always be retained. The debug_level specified via -x overrides any specification of DEBUG in /etc/mail/mailcnfg. The information provided by the -x option is esoteric and is probably only useful to system administrators.
Transport-Options: [ /options ]
Default-Options: [ /options ]
>To: recipient [ /options ]
Where the ``/options'' may be one or more of the following:
The default is /nodelivery/return. If contradictory options are used, the first will be recognized and later, conflicting, terms will be ignored.
+---------------+-----------------+ |ATTRIBUTE TYPE | ATTRIBUTE VALUE | +---------------+-----------------+ |Availability | SUNWcsu | +---------------+-----------------+
The interpretation and resulting action taken because of the header lines described in the Delivery Notifications section above will only occur if this version of mail is installed on the system where the delivery (or failure) happens. Earlier versions of mail may not support any types of delivery notification.
Conditions sometimes result in a failure to remove a lock file.
After an interrupt, the next message may not be printed; printing may be forced by typing a p.
|
|
|
Created by unroff & hp-tools. © by Hans-Peter Bischof. All Rights Reserved (1997).
Last modified 07/October/97