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