MAILX(1) General Commands Manual MAILX(1)

mailx — process messages

mailx [-s subject] address ...

The mailx utility shall read standard input and send it to one or more addresses in an unspecified manner. Unless the first character of one or more lines is tilde (∼), all characters in the input message shall appear in the delivered message, but additional characters may be inserted in the message before it is retrieved.

The mailx utility shall conform to the utility argument syntax guidelines described in 2.10.2. The following option shall be supported by the implementation:

subject

A string representing the subject of the message. All characters in the subject string shall appear in the delivered message. The results are unspecified if subject is longer than LINE_MAX − 10 bytes or contains a <newline>.

The following operand shall be supported by the implementation:

address

Send a message to address. Valid login names on the local system shall be accepted as valid addresses. The interpretation of other types of addresses is unspecified. An implementation-defined way for a user with a login-name address to retrieve the message shall be provided by the implementation.

The standard input shall be a text file. The results are unspecified if the first character of any input line is a tilde (∼).

None.

The following environment variables shall affect the execution of mailx:

This variable shall affect the processing of signals by mailx: if the application sets this variable to /dev/null, the results of receiving a signal are as described by this standard; they are otherwise unspecified.

This variable shall be interpreted as a pathname of the user’s home directory.

This variable shall determine the locale to use for the locale categories when both LC_ALL and the corresponding environment variable (beginning with LC_ ) do not specify a locale. See 2.6.

This variable shall determine the locale to be used to override any values for locale categories specified by the settings of LANG or any environment variables beginning with LC_.

This variable shall determine the locale for the interpretation of sequences of bytes of text data as characters (e.g., single- versus multibyte characters in arguments and input files).

This variable shall determine the language in which messages should be written.

This variable shall affect the startup processing of mailx: if the application sets this variable to /dev/null, mailx shall operate as described by this standard; otherwise, unspecified results occur.

Default.

None.

Used only for diagnostic messages.

None.

None.

The mailx utility shall exit with one of the following values:

Successful completion.

An error occurred.

Default.

Usage, Examples

The intent is that a header indicating who sent the message and a message subject string, the contents of the standard input, and perhaps a trailer is delivered to users specified by the given addresses. The standard input, however, may have to be manipulated slightly to avoid confusion between message text and headers as it passes through the message delivery system. POSIX. 2 does not specify how standard input may be manipulated; that will be specified in detail by POSIX. 2a. The restriction on a subject line being LINE_MAX − 10 bytes is based on the historical format that consumes 10 bytes for "Subject: " and the trailing <newline>. Many historical mailers that a message may encounter on other systems will not be able to handle lines that long, however.

The developers of the standard felt strongly that a method for applications to send messages to specific users was necessary. The obvious example is a batch utility, running noninteractively, that wishes to communicate errors or results to a user. However, the actual format, delivery mechanism, and method of reading the message are clearly beyond the scope of this standard. The intent of this command is to provide a simple, portable interface for sending messages noninteractively. It merely defines a ‘‘front-end’’ to the historical mail system. It is suggested that implementations explicitly denote the sender and recipient in the body of the delivered message. Further specification of formats for either the message envelope or the message itself were deliberately not made, as the industry is in the midst of changing from the current standards to a more internationalized standard and it is probably incorrect, at this time, to require either one. Implementations are encouraged to conform to the various delivery mechanisms described in Requests for Comment Numbers 819, 822, 882, 920, 921, and the X.400 standards. The standard does not place any restrictions on the length of messages handled by mailx, and for delivery of local messages the only limitations should be the normal problems of available disk space for the target mail file. When sending messages to external machines, applications are advised to limit messages to less than 50 kilobytes because many mail gateways impose message-length restrictions. (Note that this is usually an administrative issue based on the amount of mail traffic and disk space available on the gateways. Therefore, there is no way for this standard to require implementations to guarantee delivery of long messages to remote systems.) Like the utilities logger and lp, mailx is admittedly difficult to test. This was not deemed sufficient justification to exclude these utilities from the standard. It is also arguable that they are, in fact, testable, but that the tests themselves are not portable. Before Draft 7, there was a utility named mailto. In Draft 7, the name was changed to sendto because of comments noting that mailto implied full maillike functionality and that was not what the specification provided. However, there have been consistent comments that it does not make sense to end up with a standard that will require two mail-sending interfaces. ( POSIX. 2a is working on a fully fleshed-out mail-sending and -reading utility based on the historical System V mailx utility.) A message- (or mail-) sending utility that is a subset of the interactive utility that will be described by POSIX. 2a is much more consistent with the rest of the standard. Therefore, in Draft 10 the name has been changed again to mailx and the description is a small subset of the functionality being specified by POSIX. 2a. It provides a portable way for a shell script to be able to send a message to a user on the local system. It is expected that implementations that have provided mailx in the past will use it to meet the POSIX. 2 requirements. Implementations that have not provided mailx in the past will be able to create a simple interface to their current mailer to meet these requirements.

Most of the features provided by mailx (and the similar Mail) utility are not specified here because they are not needed for noninteractive use (applications do not usually read mail without user participation) and they depend on other interactive features that are not defined by POSIX. 2, but will be defined by POSIX. 2a (the ∼v command, for instance, uses the vi editor as a default.) If the DEAD environment variable is not set to /dev/null, historical versions of mailx and Mail save a message being constructed in a file under some circumstances when some asynchronous events occur. The details will be specified by POSIX. 2a. If the MAILRC environment variable does not name an empty file, historical versions of mailx and Mail read initialization commands from a file before processing begins. Since the initialization that a user specifies could alter the contents of messages an application is trying to send, applications are advised to set MAILRC to /dev/null. POSIX. 2a will specify details on the format of the initialization file. Options to specify addresses as ‘‘cc’’ (carbon-copy) or ‘‘bcc’’ (blind-carbon-copy) were considered to be format details and were omitted. A zero exit status implies that all messages were sent, but it gives no assurances that any of them were actually delivered. The reliability of the delivery mechanism is unspecified and is an appropriate marketing distinction between systems.

September 1991 posix.fail