![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to p6 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ucs / mmdf|
Return to p6 CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ucs / mmdf |
1.1 root 1: .SH
2: The Local Channel
3: .PP
4: The local channel remained unchanged until late 1983, when
5: a major reworking of the channel was done by BRL. The old
6: local channel could handle delivery in three basic ways.
7: The first and most common was to deliver directly to the
8: user's default mailbox, appending the message to the end.
9: Second, the user could put a program in his
10: private bin directory
11: called ``rcvmail'' that would be called by the local channel
12: to handle delivery of the message.
13: If the user program (rcvmail) did not complete successfully,
14: a standard delivery was made instead.
15: .PP
16: In early versions of the local channel for MMDFII, Dave Crocker added
17: support for mailing to files and pipes, but the original version
18: had a number of security problems,
19: mostly due to \fBsubmit\fR, so the capability
20: was not much used.
21: .PP
22: The latest version of the local channel has kept
23: the alias-file-originated delivery to files
24: and pipes, and the changes Steve Kille
25: has made to the \fBsubmit\fR program have also made this facility reliable
26: from a security standpoint.
27: The rcvmail mechanism has been totally scrapped in favor of a
28: more general and powerful mechanism which I will call
29: ``mail delivery files''.
30: .PP
31: Mail delivery files were designed to give the user as much flexibility
32: over how his mail was delivered as possible without opening security holes.
33: The mail system was changed to allow local addresses to have a
34: suffix appended which consists of an `=' and any simple text;
35: this suffix is totally ignored except when using mail delivery files.
36: Each user may create a ``.maildelivery'' file in his home
37: directory which contains one or more delivery specifications.
38: A delivery specification has five parts, separated by field separators,
39: \fI<FS>\fR, which may be tabs, spaces or commas ``,''.
40: .sp .5
41: .ti .6i
42: \fIfield\ \ <FS>\ \ pattern\ \ <FS>\ \ action\ \ <FS>\ \ A/R/\?\fR\ \ <FS>\ \ ``\fIoptional string\fR''
43: .sp .5
44: The \fIfield\fR is the name of a field that is to be searched for a pattern.
45: Currently supported fields are \fIFrom\fR, \fITo\fR, \fISubject\fR,
46: \fISender\R, and \fICc\fR, plus three special fields, \fIaddr\fR, \fI*\fR,
47: and \fI*\fR.
48: The \fIaddr\fR field is used to match against the address being delivered to
49: \fIincluding\fR the suffix (e.g. ``dpk=unixwizards'').
50: If the user subscribes to different lists with different suffixes
51: he can use his mail delivery file to segregate his mail by source.
52: To do this based on the message text alone is impossible to
53: do right 100% of the time.
54: The \fIdefault\fR field matches if the message has not been delivered
55: by any of the preceding lines in the ``.maildelivery'' file.
56: The \fI*\fR field always matches, regardless of any other action.
57: .PP
58: The \fIpattern\fR is some sequence of characters that may be matched
59: in the \fIfield\R. Case is not significant, and multiple fields of the same
60: name are concatenated, separated by spaces. If the field does not need as
61: pattern, a dash (-) or similar symbol is usually inserted to show that the
62: field is present but not used.
63: .PP
64: The \fIaction\fR is ``file'' or ``>'', ``pipe'' or ``|'', or ``destroy''.
65: ``File'' or ``>'' appends the message in standard mailbox format to the
66: file specified in the optional string.
67: ``Pipe'' or ``|'' causes the
68: program in the optional string to be run with the message available on
69: the standard input.
70: ``Destroy'' causes the mail to be thrown
71: away silently. This is useful if you go away on a long trip and don't
72: want to unsubscribe to lists, but also don't want to come home to
73: several thousand messages.
74: .PP
75: The \fIA/R/?\fR flag is a single character: `A' for accept, `R' for reject,
76: or `?' for accept if not delivered yet. This flag indicates whether the action,
77: if successful, is sufficient to mark the message as delivered.
78: If the message is undelivered at the end of the .maildelivery file,
79: the local channel next consults a system-wide file, such as
80: \fI/usr/lib/maildevliery\fR. If the message is still undelivered at the end of
81: the system-wide file, a standard delivery is made to the default mailbox.
82: This protects against
83: mail being lost due to lack of foresight or errors in the maildelivery files.
84: .PP
85: The file is always read completely so that several matches
86: can be made, and several actions taken.
87: For example, the user could have a TTY alert
88: message sent to his terminal and also have the message resent to his new
89: home machine by the following .maildelivery file:
90: .sp .5
91: .in +.6i
92: addr\ \ \ \ dpk\ \ \ \ pipe\ \ \ R\ \ ``/usr/mmdf/mailutils/ttyalert''
93: .br
94: addr\ \ \ \ dpk\ \ \ \ pipe\ \ \ A\ \ ``/usr/brl/bin/resend [email protected]''
95: .in -.6i
96: .sp .5
97: The last line, if completed without error (a return code of 0 from resend),
98: would mark the message as delivered because of the A (accept) flag in the
99: fourthcolumn.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.