NAME
mailcnfg - initialization information for mail and rmail

DESCRIPTION
The /etc/mail/mailcnfg file contains initialization information for the mail and rmail commands. Each entry in mailcnfg consists of a line of the form

    Keyword = Value

Leading whitespace, whitespace surrounding the equal sign, and trailing whitespace is ignored. Keyword may not contain embedded whitespace, but whitespace may appear within Value. Undefined keywords or badly formed entries are silently ignored.

  Keyword Definitions

DEBUG
    Takes the same values as the -x invocation option of mail. This provides a way of setting a system-wide debug/tracing level. Typically DEBUG is set to a value of 2, which provides minimal diagnostics useful for debugging mail and rmail failures. The value of the -x mail invocation option will override any specification of DEBUG in mailcnfg.

CLUSTER
    To identify a closely coupled set of systems by one name to all other systems, set Value to the cluster name. This string is used to supply the ...remote from... information on the From header line rather than the system nodename returned by uname(2).

FAILSAFE
    In the event that the /var/mail directory is accessed via RFS or NFS within a cluster (see CLUSTER above), provisions must be made to allow for the directory not being available when local mail is to be delivered (remote system crash, RFS or NFS problems, etc.). Value is a string that indicates where to forward the current message for delivery. Typically this is the remote system that actually owns /var/mail. In this way, the message is queued for delivery to that system when it becomes available. For example, assume a cluster of systems (sysa, sysb, sysc) where /var/mail is physically mounted on sysc and made available to the other machines via RFS or NFS. If sysc were to crash, the RFS/NFS-accessible /var/mail would become unavailable and local deliveries of mail would go to /var/mail on the local system. When /var/mail is re-mounted via RFS/NFS, all messages deposited in the local directory would be hidden and essentially lost. To prevent this, if FAILSAFE is defined in mailcnfg, mail and rmail check for the existence of /var/mail/:saved, a required subdirectory. If this subdirectory does not exist, mail assumes that the RFS/NFS-accessible /var/mail is not available and invokes the failsafe mechanism of automatically forwarding the message to Value. In this example Value would be sysc!%n. The %n keyword is expanded to be the recipient name [see mail(1) for details] and thus the message would be forwarded to sysc!recipient_name. Because sysc is not available, the message remains on the local system until sysc is available, and then sent there for delivery.

DEL_EMPTY_MFILE
    If not specified, the default action of mail and rmail is to delete empty mailfiles if the permissions are 0660 and to retain empty mailfiles if the permissions are anything else. If Value is yes, empty mailfiles are always deleted, regardless of file permissions. If Value is no, empty mailfiles are never deleted.

DOMAIN
    This string is used to supply the system domain name in place of the domain name returned by getdomainame(3).

SMARTERHOST
    This string may be set to a smarter host which may be referenced within the mail surrogate file via %X.

%mailsurr_keyword
    As described in mailsurr(4), certain pre-defined single letter keywords are textually substituted in surrogate command fields before they are executed. While none of the predefined keywords may be changed in meaning, new ones may be defined to provide a shorthand notation for long strings (such as /usr/lib/mail/surrcmd) which may appear repeatedly within the mailsurr file. Upper case letters are reserved for future use and will be ignored if encountered here.

FILES
/etc/mail/mailcnfg
/etc/mail/mailsurr
/var/mail/:saved
/usr/lib/mail/surrcmd

SEE ALSO
mailsurr(4)
mail(1) in the User's Reference Manual
uname(2), getdomainame(3) in the Programmer's Reference Manual

NOTES
If /var/mail is accessed via RFS or NFS and the subdirectory /var/mail/:saved is not removed from the local system, the FAILSAFE mechanism will be subverted.