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