.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\fR, which may be tabs, spaces or commas ``,''. .sp .5 .ti .6i \fIfield\ \ \ \ pattern\ \ \ \ action\ \ \ \ A/R/\?\fR\ \ \ \ ``\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.