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