home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / mmdf / mmdf-IIb.43 / doc / review / p6 < prev    next >
Encoding:
Text File  |  1988-06-02  |  4.7 KB  |  100 lines
  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\fR, 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\fR.  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/maildelivery\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 dpk@brl-vgr.arpa''
  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.
  100.