1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
|
<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.52
from spec on 25 November 2000 -->
<TITLE>Exim Specification - 50. Automatic mail processing</TITLE>
</HEAD>
<body bgcolor="#FFFFFF" text="#00005A" link="#FF6600" alink="#FF9933" vlink="#990000">
Go to the <A HREF="spec_1.html">first</A>, <A HREF="spec_49.html">previous</A>, <A HREF="spec_51.html">next</A>, <A HREF="spec_59.html">last</A> section, <A HREF="spec_toc.html">table of contents</A>.
<P><HR><P>
<H1><A NAME="SEC847" HREF="spec_toc.html#TOC847">50. Automatic mail processing</A></H1>
<P>
<A NAME="IDX1882"></A>
</P>
<P>
This chapter describes some of the ways in which incoming mail can be processed
automatically, either on a system-wide basis, or as specified by individual
users.
</P>
<P>
<H2><A NAME="SEC848" HREF="spec_toc.html#TOC848">50.1 System-wide automatic processing</A></H2>
<P>
Simple re-addressing of messages can be handled by <EM>aliasfile</EM> or <EM>forwardfile</EM>
directors. The particular case of mailing lists is covered in chapter
42. Other kinds of automatic processing can be handled by
suitable configurations of directors and transports. As an example, here is an
extract from the configuration of a system which tries to send back helpful
information when a message is received for an unknown user. The last director
in the configuration is:
<PRE>
unknownuser:
driver = smartuser
transport = unknownuser_pipe
no_verify
</PRE>
<P>
This collects all the addresses whose local parts haven't been matched by any
other director, and directs them to a special pipe transport, whose
configuration is:
<PRE>
unknownuser_pipe:
driver = pipe
command = /opt/exim/util/baduser.sh
ignore_status
return_output
user = nobody
</PRE>
<P>
The script is run as the user `nobody', and it can apply heuristics such as
soundex search to the local part, in an attempt to produce a list of
possible users for whom the message might have been intended. This is then
included in a message that is written to its standard output; Exim picks this
up and returns it to the sender as part of the delivery error message.
</P>
<P>
<A NAME="IDX1883"></A>
<A NAME="IDX1884"></A>
Chapter 47 describes how to arrange to run a system filter file
once per message. Sometimes there is a requirement to set up similar automatic
processing, but on a per-address basis, that is, the filter is run once for
each address. This can be done by using a director such as the following:
<PRE>
filter_per_address:
driver = forwardfile
no_verify
filter
file = /etc/per-address-filter
no_check_local_user
user = nobody
</PRE>
<P>
See the separate document entitled <EM>Exim's interface to mail filtering</EM>
which describes the available filtering commands. Care should be taken to ensure
that none of the commands in the filter file specify a significant delivery if
the message is to go on to be delivered to its intended recipient. The
director will not then claim to have dealt with the address, so it will be
passed on to subsequent directors to be delivered in the normal way. Note that
a traditional (non-filter) <TT>`.forward'</TT> file does not have this property, so
cannot be used in this way, though you could use it to forward all mail for a
particular domain to a single recipient in a different domain.
</P>
<H2><A NAME="SEC849" HREF="spec_toc.html#TOC849">50.2 Taking copies of mail</A></H2>
<P>
Some installations have policies that require archive copies of all messages to
be made. A single copy of each message can easily be taken by an appropriate
command in a system filter, which could, for example, use a different file for
each day's messages.
</P>
<P>
There is also a shadow transport mechanism that can be used to take copies of
messages that are successfully delivered by local transports, one copy per
delivery. This could be used, <EM>inter alia</EM>, to implement automatic
notification of delivery by sites that insist on doing such things.
</P>
<H2><A NAME="SEC850" HREF="spec_toc.html#TOC850">50.3 Automatic processing by users</A></H2>
<P>
Users can cause their mail to be processed automatically by creating <TT>`.forward'</TT>
files, provided that Exim's configuration contains an appropriate <EM>forwardfile</EM>
director. Traditionally, such files contain just a list of forwarding
addresses, local files, and pipe commands, but if the <EM>forwardfile</EM> director
has the <EM>filter</EM> option set, users can access Exim's filtering facilities by
beginning a <TT>`.forward'</TT> file with the text `# Exim filter'. Details of the
syntax and semantics of filter files are described in a separate document
entitled <EM>Exim's interface to mail filtering</EM>; this is intended for use
by end users.
</P>
<P>
The name <TT>`.forward'</TT> is purely conventional; a <EM>forwardfile</EM> director can be
configured to use any arbitrary name. As there are some finger daemons that
display the contents of users' <TT>`.forward'</TT> files, some sites might like to use a
different name when mail filtering is provided.
</P>
<P>
What users may do in their <TT>`.forward'</TT> files can be constrained by various
options of the <EM>forwardfile</EM> director:
</P>
<UL>
<LI>
If the <EM>filter</EM> option is not set, only traditional <TT>`.forward'</TT> files are
permitted.
<LI>
If the <EM>forbid_file</EM> option is set, neither a traditional <TT>`.forward'</TT>
file, nor a filter file may direct that a message be appended to a particular
local file. An attempt to do so causes a delivery error.
<LI>
If the <EM>forbid_filter_log</EM> option is set, the use of the <EM>log</EM> command
in a filter file is not permitted.
<LI>
If the <EM>forbid_pipe</EM> option is set, neither a traditional <TT>`.forward'</TT>
file, nor a filter file may direct that a message be piped to a user-specified
command. An attempt to do so causes a delivery error.
<LI>
If the <EM>forbid_reply</EM> option is set, a filter file may not direct that a
new mail message be created. An attempt to do so causes a delivery error.
</UL>
<P>
If piping is permitted, the pipe transport that is used (conventionally called
<EM>address_pipe</EM>) can constrain the command to be taken from a particular set of
files. Pipe commands generated from traditional <TT>`.forward'</TT> files are not
string-expanded, but when a pipe command is generated in a filter file, each
argument is separately expanded.
</P>
<P>
If delivery to specified files is permitted, the <EM>appendfile</EM> transport that is
used (conventionally called <EM>address_file</EM>) can specify that the file must
already exist, or can restrict the whereabouts of its creation by means of the
<EM>create_file</EM> option.
</P>
<H2><A NAME="SEC851" HREF="spec_toc.html#TOC851">50.4 Simplified vacation processing</A></H2>
<P>
<A NAME="IDX1885"></A>
The traditional way of running the <EM>vacation</EM> program is for a user to set up
a pipe command in a <TT>`.forward'</TT> file. This is prone to error by inexperienced
users. There are two features of Exim that can be used to make this process
simpler for users:
</P>
<UL>
<LI>
A local part prefix such as `vacation-' can be specified on a director which
causes the message to be delivered directly to the <EM>vacation</EM> program, or
uses Exim's <EM>autoreply</EM> transport. The contents of a user's <TT>`.forward'</TT> file are
then much simpler. For example:
<PRE>
spqr, vacation-spqr
</PRE>
<LI>
The <EM>require_files</EM> generic director option can be used to trigger a
vacation delivery by checking for the existence of a certain file in the
user's home directory. The <EM>unseen</EM> generic option should also be used, to
ensure that the original delivery also proceeds. In this case, all the user has
to do is to create a file called, say, <EM>.vacation</EM>, containing a vacation
message.
</UL>
<P>
Another advantage of both these methods is that they both work even when the
use of arbitrary pipes by users is locked out.
</P>
<P><HR><P>
Go to the <A HREF="spec_1.html">first</A>, <A HREF="spec_49.html">previous</A>, <A HREF="spec_51.html">next</A>, <A HREF="spec_59.html">last</A> section, <A HREF="spec_toc.html">table of contents</A>.
</BODY>
</HTML>
|
