.SH
The Local Channel
.PP
The local channel remained unchanged until late 1983, when
a major reworking of the channel was done by BRL.  The old
local channel could handle delivery in three basic ways.
The first and most common was to deliver directly to the
user's default mailbox, appending the message to the end.
Second, the user could put a program in his
private bin directory
called ``rcvmail'' that would be called by the local channel
to handle delivery of the message.
If the user program (rcvmail) did not complete successfully,
a standard delivery was made instead.
.PP
In early versions of the local channel for MMDFII, Dave Crocker added
support for mailing to files and pipes, but the original version
had a number of security problems,
mostly due to \fBsubmit\fR, so the capability
was not much used.
.PP
The latest version of the local channel has kept
the alias-file-originated delivery to files
and pipes, and the changes Steve Kille
has made to the \fBsubmit\fR program have also made this facility reliable
from a security standpoint.
The rcvmail mechanism has been totally scrapped in favor of a
more general and powerful mechanism which I will call
``mail delivery files''.
.PP
Mail delivery files were designed to give the user as much flexibility
over how his mail was delivered as possible without opening security holes.
The mail system was changed to allow local addresses to have a
suffix appended which consists of an `=' and any simple text;
this suffix is totally ignored except when using mail delivery files.
Each user may create a ``.maildelivery'' file in his home
directory which contains one or more delivery specifications.
A delivery specification has five parts, separated by field separators, 
\fI<FS>\fR, which may be tabs, spaces or commas ``,''.
.sp .5
.ti .6i
\fIfield\ \ <FS>\ \ pattern\ \ <FS>\ \ action\ \ <FS>\ \ A/R/\?\fR\ \ <FS>\ \ ``\fIoptional string\fR''
.sp .5
The \fIfield\fR is the name of a field that is to be searched for a pattern.
Currently supported fields are \fIFrom\fR, \fITo\fR, \fISubject\fR, 
\fISender\R, and \fICc\fR, plus three special fields, \fIaddr\fR, \fI*\fR,
and \fI*\fR.
The \fIaddr\fR field is used to match against the address being delivered to
\fIincluding\fR the suffix (e.g. ``dpk=unixwizards'').
If the user subscribes to different lists with different suffixes
he can use his mail delivery file to segregate his mail by source.
To do this based on the message text alone is impossible to
do right 100% of the time.
The \fIdefault\fR field matches if the message has not been delivered
by any of the preceding lines in the ``.maildelivery'' file.
The \fI*\fR field always matches, regardless of any other action.
.PP
The \fIpattern\fR is some sequence of characters that may be matched
in the \fIfield\R.  Case is not significant, and multiple fields of the same
name are concatenated, separated by spaces.  If the field does not need as
pattern, a dash (-) or similar symbol is usually inserted to show that the
field is present but not used.
.PP
The \fIaction\fR is ``file'' or ``>'', ``pipe'' or ``|'', or ``destroy''.
``File'' or ``>'' appends the message in standard mailbox format to the
file specified in the optional string.
``Pipe'' or ``|''  causes the
program in the optional string to be run with the message available on
the standard input.
``Destroy'' causes the mail to be thrown
away silently.  This is useful if you go away on a long trip and don't
want to unsubscribe to lists, but also don't want to come home to
several thousand messages.
.PP
The \fIA/R/?\fR flag is a single character: `A' for accept, `R' for reject,
or `?' for accept if not delivered yet.  This flag indicates whether the action,
if successful, is sufficient to mark the message as delivered.
If the message is undelivered at the end of the .maildelivery file,
the local channel next consults a system-wide file, such as
\fI/usr/lib/maildevliery\fR.  If the message is still undelivered at the end of
the system-wide file, a standard delivery is made to the default mailbox.  
This protects against
mail being lost due to lack of foresight or errors in the maildelivery files.
.PP
The file is always read completely so that several matches
can be made, and several actions taken.
For example, the user could have a TTY alert
message sent to his terminal and also have the message resent to his new
home machine by the following .maildelivery file:
.sp .5
.in +.6i
addr\ \ \ \ dpk\ \ \ \ pipe\ \ \ R\ \ ``/usr/mmdf/mailutils/ttyalert''
.br
addr\ \ \ \ dpk\ \ \ \ pipe\ \ \ A\ \ ``/usr/brl/bin/resend dpk@brl-vgr.arpa''
.in -.6i
.sp .5
The last line, if completed without error (a return code of 0 from resend),
would mark the message as delivered because of the A (accept) flag in the
fourthcolumn.
