Commit | Line | Data |
---|---|---|
8857ccfd | 1 | $Cambridge: exim/doc/doc-txt/NewStuff,v 1.76 2005/10/03 13:25:32 ph10 Exp $ |
495ae4b0 PH |
2 | |
3 | New Features in Exim | |
4 | -------------------- | |
5 | ||
6 | This file contains descriptions of new features that have been added to Exim, | |
7 | but have not yet made it into the main manual (which is most conveniently | |
8 | updated when there is a relatively large batch of changes). The doc/ChangeLog | |
9 | file contains a listing of all changes, including bug fixes. | |
10 | ||
8857ccfd PH |
11 | Exim version 4.54 |
12 | ----------------- | |
13 | ||
14 | There was a problem with 4.52/TF/02 in that a "name=" option on control= | |
15 | submission terminated at the next slash, thereby not allowing for slashes in | |
16 | the name. This has been changed so that "name=" takes the rest of the string as | |
17 | its data. It must therefore be the last option. | |
18 | ||
19 | ||
20 | ||
e3a311ba TK |
21 | Exim version 4.53 |
22 | ----------------- | |
23 | ||
24 | TK/01 Added the "success_on_redirect" address verification option. When an | |
25 | address generates new addresses during routing, Exim will abort | |
26 | verification with "success" when more than one address has been | |
27 | generated, but continue to verify a single new address. The latter | |
28 | does not happen when the new "success_on_redirect" option is set, like | |
29 | ||
30 | require verify = recipient/success_on_redirect/callout=10s | |
31 | ||
32 | In that case, verification will succeed when a router generates a new | |
33 | address. | |
34 | ||
13b685f9 PH |
35 | PH/01 Support for SQLite database lookups has been added. This is another |
36 | query-style lookup, but it is slightly different from the others because | |
37 | a file name is required in addition to the SQL query. This is because an | |
38 | SQLite database is a single file and there is no daemon as in other SQL | |
39 | databases. The interface to Exim requires the name of the file, as an | |
40 | absolute path, to be given at the start of the query. It is separated | |
41 | from the query by white space. This means that the path name cannot | |
42 | contain white space. Here is a lookup expansion example: | |
43 | ||
44 | ${lookup sqlite {/some/thing/sqlitedb \ | |
45 | select name from aliases where id='ph10';}} | |
46 | ||
47 | In a list, the syntax is similar. For example: | |
48 | ||
49 | domainlist relay_domains = sqlite;/some/thing/sqlitedb \ | |
50 | select * from relays where ip='$sender_host_address'; | |
51 | ||
52 | The only character affected by the ${quote_sqlite: operator is a single | |
53 | quote, which it doubles. | |
54 | ||
31480e42 PH |
55 | The SQLite library handles multiple simultaneous accesses to the database |
56 | internally. Multiple readers are permitted, but only one process can | |
57 | update at once. Attempts to access the database while it is being updated | |
58 | are rejected after a timeout period, during which the SQLite library | |
59 | waits for the lock to be released. In Exim, the default timeout is set | |
60 | to 5 seconds, but it can be changed by means of the sqlite_lock_timeout | |
61 | option. | |
62 | ||
13b685f9 PH |
63 | Note that you must set LOOKUP_SQLITE=yes in Local/Makefile in order to |
64 | obtain SQLite support, and you will also need to add -lsqlite3 to the | |
65 | EXTRALIBS setting. And of course, you have to install SQLite on your | |
66 | host first. | |
67 | ||
1ab52c69 PH |
68 | PH/02 The variable $message_id is now deprecated, to be replaced by |
69 | $message_exim_id, which makes it clearer which ID is being referenced. | |
70 | ||
254e032f PH |
71 | PH/03 The use of forbid_filter_existstest now also locks out the use of the |
72 | ${stat: expansion item. | |
73 | ||
f1513293 PH |
74 | PH/04 The IGNOREQUOTA extension to the LMTP protocol is now available in both |
75 | the lmtp transport and the smtp transport running in LMTP mode. In the | |
76 | lmtp transport there is a new Boolean option called ignore_quota, and in | |
77 | the smtp transport there is a new Boolean option called | |
78 | lmtp_ignore_quota. If either of these options is set TRUE, the string | |
79 | "IGNOREQUOTA" is added to RCPT commands when using the LMTP protocol, | |
80 | provided that the server has advertised support for IGNOREQUOTA in its | |
81 | response to the LHLO command. | |
82 | ||
d7b47fd0 PH |
83 | PH/05 Previously, if "verify = helo" was set in an ACL, the condition was true |
84 | only if the host matched helo_try_verify_hosts, which caused the | |
85 | verification to occur when the EHLO/HELO command was issued. The ACL just | |
86 | tested the remembered result. Now, if a previous verification attempt has | |
87 | not happened, "verify = helo" does it there and then. | |
88 | ||
7cd1141b PH |
89 | PH/06 It is now possible to specify a port number along with a host name or |
90 | IP address in the list of hosts defined in the manualroute or | |
91 | queryprogram routers, fallback_hosts, or the "hosts" option of the smtp | |
92 | transport. These all override any port specification on the transport. | |
93 | The relatively standard syntax of using a colon separator has been | |
94 | adopted, but there are some gotchas that need attention: | |
95 | ||
96 | * In all these lists of hosts, colon is the default separator, so either | |
97 | the colon that specifies a port must be doubled, or the separator must | |
98 | be changed. The following two examples have the same effect: | |
99 | ||
100 | fallback_hosts = host1.tld::1225 : host2.tld::1226 | |
101 | fallback_hosts = <; host1.tld:1225 ; host2.tld:1226 | |
102 | ||
103 | * When IPv6 addresses are involved, it gets worse, because they contain | |
104 | colons of their own. To make this case easier, it is permitted to | |
105 | enclose an IP address (either v4 or v6) in square brackets if a port | |
106 | number follows. Here's an example from a manualroute router: | |
107 | ||
108 | route_list = * "</ [10.1.1.1]:1225 / [::1]:1226" | |
109 | ||
110 | If the "/MX" feature is to be used as well as a port specifier, the port | |
111 | must come last. For example: | |
112 | ||
113 | route_list = * dom1.tld/mx::1225 | |
114 | ||
64ffc24f PH |
115 | PH/07 $smtp_command_argument is now set for all SMTP commands, not just the |
116 | non-message ones. This makes it possible to inspect the complete command | |
3ee512ff | 117 | for RCPT commands, for example. But see also PH/45 below. |
64ffc24f | 118 | |
f9a68dd3 PH |
119 | PH/08 The ${eval expansion now supports % as a "remainder" operator. |
120 | ||
1c41c9cc PH |
121 | PH/09 There is a new ACL condition "verify = not_blind". It checks that there |
122 | are no blind (bcc) recipients in the message. Every envelope recipient | |
123 | must appear either in a To: header line or in a Cc: header line for this | |
124 | condition to be true. Local parts are checked case-sensitively; domains | |
125 | are checked case-insensitively. If Resent-To: or Resent-Cc: header lines | |
126 | exist, they are also checked. This condition can be used only in a DATA | |
127 | or non-SMTP ACL. | |
128 | ||
129 | There are, of course, many legitimate messages that make use of blind | |
130 | (bcc) recipients. This check should not be used on its own for blocking | |
131 | messages. | |
132 | ||
8800895a PH |
133 | PH/10 There is a new ACL control called "suppress_local_fixups". This applies |
134 | to locally submitted (non TCP/IP) messages, and is the complement of | |
135 | "control = submission". It disables the fixups that are normally applied | |
136 | to locally-submitted messages. Specifically: | |
137 | ||
138 | (a) Any Sender: header line is left alone (in this respect, it's a | |
139 | dynamic version of local_sender_retain). | |
140 | ||
141 | (b) No Message-ID:, From:, or Date: headers are added. | |
142 | ||
143 | (c) There is no check that From: corresponds to the actual sender. | |
144 | ||
145 | This feature may be useful when a remotely-originated message is | |
146 | accepted, passed to some scanning program, and then re-submitted for | |
147 | delivery. It means that all four possibilities can now be specified: | |
148 | ||
149 | (1) Locally submitted, fixups applies: the default. | |
150 | (2) Locally submitted, no fixups applied: use control = | |
151 | suppress_local_fixups. | |
152 | (3) Remotely submitted, no fixups applied: the default. | |
153 | (4) Remotely submitted, fixups applied: use control = submission. | |
154 | ||
1130bfb0 PH |
155 | PH/11 There is a new log selector, "unknown_in_list", which provokes a log |
156 | entry when the result of a list match is failure because a DNS lookup | |
157 | failed. | |
158 | ||
3ee512ff PH |
159 | PH/12 There is a new variable called $smtp_command which contains the full SMTP |
160 | command (compare $smtp_command_argument - see PH/07 above). This makes it | |
161 | possible to distinguish between HELO and EHLO, and also between things | |
162 | like "MAIL FROM:<>" and "MAIL FROM: <>". | |
163 | ||
7546de58 TF |
164 | TF/01 There's a new script in util/ratelimit.pl which extracts sending |
165 | rates from log files, to assist with choosing appropriate settings | |
166 | when deploying the ratelimit ACL condition. | |
167 | ||
6af56900 PH |
168 | PH/13 A new letter, "H", is available in retry parameter sets. It is similar |
169 | to "G" (geometric increasing time intervals), except that the interval | |
170 | before the next retry is randomized. Each time, the previous interval is | |
171 | multiplied by the factor in order to get a maximum for the next interval. | |
172 | The mininum interval is the first argument of the parameter, and an | |
173 | actual interval is chosen randomly between them. Such a rule has been | |
174 | found to be helpful in cluster configurations when all the members of the | |
175 | cluster restart at once, and may synchronize their queue processing | |
176 | times. | |
177 | ||
0925ede6 PH |
178 | PH/14 The options never_users, trusted_users, admin_groups, and trusted_groups |
179 | are now expanded when the configuration file is read. | |
180 | ||
495ae4b0 | 181 | |
e5a9dba6 PH |
182 | Exim version 4.52 |
183 | ----------------- | |
184 | ||
185 | TF/01 Support for checking Client SMTP Authorization has been added. CSA is a | |
186 | system which allows a site to advertise which machines are and are not | |
187 | permitted to send email. This is done by placing special SRV records in | |
188 | the DNS, which are looked up using the client's HELO domain. At this | |
189 | time CSA is still an Internet-Draft. | |
190 | ||
191 | Client SMTP Authorization checks are performed by the ACL condition | |
192 | verify=csa. This will fail if the client is not authorized. If there is | |
193 | a DNS problem, or if no valid CSA SRV record is found, or if the client | |
194 | is authorized, the condition succeeds. These three cases can be | |
195 | distinguished using the expansion variable $csa_status, which can take | |
196 | one of the values "fail", "defer", "unknown", or "ok". The condition | |
197 | does not itself defer because that would be likely to cause problems | |
198 | for legitimate email. | |
199 | ||
200 | The error messages produced by the CSA code include slightly more | |
201 | detail. If $csa_status is "defer" this may be because of problems | |
202 | looking up the CSA SRV record, or problems looking up the CSA target | |
203 | address record. There are four reasons for $csa_status being "fail": | |
204 | the client's host name is explicitly not authorized; the client's IP | |
205 | address does not match any of the CSA target IP addresses; the client's | |
206 | host name is authorized but it has no valid target IP addresses (e.g. | |
207 | the target's addresses are IPv6 and the client is using IPv4); or the | |
208 | client's host name has no CSA SRV record but a parent domain has | |
209 | asserted that all subdomains must be explicitly authorized. | |
210 | ||
211 | The verify=csa condition can take an argument which is the domain to | |
212 | use for the DNS query. The default is verify=csa/$sender_helo_name. | |
213 | ||
214 | This implementation includes an extension to CSA. If the query domain | |
215 | is an address literal such as [192.0.2.95], or if it is a bare IP | |
216 | address, Exim will search for CSA SRV records in the reverse DNS as if | |
217 | the HELO domain was e.g. 95.2.0.192.in-addr.arpa. Therefore it is | |
218 | meaningful to say, for example, verify=csa/$sender_host_address - in | |
219 | fact, this is the check that Exim performs if the client does not say | |
220 | HELO. This extension can be turned off by setting the main | |
221 | configuration option dns_csa_use_reverse = false. | |
222 | ||
223 | If a CSA SRV record is not found for the domain itself, then a search | |
224 | is performed through its parent domains for a record which might be | |
225 | making assertions about subdomains. The maximum depth of this search is | |
226 | limited using the main configuration option dns_csa_search_limit, which | |
227 | takes the value 5 by default. Exim does not look for CSA SRV records in | |
228 | a top level domain, so the default settings handle HELO domains as long | |
229 | as seven (hostname.five.four.three.two.one.com) which encompasses the | |
230 | vast majority of legitimate HELO domains. | |
231 | ||
232 | The dnsdb lookup also has support for CSA. Although dnsdb already | |
233 | supports SRV lookups, this is not sufficient because of the extra | |
234 | parent domain search behaviour of CSA, and (as with PTR lookups) | |
235 | dnsdb also turns IP addresses into lookups in the reverse DNS space. | |
236 | The result of ${lookup dnsdb {csa=$sender_helo_name} } has two | |
237 | space-separated fields: an authorization code and a target host name. | |
238 | The authorization code can be "Y" for yes, "N" for no, "X" for explicit | |
239 | authorization required but absent, or "?" for unknown. | |
240 | ||
c1ac6996 PH |
241 | PH/01 The amount of output produced by the "make" process has been reduced, |
242 | because the compile lines are often rather long, making it all pretty | |
243 | unreadable. The new style is along the lines of the 2.6 Linux kernel: | |
244 | just a short line for each module that is being compiled or linked. | |
245 | However, it is still possible to get the full output, by calling "make" | |
246 | like this: | |
247 | ||
248 | FULLECHO='' make -e | |
249 | ||
250 | The value of FULLECHO defaults to "@", the flag character that suppresses | |
251 | command reflection in "make". When you ask for the full output, it is | |
252 | given in addition to the the short output. | |
253 | ||
4df1e33e | 254 | TF/02 There have been two changes concerned with submission mode: |
87ba3f5f | 255 | |
4df1e33e TF |
256 | Until now submission mode always left the return path alone, whereas |
257 | locally-submitted messages from untrusted users have the return path | |
258 | fixed to the user's email address. Submission mode now fixes the return | |
259 | path to the same address as is used to create the Sender: header. If | |
260 | /sender_retain is specified then both the Sender: header and the return | |
261 | path are left alone. | |
87ba3f5f | 262 | |
4df1e33e TF |
263 | Note that the changes caused by submission mode take effect after the |
264 | predata ACL. This means that any sender checks performed before the | |
265 | fix-ups will use the untrusted sender address specified by the user, not | |
266 | the trusted sender address specified by submission mode. Although this | |
267 | might be slightly unexpected, it does mean that you can configure ACL | |
268 | checks to spot that a user is trying to spoof another's address, for | |
269 | example. | |
87ba3f5f | 270 | |
4df1e33e TF |
271 | There is also a new /name= option for submission mode which allows you |
272 | to specify the user's full name to be included in the Sender: header. | |
273 | For example: | |
274 | ||
275 | accept authenticated = * | |
276 | control = submission/name=${lookup {$authenticated_id} \ | |
277 | lsearch {/etc/exim/namelist} } | |
278 | ||
279 | The namelist file contains entries like | |
280 | ||
281 | fanf: Tony Finch | |
282 | ||
283 | And the resulting Sender: header looks like | |
284 | ||
285 | Sender: Tony Finch <fanf@exim.org> | |
286 | ||
287 | TF/03 The control = fakereject ACL modifier now has a fakedefer counterpart, | |
29aba418 TF |
288 | which works in exactly the same way except it causes a fake SMTP 450 |
289 | response after the message data instead of a fake SMTP 550 response. | |
290 | You must take care when using fakedefer because it will cause messages | |
291 | to be duplicated when the sender retries. Therefore you should not use | |
292 | fakedefer if the message will be delivered normally. | |
293 | ||
870f6ba8 TF |
294 | TF/04 There is a new ratelimit ACL condition which can be used to measure |
295 | and control the rate at which clients can send email. This is more | |
296 | powerful than the existing smtp_ratelimit_* options, because those | |
297 | options only control the rate of commands in a single SMTP session, | |
298 | whereas the new ratelimit condition works across all connections | |
299 | (concurrent and sequential) to the same host. | |
300 | ||
301 | The syntax of the ratelimit condition is: | |
302 | ||
303 | ratelimit = <m> / <p> / <options> / <key> | |
304 | ||
3348576f TF |
305 | If the average client sending rate is less than m messages per time |
306 | period p then the condition is false, otherwise it is true. | |
870f6ba8 TF |
307 | |
308 | The parameter p is the smoothing time constant, in the form of an Exim | |
309 | time interval e.g. 8h for eight hours. A larger time constant means it | |
310 | takes Exim longer to forget a client's past behaviour. The parameter m is | |
311 | the maximum number of messages that a client can send in a fast burst. By | |
312 | increasing both m and p but keeping m/p constant, you can allow a client | |
313 | to send more messages in a burst without changing its overall sending | |
314 | rate limit. Conversely, if m and p are both small then messages must be | |
315 | sent at an even rate. | |
316 | ||
5a83e4d8 | 317 | The key is used to look up the data used to calculate the client's |
870f6ba8 TF |
318 | average sending rate. This data is stored in a database maintained by |
319 | Exim in its spool directory alongside the retry database etc. For | |
320 | example, you can limit the sending rate of each authenticated user, | |
321 | independent of the computer they are sending from, by setting the key | |
322 | to $authenticated_id. The default key is $sender_host_address. | |
dceb978c TF |
323 | Internally, Exim includes the smoothing constant p and the options in |
324 | the lookup key because they alter the meaning of the stored data. | |
325 | This is not true for the limit m, so you can alter the configured | |
326 | maximum rate and Exim will still remember clients' past behaviour, | |
327 | but if you alter the other ratelimit parameters Exim will effectively | |
328 | forget their past behaviour. | |
870f6ba8 TF |
329 | |
330 | Each ratelimit condition can have up to two options. The first option | |
331 | specifies what Exim measures the rate of, and the second specifies how | |
5a83e4d8 TF |
332 | Exim handles excessively fast clients. The options are separated by a |
333 | slash, like the other parameters. | |
870f6ba8 TF |
334 | |
335 | The per_mail option means that it measures the client's rate of sending | |
336 | messages. This is the default if none of the per_* options is specified. | |
337 | ||
338 | The per_conn option means that it measures the client's connection rate. | |
339 | ||
340 | The per_byte option limits the sender's email bandwidth. Note that it | |
341 | is best to use this option in the DATA ACL; if it is used in an earlier | |
342 | ACL it relies on the SIZE parameter on the MAIL command, which may be | |
343 | inaccurate or completely missing. You can follow the limit m in the | |
344 | configuration with K, M, or G to specify limits in kilobytes, | |
345 | megabytes, or gigabytes respectively. | |
346 | ||
347 | The per_cmd option means that Exim recomputes the rate every time the | |
348 | condition is processed, which can be used to limit the SMTP command rate. | |
349 | The alias per_rcpt is provided for use in the RCPT ACL instead of per_cmd | |
350 | to make it clear that the effect is to limit the rate at which recipients | |
351 | are accepted. Note that in this case the rate limiting engine will see a | |
352 | message with many recipients as a large high-speed burst. | |
353 | ||
354 | If a client's average rate is greater than the maximum, the rate | |
355 | limiting engine can react in two possible ways, depending on the | |
356 | presence of the strict or leaky options. This is independent of the | |
357 | other counter-measures (e.g. rejecting the message) that may be | |
358 | specified by the rest of the ACL. The default mode is leaky, which | |
359 | avoids a sender's over-aggressive retry rate preventing it from getting | |
360 | any email through. | |
361 | ||
362 | The strict option means that the client's recorded rate is always | |
363 | updated. The effect of this is that Exim measures the client's average | |
364 | rate of attempts to send email, which can be much higher than the | |
365 | maximum. If the client is over the limit it will be subjected to | |
9ec05e5e TF |
366 | counter-measures until it slows down below the maximum rate. The |
367 | smoothing period determines the time it takes for a high sending rate | |
368 | to decay exponentially to 37% of its peak value, which means that you | |
369 | can work out the time (the number of smoothing periods) that a client | |
370 | is subjected to counter-measures after an over-limit burst with the | |
371 | formula ln(peakrate/maxrate). | |
870f6ba8 TF |
372 | |
373 | The leaky option means that the client's recorded rate is not updated | |
374 | if it is above the limit. The effect of this is that Exim measures the | |
375 | client's average rate of successfully sent email, which cannot be | |
376 | greater than the maximum. If the client is over the limit it will | |
377 | suffer some counter-measures, but it will still be able to send email | |
378 | at the configured maximum rate, whatever the rate of its attempts. | |
379 | ||
380 | As a side-effect, the ratelimit condition will set the expansion | |
381 | variables $sender_rate containing the client's computed rate, | |
382 | $sender_rate_limit containing the configured value of m, and | |
383 | $sender_rate_period containing the configured value of p. | |
384 | ||
385 | Exim's other ACL facilities are used to define what counter-measures | |
386 | are taken when the rate limit is exceeded. This might be anything from | |
387 | logging a warning (e.g. while measuring existing sending rates in order | |
388 | to define our policy), through time delays to slow down fast senders, | |
389 | up to rejecting the message. For example, | |
390 | ||
391 | # Log all senders' rates | |
392 | warn | |
393 | ratelimit = 0 / 1h / strict | |
b024d9c8 | 394 | log_message = Sender rate $sender_rate / $sender_rate_period |
870f6ba8 TF |
395 | |
396 | # Slow down fast senders | |
397 | warn | |
398 | ratelimit = 100 / 1h / per_rcpt / strict | |
b024d9c8 | 399 | delay = ${eval: $sender_rate - $sender_rate_limit }s |
870f6ba8 TF |
400 | |
401 | # Keep authenticated users under control | |
402 | deny | |
403 | ratelimit = 100 / 1d / strict / $authenticated_id | |
404 | ||
405 | # System-wide rate limit | |
406 | defer | |
407 | message = Sorry, too busy. Try again later. | |
408 | ratelimit = 10 / 1s / $primary_hostname | |
409 | ||
410 | # Restrict incoming rate from each host, with a default rate limit | |
411 | # set using a macro and special cases looked up in a table. | |
412 | defer | |
b024d9c8 TF |
413 | message = Sender rate exceeds $sender_rate_limit \ |
414 | messages per $sender_rate_period | |
870f6ba8 TF |
415 | ratelimit = ${lookup {$sender_host_address} \ |
416 | cdb {DB/ratelimits.cdb} \ | |
417 | {$value} {RATELIMIT} } | |
418 | ||
894a6bd8 TF |
419 | Warning: if you have a busy server with a lot of ratelimit tests, |
420 | especially with the per_rcpt option, you may suffer from a performance | |
421 | bottleneck caused by locking on the ratelimit hints database. Apart from | |
422 | making your ACLs less complicated, you can reduce the problem by using a | |
423 | RAM disk for Exim's hints directory, /var/spool/exim/db/. However this | |
424 | means that Exim will lose its hints data after a reboot (including retry | |
425 | hints, the callout cache, and ratelimit data). | |
426 | ||
7d50add3 TK |
427 | TK/01 Added an 'spf' lookup type that will return an SPF result for a given |
428 | email address (the key) and an IP address (the database): | |
429 | ||
430 | ${lookup {tom@duncanthrax.net} spf{217.115.139.137}} | |
431 | ||
432 | The lookup will return the same result strings as they can appear in | |
433 | $spf_result (pass,fail,softfail,neutral,none,err_perm,err_temp). The | |
434 | lookup is armored in EXPERIMENTAL_SPF. Currently, only IPv4 addresses | |
435 | are supported. | |
436 | ||
437 | Patch submitted by Chris Webb <chris@arachsys.com>. | |
438 | ||
2a4be8f9 PH |
439 | PH/02 There's a new verify callout option, "fullpostmaster", which first acts |
440 | as "postmaster" and checks the recipient <postmaster@domain>. If that | |
441 | fails, it tries just <postmaster>, without a domain, in accordance with | |
442 | the specification in RFC 2821. | |
443 | ||
ef213c3b PH |
444 | PH/03 The action of the auto_thaw option has been changed. It no longer applies |
445 | to frozen bounce messages. | |
446 | ||
0cd68797 TK |
447 | TK/02 There are two new expansion items to help with the implementation of |
448 | the BATV "prvs" scheme in an Exim configuration: | |
449 | ||
450 | ||
451 | ${prvs {<ADDRESS>}{<KEY>}{[KEYNUM]}} | |
452 | ||
453 | The "prvs" expansion item takes three arguments: A qualified RFC2821 | |
454 | email address, a key and an (optional) key number. All arguments are | |
455 | expanded before being used, so it is easily possible to lookup a key | |
456 | and key number using the address as the lookup key. The key number is | |
457 | optional and defaults to "0". The item will expand to a "prvs"-signed | |
458 | email address, to be typically used with the "return_path" option on | |
459 | a smtp transport. The decision if BATV should be used with a given | |
460 | sender/recipient pair should be done on router level, to avoid having | |
461 | to set "max_rcpt = 1" on the transport. | |
462 | ||
463 | ||
464 | ${prvscheck {<ADDRESS>}{<SECRET>}{<RETURN_STRING>}} | |
465 | ||
466 | The "prvscheck" expansion item takes three arguments. Argument 1 is | |
467 | expanded first. When the expansion does not yield a SYNTACTICALLY | |
468 | valid "prvs"-scheme address, the whole "prvscheck" item expands to | |
469 | the empty string. If <ADDRESS> is a "prvs"-encoded address after | |
470 | expansion, two expansion variables are set up: | |
471 | ||
472 | $prvscheck_address Contains the "prvs"-decoded version of | |
473 | the address from argument 1. | |
474 | ||
475 | $prvscheck_keynum Contains the key number extracted from | |
476 | the "prvs"-address in argument 1. | |
477 | ||
478 | These two variables can be used in the expansion code of argument 2 | |
479 | to retrieve the <SECRET>. The VALIDITY of the "prvs"-signed address | |
480 | is then checked. The result is stored in yet another expansion | |
481 | variable: | |
482 | ||
483 | $prvscheck_result Contains the result of a "prvscheck" | |
484 | expansion: Unset (the empty string) for | |
485 | failure, "1" for success. | |
486 | ||
487 | The "prvscheck" expansion expands to the empty string if <ADDRESS> | |
488 | is not a SYNTACTICALLY valid "prvs"-scheme address. Otherwise, | |
489 | argument 3 defines what "prvscheck" expands to: If argument 3 | |
490 | is the empty string, "prvscheck" expands to the decoded version | |
491 | of the address (no matter if it is CRYPTOGRAPHICALLY valid or not). | |
492 | If argument 3 expands to a non-empty string, "prvscheck" expands | |
493 | to that string. | |
494 | ||
495 | ||
496 | Usage example | |
497 | ------------- | |
498 | ||
499 | Macro: | |
500 | ||
501 | PRVSCHECK_SQL = ${lookup mysql{SELECT secret FROM batv_prvs WHERE \ | |
502 | sender='${quote_mysql:$prvscheck_address}'}{$value}} | |
503 | ||
504 | RCPT ACL: | |
505 | ||
506 | # Bounces: drop unsigned addresses for BATV senders | |
507 | deny message = This address does not send an unsigned reverse path. | |
508 | senders = : | |
509 | recipients = +batv_recipients | |
510 | ||
511 | # Bounces: In case of prvs-signed address, check signature. | |
512 | deny message = Invalid reverse path signature. | |
513 | senders = : | |
514 | condition = ${prvscheck {$local_part@$domain}{PRVSCHECK_SQL}{1}} | |
515 | !condition = $prvscheck_result | |
516 | ||
517 | Top-Level Router: | |
518 | ||
519 | batv_redirect: | |
520 | driver = redirect | |
521 | data = ${prvscheck {$local_part@$domain}{PRVSCHECK_SQL}{}} | |
522 | ||
523 | Transport (referenced by router that makes decision if | |
524 | BATV is applicable): | |
525 | ||
526 | external_smtp_batv: | |
527 | driver = smtp | |
528 | return_path = ${prvs {$return_path} \ | |
529 | {${lookup mysql{SELECT \ | |
530 | secret FROM batv_prvs WHERE \ | |
531 | sender='${quote_mysql:$sender_address}'} \ | |
532 | {$value}fail}}} | |
533 | ||
4aee0225 PH |
534 | PH/04 There are two new options that control the retrying done by the daemon |
535 | at startup when it cannot immediately bind a socket (typically because | |
536 | the socket is already in use). The default values reproduce what were | |
537 | built-in constants previously: daemon_startup_retries defines the number | |
538 | of retries after the first failure (default 9); daemon_startup_sleep | |
539 | defines the length of time to wait between retries (default 30s). | |
0cd68797 | 540 | |
32d668a5 PH |
541 | PH/05 There is now a new ${if condition called "match_ip". It is similar to |
542 | match_domain, etc. It must be followed by two argument strings. The first | |
543 | (after expansion) must be an IP address or an empty string. The second | |
544 | (after expansion) is a restricted host list that can match only an IP | |
545 | address, not a host name. For example: | |
546 | ||
547 | ${if match_ip{$sender_host_address}{1.2.3.4:5.6.7.8}{...}{...}} | |
548 | ||
549 | The specific types of host list item that are permitted in the list are | |
550 | shown below. Consult the manual section on host lists for further | |
551 | details. | |
552 | ||
553 | . An IP address, optionally with a CIDR mask. | |
554 | ||
555 | . A single asterisk matches any IP address. | |
556 | ||
557 | . An empty item matches only if the IP address is empty. This could be | |
558 | useful for testing for a locally submitted message or one from specific | |
559 | hosts in a single test such as | |
560 | ||
561 | ${if match_ip{$sender_host_address}{:4.3.2.1:...}{...}{...}} | |
562 | ||
563 | where the first item in the list is the empty string. | |
564 | ||
565 | . The item @[] matches any of the local host's interface addresses. | |
566 | ||
567 | . Lookups are assumed to be "net-" style lookups, even if "net-" is not | |
568 | specified. Thus, the following are equivalent: | |
569 | ||
570 | ${if match_ip{$sender_host_address}{lsearch;/some/file}... | |
571 | ${if match_ip{$sender_host_address}{net-lsearch;/some/file}... | |
572 | ||
573 | You do need to specify the "net-" prefix if you want to specify a | |
574 | specific address mask, for example, by using "net24-". | |
575 | ||
056eb8b5 PH |
576 | PH/06 The "+all" debug selector used to set the flags for all possible output; |
577 | it is something that people tend to use semi-automatically when | |
578 | generating debug output for me or for the list. However, by including | |
579 | "+memory", an awful lot of output that is very rarely of interest was | |
580 | generated. I have changed this so that "+all" no longer includes | |
581 | "+memory". However, "-all" still turns everything off. | |
582 | ||
e5a9dba6 | 583 | |
b5aea5e1 PH |
584 | Version 4.51 |
585 | ------------ | |
586 | ||
1a46a8c5 PH |
587 | PH/01 The format in which GnuTLS parameters are written to the gnutls-param |
588 | file in the spool directory has been changed. This change has been made | |
589 | to alleviate problems that some people had with the generation of the | |
590 | parameters by Exim when /dev/random was exhausted. In this situation, | |
591 | Exim would hang until /dev/random acquired some more entropy. | |
592 | ||
593 | The new code exports and imports the DH and RSA parameters in PEM | |
594 | format. This means that the parameters can be generated externally using | |
595 | the certtool command that is part of GnuTLS. | |
596 | ||
597 | To replace the parameters with new ones, instead of deleting the file | |
598 | and letting Exim re-create it, you can generate new parameters using | |
599 | certtool and, when this has been done, replace Exim's cache file by | |
600 | renaming. The relevant commands are something like this: | |
601 | ||
602 | # rm -f new.params | |
603 | # touch new.params | |
604 | # chown exim:exim new.params | |
605 | # chmod 0400 new.params | |
606 | # certtool --generate-privkey --bits 512 >new.params | |
607 | # echo "" >>new.params | |
608 | # certtool --generate-dh-params --bits 1024 >> new.params | |
609 | # mv new.params params | |
610 | ||
611 | If Exim never has to generate the parameters itself, the possibility of | |
612 | stalling is removed. | |
613 | ||
614 | PH/02 A new expansion item for dynamically loading and calling a locally- | |
615 | written C function is now provided, if Exim is compiled with | |
616 | ||
617 | EXPAND_DLFUNC=yes | |
618 | ||
619 | set in Local/Makefile. The facility is not included by default (a | |
620 | suitable error is given if you try to use it when it is not there.) | |
4754440d PH |
621 | |
622 | If you enable EXPAND_DLFUNC, you should also be aware of the new redirect | |
623 | router option forbid_filter_dlfunc. If you have unprivileged users on | |
624 | your system who are permitted to create filter files, you might want to | |
625 | set forbid_filter_dlfunc=true in the appropriate router, to stop them | |
626 | using ${dlfunc to run code within Exim. | |
627 | ||
628 | You load and call an external function like this: | |
1a46a8c5 PH |
629 | |
630 | ${dlfunc{/some/file}{function}{arg1}{arg2}...} | |
631 | ||
4754440d PH |
632 | Once loaded, Exim remembers the dynamically loaded object so that it |
633 | doesn't reload the same object file in the same Exim process (but of | |
634 | course Exim does start new processes frequently). | |
1a46a8c5 PH |
635 | |
636 | There may be from zero to eight arguments to the function. When compiling | |
637 | a local function that is to be called in this way, local_scan.h should be | |
638 | included. The Exim variables and functions that are defined by that API | |
639 | are also available for dynamically loaded functions. The function itself | |
640 | must have the following type: | |
641 | ||
642 | int dlfunction(uschar **yield, int argc, uschar *argv[]) | |
643 | ||
644 | Where "uschar" is a typedef for "unsigned char" in local_scan.h. The | |
645 | function should return one of the following values: | |
646 | ||
647 | OK Success. The string that is placed in "yield" is put into | |
648 | the expanded string that is being built. | |
649 | ||
650 | FAIL A non-forced expansion failure occurs, with the error | |
651 | message taken from "yield", if it is set. | |
652 | ||
653 | FAIL_FORCED A forced expansion failure occurs, with the error message | |
654 | taken from "yield" if it is set. | |
655 | ||
656 | ERROR Same as FAIL, except that a panic log entry is written. | |
657 | ||
658 | When compiling a function that is to be used in this way with gcc, | |
659 | you need to add -shared to the gcc command. Also, in the Exim build-time | |
660 | configuration, you must add -export-dynamic to EXTRALIBS. | |
b5aea5e1 | 661 | |
7dbf77c9 PH |
662 | TF/01 $received_time is a new expansion variable containing the time and date |
663 | as a number of seconds since the start of the Unix epoch when the | |
664 | current message was received. | |
b5aea5e1 | 665 | |
7766a4f0 PH |
666 | PH/03 There is a new value for RADIUS_LIB_TYPE that can be set in |
667 | Local/Makefile. It is RADIUSCLIENTNEW, and it requests that the new API, | |
668 | in use from radiusclient 0.4.0 onwards, be used. It does not appear to be | |
669 | possible to detect the different versions automatically. | |
670 | ||
54cdb463 PH |
671 | PH/04 There is a new option called acl_not_smtp_mime that allows you to scan |
672 | MIME parts in non-SMTP messages. It operates in exactly the same way as | |
673 | acl_smtp_mime | |
674 | ||
cf00dad6 PH |
675 | PH/05 It is now possible to redefine a macro within the configuration file. |
676 | The macro must have been previously defined within the configuration (or | |
677 | an included file). A definition on the command line using the -D option | |
678 | causes all definitions and redefinitions within the file to be ignored. | |
679 | In other words, -D overrides any values that are set in the file. | |
680 | Redefinition is specified by using '==' instead of '='. For example: | |
681 | ||
682 | MAC1 = initial value | |
683 | ... | |
684 | MAC1 == updated value | |
685 | ||
686 | Redefinition does not alter the order in which the macros are applied to | |
687 | the subsequent lines of the configuration file. It is still the same | |
688 | order in which the macros were originally defined. All that changes is | |
689 | the macro's value. Redefinition makes it possible to accumulate values. | |
690 | For example: | |
691 | ||
692 | MAC1 = initial value | |
693 | ... | |
694 | MAC1 == MAC1 and something added | |
695 | ||
696 | This can be helpful in situations where the configuration file is built | |
697 | from a number of other files. | |
698 | ||
699 | PH/06 Macros may now be defined or redefined between router, transport, | |
700 | authenticator, or ACL definitions, as well as in the main part of the | |
701 | configuration. They may not, however, be changed within an individual | |
702 | driver or ACL, or in the local_scan, retry, or rewrite sections of the | |
703 | configuration. | |
704 | ||
475fe28a PH |
705 | PH/07 $acl_verify_message is now set immediately after the failure of a |
706 | verification in an ACL, and so is available in subsequent modifiers. In | |
707 | particular, the message can be preserved by coding like this: | |
708 | ||
709 | warn !verify = sender | |
710 | set acl_m0 = $acl_verify_message | |
711 | ||
712 | Previously, $acl_verify_message was set only while expanding "message" | |
713 | and "log_message" when a very denied access. | |
714 | ||
e4a89c47 PH |
715 | PH/08 The redirect router has two new options, sieve_useraddress and |
716 | sieve_subaddress. These are passed to a Sieve filter to specify the :user | |
717 | and :subaddress parts of an address. Both options are unset by default. | |
718 | However, when a Sieve filter is run, if sieve_useraddress is unset, the | |
719 | entire original local part (including any prefix or suffix) is used for | |
720 | :user. An unset subaddress is treated as an empty subaddress. | |
475fe28a | 721 | |
be22d70e PH |
722 | PH/09 Quota values can be followed by G as well as K and M. |
723 | ||
2e0c1448 PH |
724 | PH/10 $message_linecount is a new variable that contains the total number of |
725 | lines in the header and body of the message. Compare $body_linecount, | |
726 | which is the count for the body only. During the DATA and | |
727 | content-scanning ACLs, $message_linecount contains the number of lines | |
728 | received. Before delivery happens (that is, before filters, routers, and | |
729 | transports run) the count is increased to include the Received: header | |
730 | line that Exim standardly adds, and also any other header lines that are | |
731 | added by ACLs. The blank line that separates the message header from the | |
732 | body is not counted. Here is an example of the use of this variable in a | |
733 | DATA ACL: | |
734 | ||
735 | deny message = Too many lines in message header | |
736 | condition = \ | |
737 | ${if <{250}{${eval: $message_linecount - $body_linecount}}} | |
738 | ||
739 | In the MAIL and RCPT ACLs, the value is zero because at that stage the | |
740 | message has not yet been received. | |
741 | ||
d20976dc PH |
742 | PH/11 In a ${run expansion, the variable $value (which contains the standard |
743 | output) is now also usable in the "else" string. | |
744 | ||
2e2a30b4 PH |
745 | PH/12 In a pipe transport, although a timeout while waiting for the pipe |
746 | process to complete was treated as a delivery failure, a timeout while | |
747 | writing the message to the pipe was logged, but erroneously treated as a | |
748 | successful delivery. Such timeouts include transport filter timeouts. For | |
749 | consistency with the overall process timeout, these timeouts are now | |
750 | treated as errors, giving rise to delivery failures by default. However, | |
751 | there is now a new Boolean option for the pipe transport called | |
752 | timeout_defer, which, if set TRUE, converts the failures into defers for | |
753 | both kinds of timeout. A transport filter timeout is now identified in | |
754 | the log output. | |
755 | ||
7766a4f0 | 756 | |
f7b63901 | 757 | Version 4.50 |
35edf2ff PH |
758 | ------------ |
759 | ||
b9e40c51 | 760 | The documentation is up-to-date for the 4.50 release. |
495ae4b0 PH |
761 | |
762 | **** |