The message selection criteria used by slocal is specified in the file ``.maildelivery'' in the user's home directory. You can specify an alternate file with the -maildelivery file option. The syntax of this file is specified below.
The message delivery address and message sender are determined from the Message Transfer Agent envelope information, if possible. Under sendmail, the sender will obtained from the UUCP ``From:'' line, if present. The user may override these values with command line arguments, or arguments to the -addr and -sender switches.
The message is normally read from the standard input. The -file switch sets the name of the file from which the message should be read, instead of reading stdin. This is useful when debugging a ``.maildelivery'' file.
The -user switch tells slocal the name of the user for whom it is delivering mail. The -mailbox switch tells slocal the name of the user's maildrop file.
slocal is able to detect and suppress duplicate messages. To enable this, use the option -suppressdup. slocal will keep a database containing the Message-ID's of incoming messages, in order to detect duplicates. Depending on your configuration, this database will be in either ndbm or Berkeley db format.
The -info switch may be used to pass an arbitrary argument to sub-processes which slocal may invoke on your behalf.
The -verbose switch causes slocal to give information on stdout about its progress. The -debug switch produces more verbose debugging output on stderr. These flags are useful when creating and debugging your ``.maildelivery'' file, as they allow you to see the decisions and actions that slocal is taking, as well as check for syntax errors in your ``.maildelivery'' file.
in your .forward file in your home directory. This will cause sendmail to invoke slocal on your behalf when a message arrives.
If your MTA is MMDF-I, you should (symbolically) link /usr/libexec/nmh/slocal to the file bin/rcvmail in your home directory. This will cause MMDF-I to invoke slocal on your behalf with the correct ``address info sender'' arguments.
If your MTA is MMDF-II, then you should not use slocal. An equivalent functionality is already provided by MMDF-II; see maildelivery(5) for details.
The format of each line in the ``.maildelivery'' file is:
header:
The following special fields are also defined:
pattern:
action:
result:
The delivery file is always read completely, so that several matches can be made and several actions can be taken.
If the ``.maildelivery'' file cannot be found, or does not perform an action which delivers the message, then slocal will check for a global delivery file at /etc/nmh/maildelivery. This file is read according to the same rules. This file must be owned by the root and must be writable only by the root.
If a global delivery file cannot be found or does not perform an action which delivers the message, then standard delivery to the user's maildrop is performed.
# # .maildelivery file for nmh's slocal # # Blank lines and lines beginning with a '#' are ignored # # FIELD PATTERN ACTION RESULT STRING # # File mail with foobar in the ``To:'' line into file foobar.log To foobar file A foobar.log # Pipe messages from coleman to the program message-archive From coleman pipe A /bin/message-archive # Anything to the ``nmh-workers'' mailing list is put in # its own folder, if not filed already To nmh-workers folder ? nmh-workers # Anything with Unix in the subject is put into # the file unix-mail Subject unix file A unix-mail # I don't want to read mail from Steve, so destroy it From steve destroy A - # Put anything not matched yet into mailbox default - file ? mailbox # always run rcvtty * - pipe R /usr/libexec/nmh/rcvtty
The process is given a certain amount of time to execute. If the process does not exit within this limit, the process will be terminated with extreme prejudice. The amount of time is calculated as ((size / 60) + 300) seconds, where size is the number of bytes in the message (with 30 minutes the maximum time allowed).
The exit status of the process is consulted in determining the success of the action. An exit status of zero means that the action succeeded. Any other exit status (or abnormal termination) means that the action failed.
In order to avoid any time limitations, you might implement a process that began by fork()-ing. The parent would return the appropriate value immediately, and the child could continue on, doing whatever it wanted for as long as it wanted. This approach is somewhat risky if the parent is going to return an exit status of zero. If the parent is going to return a non-zero exit status, then this approach can lead to quicker delivery into your maildrop.
^/etc/nmh/mts.conf~^nmh mts configuration file ^$HOME/.maildelivery~^The file controlling local delivery ^/etc/nmh/maildelivery~^Rather than the standard file ^/var/mail/$USER~^The default maildrop
`-noverbose' `-nosuppressdup' `-maildelivery' defaults to $HOME/.maildelivery `-mailbox' deaults to /var/mail/$USER `-file' defaults to stdin `-user' defaults to the current user
In addition to an exit status of zero, the MMDF values RP_MOK (32) and RP_OK (9) mean that the message has been fully delivered. Any other non-zero exit status, including abnormal termination, is interpreted as the MMDF value RP_MECH (200), which means ``use an alternate route'' (deliver the message to the maildrop).
Slocal was originally designed to be backwards-compatible with the maildelivery functionality provided by MMDF-II.